[keycloak-dev] File-based Vault implementation

Thu Aug 8 03:34:21 EDT 2019

On Tue, Aug 6, 2019 at 4:05 PM Pedro Igor Silva <psilva at redhat.com> wrote:

> Not sure if makes sense if we have our own SPI and impl. Maybe what we
> want is more simple and more aligned with Keycloak arch ...
>
> If I understood the proposal correctly, the design document is about a
> read-only / read-write approach for credential storage.
>

Probably Hynek can answer this better but I believe the read-only is a
must-have and read-write is nice-to-have and definitely not for now. So I'm
not sure 100% is read-write will ever occur.

> Where read-only is related to leveraging 3rd party credential stores so
> you can fetch credentials from them. The point I'm trying to make is that
> you don't need to come up with an SPI but implement Elytron's SPI.
>

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 at redhat.com>
> 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 at redhat.com>
>> 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/1c42623a343e138ac4a31bd5dcfd8d2ccc47633e/credential/store/src/main/java/org/wildfly/security/credential/store/CredentialStoreSpi.java#L35
>>>
>>> On Tue, Aug 6, 2019 at 3:37 AM 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
>>>>>
>>>>