dimas-b commented on code in PR #1506:
URL: https://github.com/apache/polaris/pull/1506#discussion_r2093430843
##########
spec/polaris-management-service.yml:
##########
@@ -938,6 +940,38 @@ 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"
+ serviceIdentity:
+ $ref: '#/components/schemas/ServiceIdentityInfo'
Review Comment:
I assume credentials referenced by `serviceInfoAuthLocatorUrn` are provided
by the end user, right? In that case does it not contradict having a
`serviceArn`?
In other words, if the user provide connection credentials, the "service"
acts not by itself, but on behalf of the user. It will assume the identity
associated with the use-provided credentials. In this case we probably do not
need `serviceIdentity` at all :thinking: ... or did I miss something?
I think `serviceIdentity` is relevant only when the service authenticates
itself using service-provided (pre-configured) credentials (such as workload
identity). WDYT?
--
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]
