collado-mike commented on PR #461: URL: https://github.com/apache/polaris/pull/461#issuecomment-2533431900
> Generally, I do not think that Apache Polaris should get into the business of handling identities or secrets, but rather interface w/ systems that are purely there for these kinds of things. The currently built-in secrets handling should IMHO entirely go away. While I appreciate the security focus, I think the reality is that we are going to have to be able to manage secrets in Polaris as a standalone application for a long time (forever?). External secrets management systems like Vault or external identity providers like Okta are fantastic and I definitely promote their usage, but the reality is that some installations will simply not want/need the overhead of managing an external service. I think our approach should be that core features work out of the box with nothing more than a database (even that might be a local file), but that we allow extension points to add more and more layers of security and functionality. My proposal for Federated Principals and Roles is an example of this - basic identity management works, but if you want to be _really_ secure, delegate identity and group membership to an external service that's tailor made for that. I 100% agree with the approach that we should expose secrets once and never again. This is a core tenet of the service and the reason why there are no secrets retrieval APIs. It's why @eric-maynard's changes to store only secret hashes works. But there has to be _once_. That means that during bootstrapping, we need the ability to return the root credentials to the user who bootstrapped. Never again will we return those credentials be accessible, but we have to be able to return them somewhere. I see a few approaches for this: 1. Remove the `bootstrap` method from the `PolarisMetaStoreManager` and bootstrap directly from the `BootstrapCommand` class, as @dimas-b suggests. I actually think this is very elegant and allows the `BootstrapCommand` itself to determine what to do with the secrets (print or not depending on the argument) 2. Keep the `bootstrap` method, but change the response to return a `Map<String, PrincipalSecrets>` so that the `BootstrapCommand` can determine what to do with the secrets 3. Add a `PrincipalSecretsConsumer` of some kind that takes the generated secrets and does something with them. This can be configured on the CLI to print or to store in a file or whatever Personally, I like 1. It's clean and simple and there's no opportunity to misuse it. The tests and the in-memory startup will need to change, but I think that's a cost worth paying. -- 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]
