Skip to content

Client Secret Generation Approaches⚓︎

It is intended to simplify the setup of the EOEPCA BBs as far as possible by handlung automatable aspects in Helm charts. One of these aspects is setting up clients, routes and client secrets shared among them. The client secrets should be configurable explicitly for cases where this is really needed, but created and handled automatically by default.

This document describes how the setup of client secrets is currently handled by the IAM BB Helm chart, taking the OPA route and its associated clients as an example. It is meant as a starting point for discussing how client secrets should be handled in EOEPCA in general.

General Considerations⚓︎

Tooling⚓︎

Two tools are taken into account as a potential prerequisite:

The Crossplane Keycloak Provider is already required and used by the Workspace BB. So we can assume that it is available in a typical EOEPCA setup, and it makes sense to leverage it for setting up required Keycloak objects like clients, resources, groups etc.

The Kubernetes Secret Generator is not available in EOEPCA yet. It is an operator that allows creating and managing random values in Kubernertes secrets independently of Helm.

It is possible to generate random values directly from a Helm chart. However, without extra handling this causes values to be regenerated each time an update is performed, which may interfere with ArgoCD. When using Kubernetes Secret Generator, the Helm chart can reproducibly create constant secrets, which are amended by the operator at runtime. This may (or may not) be a sufficient benefit that justifies adding a dependency on the Kubernetes Secret Generator.

Special Considerations for IAM BB⚓︎

It is assumed that the EOEPCA BBs will typically be installed together in a single cluster. However, for the IAM BB this may not always be true. The IAM BB handles sensitive data, and therefore a platform operator may decide to deploy it separately from the other BBs and with as few dependencies as possibly. For instance, this means that Crossplane may not be available on the cluster where the IAM BB is installed.

For this reason, the Crossplane-related configuration has been separated from the iam-bb Helm chart and put into a separate chart named iam-bb-config. This chart is typically installed implicitly as a subchart of the iam-bb chart, but it can also be installed separately as a stand-alone chart, possibly in a separate cluster. In the latter case, however, secrets generated by the iam-bb chart may have to be transferred to the other cluster manually.

Note that there is probably no need to separate the Crossplane-related configuration from the main Helm chart for any other BBs than the IAM.

Realm Setup Using keykloak-config-cli⚓︎

The basic realm initialization is performed via keycloak-config-cli and thus independently of Crossplane. The iam-bb Helm chart also supports creating a client for Crossplane Keycloak Provider. The iam-bb-config Helm chart references this client when configuring the Keycloak Provider. This way the transition from basic Realm setup to Crossplane-based Keycloak configuration is fully automated in case of a single-cluster setup.

Configuration Approaches⚓︎

The iam-bb Helm chart allows configuring or generating client secrets in different ways, which are described in this section.

Literal client secret in values.yaml file⚓︎

The simplest, but also most insecure way of configuring a client secret is to specify it literally in the values.yaml file. This is mostly useful for a development environment. 

iam:
  opa:
    clientId: opa
    clientSecret: my_very_secret_client_secret

Reference to existing secret⚓︎

As a more secure alternative, the client secret can be configured by referencing an existing secret. Besides the client secret itself the referenced secret may also contain additional configuration values for the route. E.g., the client ID may be contained in the secret and can then be omitted from the values.yaml file in this case. 

iam:
  opa:
    # clientId: opa (omitted, taken from referenced secret)
    clientSecretRef: my-existing-opa-route-secret

Automated Secret Generation⚓︎

In most cases, it is not necessary to specify client secrets explicitly. They can simply be generated instead.

Secret Generation by Helm Chart⚓︎

Helm allows generating secrets using template functions like randAlphaNum. This works quite well for the initial installation, but may cause problems during upgrades or in conjunction with ArgoCD, because each template application generates different secrets.

This problem can be mitigated by performing a lookup on each affected secret and only generating a new value if the secret does not exist yet. However, this does not work if the templates are applied offline, e.g. through helm template.

This approach is selected by setting the useSecretGenerator configuration parameter to false and omitting clientSecret and clientSecretRef or leaving them blank. 

iam:
  keycloak:
    configuration:
      useSecretGenerator: false

Secret Generation via Kubernetes Secret Generator⚓︎

Kubernetes-secret-generator is an operator that allows generating secret values at runtime based on annotations or CRs. It can thus decouple secret value generation from Helm template execution, allowing Helm to generate fixed output without random values. This can be beneficial in conjunction with tools like ArgoCD. The main disadvantage is that kubernetes-secret-generator needs to be installed as a prerequisite.

This approach is selected by setting the useSecretGenerator configuration parameter to true and omitting clientSecret and clientSecretRef or leaving them blank. 

iam:
  keycloak:
    configuration:
      useSecretGenerator: true

Conclusion⚓︎

All listed approaches have their pros and cons.

Literal client secrets in the values.yaml file are mostly useful for quick evaluation or during development, but are not suitable for production use. Furthermore, they can be replaced with automated secret generation in virtually all relevant use cases and thus need not necessarily be supported.

The possibility to specify client secrets and configurations as existing secrets allows creating stable configurations without any magic that may cause problems. It also allows adapting plugin configurations in an easy way. So this approach should be supported.

The automated approaches can simplify the installation process a lot in cases where no direct control over the actual secret values is needed. The Helm-based approach should therefore be supported in any case, preferably including lookup. The kubernetes-secret-generator-based approach should be supported only as an option in order to avoid a hard dependency on kubernetes-secret-generator.

Implementation Status in IAM-BB Helm Chart⚓︎

The OPA route and the corresponding Keycloak client share a common secret that contains the client secret and optional APISIX plugin configuration. This secret can be populated using any of the described approaches as indicated.

The Helm chart supports generating a Crossplane Keycloak Provider configuration along with an associated Keycloak client. For the underlying secret, the kubernetes-secret-generator-based approach cannot be used due to the way how the secret needs to be constructed. The other approaches are supported though.

Note that the IAM-BB Helm chart does not currently perform lookups to find existing secrets. This may be added in the future.