bug: credentials for external sources should be enforced

[arkbriar]

Describe the bug

For now, the credentials can be omitted, e.g,.

CREATE TABLE side_input(
      key BIGINT PRIMARY KEY,
      value VARCHAR
    )  WITH (
    connector = 's3',
    s3.region_name = 'us-east-1',
    s3.bucket_name = 'xxxx',
    match_pattern = 'side-input.csv'
    ) FORMAT PLAIN ENCODE CSV (
        without_header = 'true',
        delimiter = ','
    );

, and RisingWave will use the local AWS credentials to access the S3 bucket.

It might be handy for local deployments but it's dangerous when RisingWave is serving external queries. There's a chance that the querier can have access to files in the RisingWave's state store.

Error message/log

ERROR:  QueryError: internal error: connector error: service error

To Reproduce

No response

Expected behavior

I expected to see that the credentials are enforced and the SQL is rejected because lacking of them, like what Snowflake does.

CREATE TABLE side_input(
      key BIGINT PRIMARY KEY,
      value VARCHAR
    )  WITH (
    connector = 's3',
    s3.region_name = 'us-east-1',
    s3.bucket_name = 'xxxx',
    s3.credentials.access='dummy',
    s3.credentials.secret='dummy',
    match_pattern = 'side-input.csv'
    ) FORMAT PLAIN ENCODE CSV (
        without_header = 'true',
        delimiter = ','
    );

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response

[huangjw806]

Only when the bucket is Publicly accessible, we can not write ak, sk. As long as the bucket is private, we must provide ak, sk？

[arkbriar]

Only when the bucket is Publicly accessible, we can not write ak, sk. As long as the bucket is private, we must provide ak, sk？

Yes. And for those not provided with AK/SK, we shouldn't allow them to use the local ones.