DevSecOps Practice Hub

OpenShift Security

Apply Security Context Constraints, project isolation and integrated build security on OpenShift.

AdvancedOpenShift SecurityContainerInfrastructure

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Deploy Policy enforcement, admission control and infrastructure security.
  • Operate Runtime security, secrets rotation and configuration reconciliation.

Overview

OpenShift adds Security Context Constraints on top of Kubernetes, defaulting workloads to non-root with restricted capabilities, plus integrated registry and build controls.

Why it matters

The restricted-by-default posture prevents many issues, but workarounds that grant permissive SCCs silently undo it.

How it works

  1. 01SCCs define what a pod may request; the restricted-v2 SCC is the default.
  2. 02Projects provide namespace isolation with per-project quotas and roles.
  3. 03The internal registry and image streams gate what can run.

Common tools

OpenShiftKyvernoTrivyFalcoOpenShiftKubernetesRed Hat

Implementation examples

bashAudit permissive SCC bindings
oc get clusterrolebinding -o json \  | jq -r '.items[] | select(.roleRef.name | test("privileged")) | .metadata.name'
Finds bindings that grant the privileged SCC, which should be rare and justified.

Best practices

  • Keep restricted-v2 as the default.
  • Justify and review every privileged SCC binding.

Common mistakes

  • Granting anyuid cluster-wide to fix one image that runs as root.