dimas-b commented on code in PR #1506:
URL: https://github.com/apache/polaris/pull/1506#discussion_r2074474158


##########
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:
   > how about using serviceArn as the field name
   
   This is still a value that it _not_ used by Polaris code. That, IMHO, makes 
it irrelevant to this config object and confusing.
   
   I believe connection configuration in for cases when Polaris is a service 
needs to be clarified. 
   
   What workflow do you have in mind? Something like this?
   1. User contacts service provider to setup a Federated Catalog
   2. Service provider invokes Admin API and saves a 
`SigV4AuthenticationParameters`
   3. User accesses the Admin API and reads `SigV4AuthenticationParameters`
   4. User extracts `serviceArn` from the output of the API call
   5. User uses `serviceArn` to grant Polaris permission to perform AssumeRole 
in STS and access AWS resources.
   
   ... or is it something else?
   
   If so, why couldn't the user learn about `serviceArn` at step 1?



-- 
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]

Reply via email to