iremcaginyurtturk opened a new pull request, #1506:
URL: https://github.com/apache/iceberg-go/pull/1506

   ## Problem
   
   `createS3Bucket` (`io/gocloud/s3.go`) resolves the AWS config by preferring 
an ambient config injected into the context via `utils.WithAwsConfig` — for 
example the Glue catalog's own AWS config — and only falls back to 
`ParseAWSConfig(props)` when no context config exists. The **endpoint** is 
always read from the properties (`s3.endpoint`), but the **credentials** are 
whatever the context config carries.
   
   So when a catalog whose API credentials are AWS (Glue) writes to a bucket 
reached via a custom `s3.endpoint` whose credentials differ — a local MinIO, or 
a cross-account / delegated-role S3 target — the metadata read-back 
authenticates with the catalog's AWS credentials instead of the explicitly 
supplied `s3.access-key-id`, and fails:
   
   ```
   S3: GetObject ... api error InvalidAccessKeyId: The Access Key Id you 
provided does not exist in our records.
   ```
   
   `s3.access-key-id` / `s3.secret-access-key` / `s3.session-token` are 
silently ignored whenever a context config is present (the endpoint is 
honoured, so the request reaches the right store — with the wrong credentials).
   
   ## Fix
   
   Extract the resolution into `resolveS3AWSConfig`. When explicit `s3.*` 
credentials are present, layer a static credentials provider built from them 
over the resolved config — on a copy, so the shared context config is not 
mutated. Precedence becomes **explicit props > context config > default 
chain**, matching how `s3.endpoint` already behaves. The common case (Glue + 
AWS S3, where the storage creds *are* the catalog creds) is unchanged.
   
   ## Tests
   
   `TestResolveS3AWSConfigCredentialPrecedence` covers three cases:
   - explicit `s3.*` props override a context config (and do not mutate it),
   - the context config is used when no props creds are set,
   - props creds are used when there is no context config.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to