[keycloak-user] Plain-text vault

[Stian Thorgersen]

On Wed, 18 Sep 2019 at 16:36, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Recently, vault capability has been introduced recently in Keycloak
> (master) with an out-of-the-box implementation that is basically providing
> secrets in the same format as if mounting secrets volume within Kubernetes
> [1]. Now there have been considerations regarding name and storage layout
> which I would like to gather feedback on.
>
> The questions are the following ones. Both have arguments for the current
> implementation explained below:
> 1. Is there any better way of storing the credentials?
>

I really dislike the current scheme. We should go with either:

* directory for each realm - this would also allow shared secrets between
realms (secrets/mysecret is visible to all realms, secrets/realm-a/mysecret
is only visible to realm-a). I don't think the mountpath is all that bad as
I think in most cases secrets will be mounted into the pod with
ldap.secret, then made available to the Keycloak vault as
"my_realm/ldap_secret" or shared as "ldap_secret", so you would need to
write it anyways.
* a delimiter between realm name and secret name. realm-a---secret-a for
example. Note I've used 3 '-' as that makes it clear that there is more
than 1, with 2 '_' I actually had to count them with my mouse to be sure.

In general I think it would be good to have support for shared secrets
between all realms.


> 2. Is there a better name for the OOTB implementation?
>

It should be files or files-plaintext. Plaintext is not a very descriptive
name and doesn't indicate where it gets secrets from.


>
> Storage layout:
> The aim: The plain text vault implementation respects realm to prevent
> leaking a secret used in one vault into another realm. The implementation
> also accounts for Kubernetes secret keys naming restrictions [1] which are
> only consisting of alphanumeric characters, ‘-’, ‘_’ or ‘.’. Note that
> forward slash is not among allowed characters.
>
> Since the vault adheres to the same format as provided by Kubernetes
> secrets volume, it also limits the file possible names for easy usage.
> While kubernetes support exposing the secret keys as files in various
> subdirectories of the mount directory, the default way of providing secrets
> is via flat file structure (no subdirectories). To achieve structure where
> secret would be looked up in a file with a given key within a realm
> directory (i.e. realm_name/secret_key), every secret would have to be
> accompanied with "path" specification which is not particularly user
> friendly.
>
> Having kubernetes secrets per realm and mounting them into separate
> directories could be an option, however that limits the ability to easily
> add a new realm because the Pod definition would need to change with every
> new realm to incorporate the new volume, and the whole deployment restarted
> to reflect the changes. Alternatively, secrets for all realms could be
> mounted into a single directory and "path" would be defined for every
> secret as described above - but that is error-prone as well.
>
> Thus the implementation where realm name and secret key would be separated
> by a single underscore, and to prevent ambiguity, every underscore within
> the either realm name and secret keys would be doubled. In other words, to
> get secret called "some-secret" or "other_secret" from vault from within
> realm called "realm-1" or "other_realm", the files would be called
> "realm-1_some-secret" and "other__realm_other__secret", respectively. This
> is clearly readable in the former case but may be error-prone in the
> latter.
>
> Name:
> The SPI name was chosen to be "plaintext" since the secrets are stored
> openly in the files. Perhaps there is a better name? "kubernetes"? Any
> other suggestion or +1 or -1 with arguments to the alternatives are
> welcome.
>
> I would love to hear your opinion on the two questions.
>
> [Apologies for cross-posting, this can gain valuable feedback from both
> devs and users though]
>
> --Hynek
>
> [1] https://kubernetes.io/docs/concepts/configuration/secret/
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user