eric-maynard commented on code in PR #389:
URL: https://github.com/apache/polaris/pull/389#discussion_r1828951565
##########
spec/polaris-management-service.yml:
##########
@@ -901,6 +903,58 @@ components:
required:
- roleArn
+ S3StorageConfigInfo:
+ type: object
+ description: S3 compatible storage configuration info (MinIO, Dell ECS,
Netapp StorageGRID, ...)
+ allOf:
+ - $ref: '#/components/schemas/StorageConfigInfo'
+ properties:
+ credsCatalogAndClientStrategy:
+ type: string
+ enum:
+ - VALUE
+ - ENV_VAR_NAME
+ default: ENV_VAR_NAME
+ example: "ACCESS_KEY"
+ description: When you send key VALUE directly via this command, they
should apear in logs. By ENV_VAR_NAME without dollar, only a reference will
appear in logs, but the value have to be available as environnement variable in
the context where Polaris is running
+ credsVendingStrategy:
+ type: string
+ enum:
+ - TOKEN_WITH_ASSUME_ROLE
+ - KEYS_SAME_AS_CATALOG
+ - KEYS_DEDICATED_TO_CLIENT
Review Comment:
> you have not to rely on the main credentials provided at the global
Polaris service level.
I think this is the key point here. I agree that the experience you describe
is bad, but I'm not sure that fixing it should be a blocker for s3compat
support (or that this is the right fix).
Would you be okay saving this for later, or carving it out into a different
PR? In my view relying on the global credentials in production is universally a
bad idea, regardless of what STORAGE_TYPE you're using.
--
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]
