[keycloak-dev] File-based Vault implementation

[Stian Thorgersen]

A client secret for a new OIDC client will not be stored in the vault
regardless. That would be something that we plan to encrypt in the database.

Look at the use-case of an LDAP bind password for instance. The value
should be added directly to the vault, not through the Keycloak admin
console. If that's Kube it's Kube secrets using kubectl. If that's
HashiCorp vaut it's done with the CLI/GUI provided by that vault.

On Wed, 14 Aug 2019 at 11:54, Marek Posolda <mposolda at redhat.com> wrote:

> On 14. 08. 19 11:21, Stian Thorgersen wrote:
> > 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.
>
> IMO having writable vault can be beneficial. It would mean that new
> secrets can be written to the vault OOTB without any further actions
> required from admin. For example when you register new OIDC client, the
> client secret won't be automatically written to the DB, but instead the
> file will be created by the file-vault and just the reference to the
> vault will be written to the DB. So no further action will be required
> by admin and DB will never contain any secrets at any point of time,
> which is good thing.
>
> I understand that people may want to have their own vault implementation
> and manage secrets themselves, so the Vault SPI would need to have a way
> to specify whether vault is writable or read-only.
>
> Marek
>
> >
> > 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
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>