tokoko commented on issue #2970: URL: https://github.com/apache/polaris/issues/2970#issuecomment-3725072364
sounds good. Right now I'm thinking of the possible solutions: 1. Having thought a bit more about it, unless we go with some sort of secrets manager that will have it's own rbac, allowing arbitrary access to env variables during CreateCatalog (however secure one might think it may be) is a bad idea. There should not be a way for a StorageInfo config to control where the values come from, instead I think the easiest solution will be if we extend already existing `polaris.storage.aws.access-key` and `polaris.storage.aws.secret-key` configs. We could introduce similar catalog-scoped configs like `polaris.storage.aws.<catalog-id>.access-key` and `polaris.storage.aws.<catalog-id>.secret-key`. How the values are provided on startup will be completely up to the deployment owner, mounting k8s secrets as env variables is obviously the most straightforward solution. The only downside here is that we're effectively splitting up creation of a catalog in two parts: CreateCatalog call and prepopulation of keys in polaris config, but personally I can live w ith that. 2. We can do a read-only secrets manager where values can be populated from env vars or polaris config, arbitrary StorageInfo configs (and other places) can refer to them in some way, but there should probably be some rbac in the mix as well. I'm heavily in favor of the first option, probably because I'm only interested in a single-tenant deployment where product-specific secret manager is not worth the trouble. -- 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]
