[keycloak-dev] File-based Vault implementation

[Stian Thorgersen]

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 at redhat.com> 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 at redhat.com>
> wrote:
>
> > On Mon, Aug 12, 2019 at 11:43 PM Sebastian Laskawiec <
> slaskawi at redhat.com>
> > 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>