XJDKC commented on code in PR #1506:
URL: https://github.com/apache/polaris/pull/1506#discussion_r2074241739
##########
spec/polaris-management-service.yml:
##########
@@ -938,6 +940,34 @@ components:
format: password
description: Bearer token (input-only)
+ SigV4AuthenticationParameters:
+ type: object
+ description: AWS Signature Version 4 authentication
+ allOf:
+ - $ref: '#/components/schemas/AuthenticationParameters'
+ properties:
+ roleArn:
+ type: string
+ description: The aws IAM role arn assume when signing requests
Review Comment:
Hey Dennis, thanks for bringing this up, I didn't realize there was already
a solution in place for storage config.
We can definitely follow the same pattern for connection config: skip
assuming the role and just read the credentials from the command line. I also
looked into the Iceberg SDK, if we don't explicitly pass credentials in the
catalog properties when initializing the RESTCatalog, the SDK falls back to AWS
SDK's `DefaultCredentialsProvider`, which picks up credentials from the
environment variables.
Code pointers:
[RESTSigV4Signer.java#L91](https://github.com/apache/iceberg/blob/apache-iceberg-1.9.0/aws/src/main/java/org/apache/iceberg/aws/RESTSigV4Signer.java#L91)
[AwsProperties.java#L417-L435](https://github.com/apache/iceberg/blob/apache-iceberg-1.9.0/aws/src/main/java/org/apache/iceberg/aws/AwsProperties.java#L417-L435)
Agree that there could be other non-static-creds (e.g. For Top Secret
Region, we need to call CAP service to get the credentials, it's a replacement
to the STS). Instead of creating many top-level types for SigV4, let's not
adding any particular type for SigV4 auth.
I will add `SUPPORTED_CONNECTION_AUTH_TYPES` in a follow up PR.
Mind giving this PR a stamp?
cc: @dimas-b @dennishuo
--
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: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
