On Mon, Aug 5, 2019 at 9:49 AM Hynek Mlnarik <hmlnarik(a)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(a)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-...
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>