dennishuo commented on code in PR #1506:
URL: https://github.com/apache/polaris/pull/1506#discussion_r2074012033
##########
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:
Replied on the dev list as well, but I think for STATIC_CREDS we can
probably follow the same convention we started with
[SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION](https://github.com/apache/polaris/blob/4db7998381a61e9cab82cdc4fded6867b0bca464/service/common/src/main/java/org/apache/polaris/service/catalog/io/FileIOUtil.java#L92)
for StorageConfig, where we can be more opinionated about subscoping design
for the "managed multi-tenant" use cases, while allowing a simpler approach for
open-ended "self-managed, single-tenant" use cases to just delegate to
environment variables and/or default client SDK behaviors.
In particular, we can take stand on whether we ever actually want Polaris to
run in a mode that mixes some catalogs that do subscoping with other catalogs
that just use static credentials through environment variables or similar. The
problem is that the subscoping is trying to promise certain guarantees of
isolation, and mixing the two might fundamentally violate its assumptions. So
it might be best to really bifurcate the two use cases by essentially making
the behavior choice a top-level server config (e.g.
SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION) instead of trying to express it as an
"option" in the ConnectionConfigType.
That said, I don't feel too strongly whether to make the auth type more
sts-specific since *in theory* there could still be other non-static-creds
based flows for sigv4 that also don't use STS. Like it could be `SIGV4_STS` or
`STS_SIGV4`. But for now still not adding any particular type for static creds.
Alternatively, if anyone feels strongly that even in the static creds case
we need an explicit ConnectionType for it (maybe in addition to a server-level
config), we at the very least need to add a `SUPPORTED_CONNECTION_AUTH_TYPES`
just like how we have a `SUPPORTED_CATALOG_STORAGE_TYPES` because in
multi-tenant configurations it'll be important to block the ability for
catalogs to be configured to use open-ended static creds
--
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]
