Skip to content

openshift-secrets

Base profile backing OpenShift cluster secrets with an external secret store

Backs a cluster's generated secrets with an external secret store (through a DRP secret-store plugin) instead of storing them as local secure params.

This is the backend-agnostic half of the design: every secure param is set to a LookupUri reference composed from openshift/secrets/uri-prefix plus the per-secret leaf name (plus &format=json for structured params), and openshift/pull-secret dereferences openshift/secrets/pull-secret-uri. The backend-specific URI grammar lives entirely in those two params.

Do not apply this profile directly

Operators apply one of the backend profiles in this bundle, which nest this profile and supply the grammar params and openshift/secrets/type:

  • openshift-secrets-vault - HashiCorp Vault
  • openshift-secrets-awssecman - AWS Secrets Manager
  • openshift-secrets-azkeyvault - Azure Key Vault

The escape hatch: apply this profile directly and set openshift/secrets/uri-prefix, openshift/secrets/pull-secret-uri, and openshift/secrets/type yourself. One caveat on openshift/secrets/type: its schema is a closed enum of the shipped providers (secret-rotation tooling keys on those values), so if your backend is not one of them, leave it at the default and expect type-keyed automation not to recognize the backend.

How it works

Each reference is a Go template resolved per cluster at read and write time, so one profile serves every cluster. The URI scheme is the plugin instance named by openshift/secrets/store, and the per-cluster location is derived from the cluster FQDN (<name>.<cluster-domain>), which isolates each cluster's secrets.

Writes go through by default: setting a secure param whose aggregated value carries a LookupUri writes the value into the backing store and keeps the reference as the source of truth. Write-through aggregates from the object being written, so the pipeline's write sites are cluster-rooted (drpcli clusters set Name:<cluster> param ...), which sees this profile's references no matter how the profile reached the cluster (applied at creation or added later). A profile-rooted write (drpcli profiles set) only sees references in that profile's own chain and would silently seal the value locally instead. Use --no-write-through only to deliberately shadow a reference with a value stored on the object itself. Customers who do not set openshift/secrets/store and do not apply a backend profile keep the default behavior (local secure params, stored on the cluster object); the same pipeline serves both.

Scope

Every Secure param the pipeline reads or writes:

  • openshift/kubeconfig, openshift/kubeadmin-password, and openshift/ssh-key are generated per cluster and stored under the per-cluster location.
  • openshift/pull-secret is operator-provided and shared across clusters, so it uses the fixed location named by openshift/secrets/pull-secret-uri.
  • openshift/processed-pull-secret, openshift/controlplane, openshift/worker, openshift/install-config, openshift/agent-config, and openshift/external-registry-cert are pipeline-written per cluster and stored under the per-cluster location, same as the generated credentials above.
  • openshift/hub-cluster-kubeconfig and openshift/hub-cluster-init-repo-ssh-key are operator-provided for hub-spoke topologies and stored under the per-cluster location of the cluster they are set on.

Structured params (openshift/kubeconfig, openshift/pull-secret, openshift/hub-cluster-kubeconfig, and the other object-typed params) round-trip as JSON via &format=json; plain strings like openshift/kubeadmin-password and openshift/ssh-key omit the argument.

Requirements and caveats

  • Requires DRP with the more-external-secrets and secure-param-write-through features (enforced by this bundle's RequiredFeatures).
  • A configured, healthy secret-store plugin instance named by openshift/secrets/store must exist, and openshift/cluster-domain must be set so the per-cluster location resolves.
  • This is a shared profile: anyone with DRP RBAC to a cluster's profile can decode that cluster's secret. For tighter isolation, scope the backing store's access policy (Vault, AWS, and Azure all support per-secret/path scoping) or run separate plugin instances with distinct credentials.

Objects that Reference openshift-secrets

Objects used by openshift-secrets