Secrets in OpenShift

1 Die Typen

Der type eines Secrets erzwingt, welche Schlüssel drin sein müssen – und wofür OpenShift es benutzen darf.

# Opaque - der einfache Weg:
oc create secret generic catalog-db -n library \
  --from-literal=username=catalog \
  --from-literal=password='s3hr-geheim'

# aus einer Datei (der Schluessel wird der Dateiname):
oc create secret generic app-config -n library --from-file=./application.yaml

# ein TLS-Secret:
oc create secret tls catalog-tls -n library --cert=tls.crt --key=tls.key

# ansehen (Typ + Schluessel-Namen, nicht die Werte):
oc get secret catalog-db -n library -o yaml | grep -E 'type:|^  [a-z]'

immutable: true im Secret schützt vor versehentlicher Änderung (und spart etwas API-Last). Maximalgröße 1 MiB, weil alles in etcd landet.

2 env vs Mount – live

Der praktisch wichtigste Unterschied. Ein Pod nimmt ein Secret auf zwei Wegen, und sie verhalten sich verschieden.

Zum Selbst-Sehen: ein Secret als Mount in einen Test-Pod, dann den Wert ändern und im Pod warten:

oc create secret generic demo -n library --from-literal=k=eins
oc run demo --image=registry.access.redhat.com/ubi9/ubi-minimal -n library --restart=Never -- \
  sh -c 'while true; do cat /s/k; echo; sleep 5; done'
oc set volume pod/demo -n library --add --type=secret --secret-name=demo --mount-path=/s
oc logs -f demo -n library &
oc create secret generic demo -n library --from-literal=k=zwei --dry-run=client -o yaml | oc apply -f -
# nach ~1 min zeigt das Log 'zwei' - ein env haette weiter 'eins' gezeigt
oc delete pod demo -n library ; oc delete secret demo -n library

3 Der Klartext-Weg

Was in etcd liegt, ist per Default nur base64. Wer get secret darf, hat den Klartext – das ist die Rolle admin/edit, nicht view (B9).

# ein Feld:
oc get secret catalog-db -n library -o jsonpath='{.data.password}' | base64 -d ; echo

# alle Felder in Dateien:
oc extract secret/catalog-db -n library --to=./out --confirm

# eine aenderbare Vorlage (fuer Git NUR nach dem Versiegeln, Schritt 7):
oc create secret generic catalog-db -n library \
  --from-literal=password=neu --dry-run=client -o yaml

oc describe pod zeigt nur die env-Namen, nicht die Werte – aber oc get secret -o yaml > all.yaml oder ein Crash-Dump leakt alles. Deshalb: Secret-YAML nie in ein Ticket, nie in einen Chat, nie unverschlüsselt in Git.

4 Verschlüsselung at-rest

Standardmässig ist jedes etcd-Backup und jedes Disk-Image der Node Klartext. Ein Cluster-Schalter ändert das.

# einschalten:
oc patch apiserver cluster --type=merge -p '{"spec":{"encryption":{"type":"aescbc"}}}'

# der kube-apiserver-Operator rollt eine EncryptionConfiguration aus und
# schreibt alle bestehenden Secrets/ConfigMaps/Token neu. Fortschritt:
oc get apiserver cluster -o jsonpath='{.status.conditions}' | tr ',' '\n' | grep -i encrypt
oc get openshiftapiserver cluster -o jsonpath='{range .status.conditions[?(@.type=="Encrypted")]}{.reason}{"\n"}{end}'
# fertig, wenn reason = EncryptionCompleted

Der Schlüssel liegt in einem Secret im Namespace openshift-config-managed, der Operator rotiert ihn automatisch (wöchentlich). Das ist der OpenShift-Komfort – auf reinem Kubernetes ist das eine EncryptionConfiguration- Datei auf jedem Control-Plane-Node, von Hand.

5 Pull-Secrets

Wie ein Pod ein Image aus einer privaten Registry zieht.

# private externe Registry, nur ns library:
oc create secret docker-registry regcred -n library \
  --docker-server=ghcr.io --docker-username=USER --docker-password=TOKEN

oc secrets link default regcred --for=pull -n library     # an die default-SA haengen
# oder direkt im Deployment: spec.template.spec.imagePullSecrets: [{name: regcred}]

# clusterweit (registry.redhat.io o.ae.):
oc get secret pull-secret -n openshift-config -o jsonpath='{.data.\.dockerconfigjson}' | base64 -d > ps.json
#   ... ps.json um den neuen Eintrag ergaenzen ...
oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=ps.json

6 Rotation ohne Ausfall

Einen Secret-Wert austauschen, ohne dass etwas bricht.

Automatisch: TLS-Secrets vom service-ca-Operator (F5) und von cert-manager erneuern sich vor Ablauf selbst. Damit der Pod die neue Datei auch benutzt, löst ein Reloader (z. B. stakater/reloader) den rollout restart aus – oder man setzt eine checksum/config-Annotation am Pod-Template, die sich mit dem Secret ändert (macht der Helm-Chart, B12).

7 Raus aus Git

Der Kernkonflikt: die App-Config gehört versioniert in Git – ein Klartext-Secret nicht (base64 ist lesbar, jeder mit Repo-Zugriff hat die Zugangsdaten). Drei Modelle lösen das.

Die Vorlage baut man immer gleich: oc create secret ... --dry-run=client -o yaml – und dann versiegeln (kubeseal), referenzieren (ESO) oder verschlüsseln (sops -e). Vergleich der drei im Atlas-Diagramm E5, der SOPS-Weg im Compose-Kontext in Secrets-Management.

8 Wie die Bibliothek es macht

Heute noch von Hand – GitOps (und damit ein Modell aus Schritt 7) ist Atlas-Block E.

Jedes Secret gehört genau einem der 8 Dienste, alles im Namespace library – ein kompromittierter Pod sieht nur seine eigenen und die des Namespace, nicht die des ganzen Clusters.

+ Die Kurzfassung