[keycloak-dev] File-based Vault implementation

[Pedro Igor Silva]

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