[keycloak-dev] File-based Vault implementation

Sebastian Laskawiec slaskawi at redhat.com
Mon Aug 5 08:28:26 EDT 2019


On Mon, Aug 5, 2019 at 9:49 AM Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> From maintenance perspective, single implementation is better, in
> which case the multiple files (alike Kubernetes) would be the one to choose.
>

I totally agree.


>
> How many secrets are expected to be used within testsuite? Unless this
> number is big, I'd still prefer a single implementation.
>

That's a good point. Let's see how it goes when we'll be implementing this.


>
> --Hynek
>
> On Fri, Aug 2, 2019 at 11: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
>>
>


More information about the keycloak-dev mailing list