Re: [keycloak-dev] File-based Vault implementation

The issue we're primarily trying to solve here is that people where not happy to find the LDAP bind password and SMTP password in clear-text in the database. That's basically the most important thing we're trying to solve now. So let's not go overboard here. Some pointers from me: For file based provider do multiple file approach only. That is what we need for Kube and OpenShift. Do not worry about the secrets being clear-text in memory. The best we can do here is reduce the window/chance and can't prevent it completely. There is no need to add options as that just makes it more complex and adds test cases. This will be used for SMTP password, LPAP bind and client secrets for identity providers. That's it really for now. Realm keys are a separate thing and already have support to implement custom stuff here (such as loading keys from a vault, we already support keystore, or even using an external HSM to prevent Keycloak ever having access to private keys). For SMTP password and LDAP those needs to be cached in memory regardless due to connection pooling so trying to be clever and not caching in the vault provider won't mean the secrets are not available in clear text in memory. For client secrets for identity providers actually those that are paranoid shouldn't use client secrets, but rather use keys or certs for enhanced security. We will not use Elytron SPIs internally in Keycloak. However, we may if there is many vault providers available provide an vault provider that can delegate to Elytron. I do not actually foresee that we will ever need write access to the vault. As this is supposed to be used to inject secrets into Keycloak and I believe most proper vaults will have proper tools that admins are used to that allows them to manage secrets and they wouldn't use Keycloak admin console to add secrets to the vault regardless.

In the future we plan to add another capability that allows us to encrypt secrets at rest. That will enable encrypting secrets into the database. It's primary purpose will be to encrypt user secrets, client secrets, external tokens, etc. that are stored in the database. On Tue, 13 Aug 2019 at 16:02, Hynek Mlnarik <hmlnarik(a)redhat.com&gt; wrote: > HashiCorp might be the next one if there is enough interest in it. > > At this point, we need to have something simple and useful in place so that > we can also test with it. This is the purpose of Kubernetes / file-based > plaintext vault. There could be space for one more OOTB implementation like > HashiCorp. Feel free to comment on pros/cons just the same as we have with > Elytron Vault earlier in this thread. > > --Hynek > > On Tue, Aug 13, 2019 at 3:00 PM Pedro Igor Silva <psilva(a)redhat.com&gt; > wrote: > >> On Mon, Aug 12, 2019 at 11:43 PM Sebastian Laskawiec < > slaskawi(a)redhat.com&gt; >> wrote: >> >>> Writing anything by a running Pod is very tricky. In theory you could >> use a >>> Persistent Volume but this doesn't work with Secrets very well. So at >> least >>> in Kubernetes/OpenShift scenario, having a read-only vault and > delegating >>> manipulating vault's secrets to the environment is the most natural way >> to >>> tackle this. >>> >> It seems that a lot of people is using the Vault by HashiCorp to manage >> k8s/app sensitive data such as credentials. How useful a file-based vault >> would be if you are already using HashiCorp ? >> >> I think there is an ongoing work in Quarkus to support HashiCorp's Vault. >> Maybe it is worthy to consider it or maybe wait for KC.Next :) >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev