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

I briefly looked at the SPI and it seems a bit over the top comparing to what we need. Plus we would create a strong connection between Keycloak and Elytron Security SPIs and I'm not sure if this is desirable. Maybe a translation layer (a simple Vault SPI implementation that delegates to Elytron SPIs) would be better?

> For read-write, you have the key store implementation from Elytron that > can save you some time. So your credentials are stored more securely and > you can easily look up them. > I agree with you here. The write path of the Vault SPI is a bit tricky. But I'm not sure if that will happen (we will probably see in the future). My personal vote here is to leave the door open and implement a delegation layer to Elytron SPIs. We can leave that as an Experimental Feature if we want to avoid extensive testing on the product side.

> > I just wanted to let you know about Elytron Credential Store. I haven't > joined the discussions about the credential store proposal so I may be just > messing your thread :) > > On Tue, Aug 6, 2019 at 10:35 AM Sebastian Laskawiec <slaskawi(a)redhat.com&gt; > wrote: > >> The idea sounds interesting to me. Although, having in mind our plans >> related to Keycloak.next, I'm not sure if we should provide it out of the >> box. >> >> Perhaps we should provide a community-driven extension (as a separate >> jar) to use this? >> >> On Tue, Aug 6, 2019 at 2:59 PM Pedro Igor Silva <psilva(a)redhat.com&gt; >> wrote: >> >>> Hey Hynek, >>> >>> Elytron came into my mind because it provides an SPI for plugging >>> different implementations based on a SPI [1]. There are some OOTB >>> implementations such as a keystore-based and map-based. >>> >>> You should be able to delegate to other vault types or even build your >>> own on top of some default implementation. Considering that Elytron >>> Subsystem is available as a subsystem you also have the necessary means to >>> manage your credential stores (via CLI, etc). >>> >>> [1] >>> https://github.com/wildfly-security/wildfly-elytron/blob/1c42623a343e138a... >>> >>> On Tue, Aug 6, 2019 at 3:37 AM Hynek Mlnarik <hmlnarik(a)redhat.com&gt; >>> 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(a)redhat.com&gt; >>>> 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(a)redhat.com&gt; >>>>> 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-... >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>>