[keycloak-dev] File-based Vault implementation

[Sebastian Laskawiec]

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