[keycloak-dev] File-based Vault implementation

[Stefan Guilhen]

Adding Farah and Darran as they likely can answer most of our questions
around the credential store

On Tue, Aug 6, 2019, 03:40 Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Hi Pedro,
>
> Elytron Cred Store has been considered, any details would be appreciated.
> Specifically, does it support delegation to other vault types? Is it able
> to delegate access to other vault types, e.g. Kubernetes credentials? See
> [1] for further context.
>
> Pros and cons of other vault implementations are highly appreciated as
> well. The number of built-in implementations mus be kept low (one or two)
> for maintenance reasons, so we need convincing arguments for including any
> in Keycloak. On the other hand, support for other vault types can be
> contributed as a Community Extension [2].
>
> --Hynek
>
> [1]
>
> https://github.com/keycloak/keycloak-community/pull/18#discussion_r304860227
> [2] https://www.keycloak.org/extensions.html
>
> On Mon, Aug 5, 2019 at 2:55 PM Pedro Igor Silva <psilva at redhat.com> wrote:
>
> > Hi Sebastian,
> >
> > Elytron has a very powerful and flexible Credential Store SPI (Peter can
> > give more details) that can help managing credentials based on keys. You
> > could even use an implementation backed by a java key store (with
> in-memory
> > support).
> >
> > Wouldn't make sense to use it or at least check how the design could be
> > improved to fit our requirements?
> >
> > Regards.
> > Pedro Igor
> >
> > On Fri, Aug 2, 2019 at 6:39 AM Sebastian Laskawiec <slaskawi at redhat.com>
> > wrote:
> >
> > > Hey,
> > >
> > > We are considering an initial, file-based Vault [1] implementation that
> > > we'll ship out of the box. I imagine a minimum set of requirements as
> the
> > > following:
> > > - Easy to write by hand (for testing)
> > > - Works out of the box in Kubernetes (Kubernetes can mount Secrets as
> > > files)
> > > - Make sure we do not cache file content anywhere, so we don't
> > compromise a
> > > secret value in Keycloak
> > >
> > > Essentially, there are two approaches for such an implementation.
> > >
> > > The first option is to put all secrets into a shared file representing
> > > key-value pairs (a properties file is a natural candidate for such an
> > > implementation). This approach very easy to use but it's pretty hard to
> > > search for a particular key in a file. We would need to make sure that
> we
> > > don't cache anything wile parsing the file (in BufferedInputStream for
> > > example). Such an implementation would also be pretty slow, since
> > whenever
> > > we'd access the vault for a particular key, we would potentially need
> to
> > > search the whole file.
> > >
> > > The second option is more complicated. Imagine the following file
> > structure
> > > (inside a vault directory):
> > > my-secret-1 (secret value in its content)
> > > my-secret-2 (secret value in its content)
> > > my-secret-3 (secret value in its content)
> > > In other words, each key is a file in a vault directory and its content
> > > corresponds the secret value. Such an implementation is not very easy
> to
> > > use as we'd need to create many small files. However, it's super fast
> for
> > > searching and we can securely read the value without a risk of
> > compromising
> > > other secret values provided by the vault.
> > >
> > > I wonder what do you think about this? My personal take on this is that
> > we
> > > should provide both implementations. The former (single file) would be
> > used
> > > in our testsuite (because of simplicity) and the latter (multiple
> files)
> > in
> > > production and in Kubernetes.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > [1]
> > >
> > >
> >
> https://github.com/keycloak/keycloak-community/blob/master/design/secure-credentials-store.md
> > > _______________________________________________
> > > 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
>