OpenShift Secret Management¶

Introduction¶

Secrets hold credentials, tokens, and certificates for OpenShift workloads. Keep them scoped to the project, mount them only where needed, and avoid printing decoded values in shared logs.

Why This Matters¶

OpenShift adds security defaults such as SCCs, project isolation, and integrated OAuth/RBAC behavior. These protections are useful only when permissions are granted narrowly and verified.

Step-by-Step Configuration¶

oc create secret generic app-db --from-literal=username=app --from-literal=password=change-me -n app

oc set env deployment/web --from=secret/app-db -n app

oc rollout status deployment/web -n app

oc get secret app-db -n app

Example output:

secret/app-db created
deployment.apps/web updated
deployment "web" successfully rolled out

Verification¶

oc get secret app-db -n app

oc describe deployment web -n app

oc exec deploy/web -n app -- printenv username

Security Best Practices¶

Grant the smallest role or SCC that works, prefer service-account-specific access, keep secrets out of Git, and verify permissions with oc auth can-i.

Common Mistakes¶

• Committing secret manifests with real values.
• Using env vars for highly sensitive values when a file mount is safer.
• Sharing oc describe output without checking for exposed metadata.

Troubleshooting¶

Compare the failing user or service account with the role binding, SCC admission error, project quota, or OAuth status shown in OpenShift events.

Related Guides¶

• Openshift Security Context Constraints Explained
• Openshift RBAC Security Explained
• Openshift Security Checklist

Summary¶

OpenShift Secret Management is safest when permissions are explicit, namespace-scoped where possible, and validated from the same identity that runs the workload.