XJDKC commented on code in PR #1506:
URL: https://github.com/apache/polaris/pull/1506#discussion_r2087269395
##########
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:
Hey Dmitri, I discussed the proposal of adding another set of management
apis for the service identity info in my design doc (topic 3, proposal 3):
[Apache Polaris Creds Management
Proposal](https://docs.google.com/document/d/1MAW87DtyHWPPNIEkUCRVUKBGjhh5bPn0GbtV7fifm30/edit?usp=sharing)
Here is the pros and cons:
* Pros
* Clean separation of concerns: identity info is no longer mixed into
catalog or storage config
* Keeps catalog schema simple and focused on user input
* Easy to extend without touching catalog model or breaking clients
* Works well for self-managed and SaaS deployments
* Cons
* Users must make an additional API call to fetch identity info, it
requires users to coordinate across two APIs to complete setup
* Identity context is no longer colocated with the catalog entity, this
assumed that polaris will use same identity for all the catalogs within the
same realm
* Incompatible with current behavior where identity fields are visible in
the catalog response
* Some service-managed fields like consentUrl are not static and cannot be
precomputed globally. Instead, they depend on user-provided configuration
(e.g., Azure tenant ID) and are generated after Polaris receives that info.
--
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]
