KEYCLOAK-17209 Add support for bind cred secret

[Kevin Burns]

I created jira KEYCLOAK-17209 and a PR with a possible solution. Does this look like a good way to handle allowing the ldap bind credential to be stored in a secret?

Thanks,

- Kevin

[Stian Thorgersen]

Keycloak already supports using secrets directly by configuring a vault, which under the covers can just be Kubernetes secrets. That would be the proper way to do this, as what you are doing here ends up loading the secret in the operator and also storing the secret in the KC db.

--
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/9b05d405-a060-4adc-9b88-a30f97191e54n%40googlegroups.com.

[Sebastian Łaskawiec]

Thanks for the Pull Request Kevin!

There's a number of tickets to introduce some sort of support for Secrets in our backlog. Most of the tickets are quite critical and touch different areas of our CRs - User Credentials (you can specify them in raw text) or configuration. Sadly, we don't have any coherent approach to them and we probably need to agree on one before merging your Pull Request.

I was thinking about creating a type capable of using raw values (for development purposes and backwards compatibility) and a reference to a Secret. Something like this:

type SecretRefOrValue struct {
    value *string

    secretRef *SecretKeySelector `json:",inline" name=secretRef"`

}

The idea here is to inline the Secret Ref so that it will result in a flat structure from the CRD perspective. This way, users will have a choice - they could use a raw value or a Secret.

Then, the Operator's code could use reflections and extract values from Secrets and put it into proper fields. My point here is that we need a generic mechanism that will do this for all CRs and at all levels.

What do you think?

--

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/9b05d405-a060-4adc-9b88-a30f97191e54n%40googlegroups.com.

--

Sebastian Łaskawiec

[Stian Thorgersen]

Secrets should be read by Keycloak, not the Operator. Hence why we should use the vault integration we already have.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-dev/CADP5VTUFj8-kUag86LRUy93iopfQXdevV7PUXk0XYjZaA1nqjQ%40mail.gmail.com.

[Kevin Burns]

Thanks for the feedback. I'll close my PR and look into using the vault integration. Once I get that working I'll put in a PR for a doc example for setting up a realm with LDAP and the vault integration.

[Roman Manz]

Just added a PR (https://github.com/keycloak/keycloak-operator/pull/329) that allows to mount secrets to implement the plaintext-vault as suggested above. It would be nice if you could comment there. Thank you!