[keycloak-dev] File-based Vault implementation

Thu Aug 8 08:35:00 EDT 2019

On Thu, Aug 8, 2019 at 4:34 AM Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

>
> 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?
>

Yeah, it is. Like I said, for this particular case your SPI is more simple
and you won't get much from Elytron.

>
>> 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 see. If you are not planning to deliver the write path anytime soon,
let's talk more about it later.

Thanks.

>
>
>>
>> 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
>>>>>>
>>>>>