GabrielBBaldez opened a new pull request, #16794: URL: https://github.com/apache/iceberg/pull/16794
## What changed `RESTSigV4AuthSession` signs catalog requests with `AwsProperties#restCredentialsProvider()`, whose decision chain only handled three cases: 1. explicit static `rest.*` keys → `StaticCredentialsProvider` 2. a custom `client.credentials-provider` → that provider 3. otherwise → `DefaultCredentialsProvider` There was no branch for `client.assume-role.*`. So when the catalog is configured with `AssumeRoleAwsClientFactory`, the assumed role is applied to the S3/Glue/KMS/DynamoDB clients (via `applyAssumeRoleConfigurations`) but never to the SigV4 REST signing path — REST calls silently fall back to the default credential chain and diverge from the other AWS clients. This adds an assume-role branch between the custom-provider and default-chain steps that returns an `StsAssumeRoleCredentialsProvider` built from the existing `client.assume-role.*` properties (arn, region, session name, timeout, external id, tags), mirroring `AssumeRoleAwsClientFactory#createCredentialsProvider`. Explicit static `rest.*` keys and `client.credentials-provider` keep precedence. This is the "fastest path" described in the issue. Happy to instead extract the STS provider construction into a shared utility (option 3 in the issue) if reviewers prefer to avoid the small duplication with `AssumeRoleAwsClientFactory`. Closes #16667 ## Testing New unit tests in `TestAwsProperties`: - assume-role configured → `restCredentialsProvider()` returns an `StsAssumeRoleCredentialsProvider` - no credentials configured → falls back to `DefaultCredentialsProvider` - explicit static `rest.*` keys → still returns `StaticCredentialsProvider` (precedence preserved) `./gradlew :iceberg-aws:test :iceberg-aws:spotlessJavaCheck :iceberg-aws:checkstyleMain :iceberg-aws:checkstyleTest` passes locally. -- 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]
