On Wed, 18 Sep 2019 at 16:36, Hynek Mlnarik <hmlnarik(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user