[keycloak-dev] File-based Vault implementation

Wed Aug 14 16:37:25 EDT 2019

On 14. 08. 19 12:08, Stian Thorgersen wrote:
> 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.
Ok, I see now.
>
> 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.

I see the point for LDAP bind password. For client secrets it is 
different due the use-cases like OIDC client registration. But since 
those are encrypted, we should be fine. Thanks for the clarification.

Marek

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