XJDKC commented on code in PR #1506: URL: https://github.com/apache/polaris/pull/1506#discussion_r2074310561
########## spec/polaris-management-service.yml: ########## @@ -938,6 +940,40 @@ 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 assumed by polaris userArn when signing requests + example: "arn:aws:iam::123456789001:role/role-that-has-remote-catalog-access" + roleSessionName: + type: string + description: The role session name to be used by the SigV4 protocol for signing requests + example: "polaris-remote-catalog-access" + externalId: + type: string + description: An optional external id used to establish a trust relationship with AWS in the trust policy + example: "external-id-1234" + signingRegion: + type: string + description: Region to be used by the SigV4 protocol for signing requests + example: "us-west-2" + signingName: + type: string + description: The service name to be used by the SigV4 protocol for signing requests, the default signing name is "execute-api" is if not provided + example: "glue" + userArn: + type: string + description: The aws user arn used to assume the aws role, this represents the polaris service itself + example: "arn:aws:iam::123456789001:user/polaris-service-user" Review Comment: > the trust policy does not have to be based on a "user" ARN, it could be based on a "role" ARN too. Yes, you are right. But the fact is, we can't create long-lived creds for an IAM role. This is the model of AWS IAM service (see [IAM tutorial: Delegate access across AWS accounts using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)). The recommended model works like this: 1. The service provider creates an IAM user that represents its identity. 2. The service consumer creates an IAM role and configures the trust relationship to allow the service provider's IAM user to assume it. 3. The service provider uses long-lived credentials for its IAM user to assume the consumer's IAM role, getting temporary credentials with the role’s permissions. 4. The service provider uses those temp credentials to access the consumer's resources (e.g., S3, Glue, etc.). 5. **The service provider is responsible for rotating its long-lived credentials securely and periodically.** (userArn doesn't change) 6. **If the service consumer wants to revoke access, they simply remove the service provider's IAM user ARN from the role’s trust relationship.** So if polaris wants to assume a user-privided role from a polaris service role, before that, polaris needs to get a temp creds for that polaris service role. But then how do we get those initial creds? By assuming that polaris service role from another set of long-lived credentials? That gets a bit weird and kind of defeats the purpose. 🙂 -- 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