keycloak-operator vault support for client secrets

[Roman Manz]

Hello,

we have the requirement that users want to use the same keycloakclient in several namespaces across different clusters and we are seeking for a good solution to sync the client secrets.

We thought of pushing the secrets into a key vault and let the users synchronize from there. Would that be something that could be built into the keycloak operator? We thought of a kind of plugin mechanism which would enable administrators to add a sidecar to the keycloak operator providing the binary or maybe to share a socket and let the operator call it whenever a secret needs to be syncronized. The users could add plugin-specific information as an annotation to the keycloakclient CR, for ex. the vault user they will use to access the secrets.

If this does not sound like a good idea what alternative would you recommend?

In the other case we could work on a PR to suggest an implementation.

Many thanks and best regards,

Roman

[ronald fotso]

hi guys,

Could we have a review on this one ?

Regards,

Roni

[Roman Manz]

Was just looking at: https://github.com/keycloak/keycloak-community/blob/master/design/secure-credentials-store.md

The two could be combined together actually it seems. If we let the operator create the secret and push it to a Vault, Keycloak could use that Vault to read them in the same way as the users do. It is clear, the objection will be that the operator should not be involved in this business, and I understand, but I would still like to give it a try. We are looking into a full self-service approach where this would come handy.

[Václav Muzikář]

Hi, could you please elaborate a bit more on what you are trying to achieve exactly? Why do you need the same client across multiple namespaces? IMHO pushing client secrets to the vault is not something the operator should do.

Btw, vault with OCP secrets as the source is supported by the operator (although it's an experimental feature AFAIK) [1].

[1] https://github.com/keycloak/keycloak-operator/blob/master/deploy/examples/keycloak/keycloak-with-vault.yaml

--
You received this message because you are subscribed to the Google Groups "Keycloak Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/269acb09-77bf-4003-bd4e-c1d25eda2d7cn%40googlegroups.com.

--

Václav Muzikář
Senior Software Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

[Roman Manz]

Thanks a lot Vaclav for the reply.

The one requirement regarding the several namespaces comes from customers that run several stages on the same cluster, for ex. qat and uat. They would like to use the same clients in all their stages.

I understand the concern regarding the operator being involved in the secrets management, for use cases like this one it would be a good fit though because there are ways to synchronize vault secrets with OCP secrets, and that way we could have a full end to end flow - knowing that keycloak itself is (currently) "only" a vault reader.

If you can think of a simple alternative it would be great to know.

Thanks again!

[Václav Muzikář]

Hello,

if I understand correctly, you want to use Client CRDs as a sort of template to create identical clients in multiple Keycloak instances across several namespaces. Is that correct? I believe it doesn't work like that as you'd still need to have a copy of the Client CRD in each namespace for each Keycloak instance separately. The same applies for the secrets.

Regarding the Client Secrets stored as OCP Secrets. I think there are two ways to do it. Either the Operator will read the Secret when creating/updating the Client and send the Secret directly to Keycloak, or we will use the Vault and Keycloak will read the secret from it. I'd say the latter is a much more robust solution but I'm not sure if Vault can be used with Client Secrets or if it's even supposed to be used like this. Maybe @Hynek Mlnarik might have some insight into this.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/0e621a73-a157-49f6-9ee0-c2413c1af69dn%40googlegroups.com.

[Roman Manz]

Thanks again Vaclav for the reply.

[Roman Manz]

Sorry, clicked post just accidently, and sorry for the unclear description.

The intention is not to have several copies of the client.

If I understand the way the operator works correctly, if you run it in multi-tenant mode, if it finds a keycloakclient CR in a namespace it will create that client with the keycloak API and will in return create an OCP secret and that same namespace.

The workflow we had in mind is the exact same one. Just with the addition to push the client secret also into a vault. If then a customer needs that secret in several namespaces they can synchronize them from the vault directly.

For example one customer creates a CR in namespaceA, the keycloak operator creates the secret in namespaceA and the customer's application can use it there. If the same customer wants to run another instance of their application in namespaceB they don't need to create another client CR there, instead they can sync the client secret (from the vault) into namespaceB and use the same client_id, client_secret combination in both namespaces.

If you think it is too involved for the keycloak operator, I fully understand.

Thanks again and best regards.

[Václav Muzikář]

Hi,

sorry for the late reply. So if I understand correctly, you want to use a single Client CR for creating two identical clients in two different instances of Keycloak in two different namespaces. This is not supported at the moment (even though it might work with a bit of tweaking to WATCH_NAMESPACE var [1]).

Regarding the Vault. Currently, the Operator sends the secrets directly to Keycloak when configuring the client. Theoretically, we could use Vault for this to avoid sending it directly for improved security, although it seems to me like maybe a bit unnecessary additional complexity – not sure. But feel free to open a feature request for this! In any case, this wouldn't solve your problem as secrets can't be accessed across namespaces [2].

[1] https://github.com/keycloak/keycloak-operator/blob/98a6ba2ecda4900012e16c28aa9cab4bc6e6b9ea/deploy/operator.yaml#L24-L27

[2] https://kubernetes.io/docs/concepts/configuration/secret/#details

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/423fb700-16b1-4814-bba6-a24085e055bbn%40googlegroups.com.