GabrielBBaldez commented on issue #16667: URL: https://github.com/apache/iceberg/issues/16667#issuecomment-4691958036
I dug into this and can confirm the root cause. `RESTSigV4AuthSession` signs requests with `AwsProperties#restCredentialsProvider()`, which delegates to the internal `credentialsProvider(...)` decision chain. That chain only handles explicit static `rest.*` keys, a custom `client.credentials-provider`, and otherwise the `DefaultCredentialsProvider` — there is 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. The REST calls silently fall through to the default credential chain — exactly the permission divergence reported here. Opened #16794 implementing the "fastest path" from the description: 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`. Static `rest.*` keys and `client.credentials-provider` keep precedence, and it is covered with unit tests. @NathanCYee apologies if you were already mid-work on this — happy to collaborate. @xndai I kept it to the minimal option-1; glad to extract a shared utility (option 3) instead if you'd prefer to avoid the small duplication with `AssumeRoleAwsClientFactory`. -- 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]
