OpenShift Security Context Constraints (SCC)

Learn Security Context Constraints (SCC) in OpenShift, understand how SCC secures containers, compare SCC with Kubernetes Pod Security, configure Spring Boot applications, and implement enterprise security best practices.

Introduction

Security is one of the biggest differences between Kubernetes and OpenShift.

In Kubernetes, a container can often run as the root user unless restricted by security policies.

OpenShift follows a much more secure approach.

By default:

Containers run as non-root users
Privileged containers are restricted
Host filesystem access is blocked
Linux capabilities are limited
Sensitive host resources are protected

These security controls are enforced through Security Context Constraints (SCCs).

SCCs are one of the most important OpenShift security features and are commonly discussed in OpenShift interviews.

Learning Objectives

By the end of this article, you will understand:

What is SCC?
Why SCC is required
SCC Architecture
How SCC works
Default SCCs
Running containers as non-root
Privileged containers
Service Account integration
Spring Boot deployment
Enterprise security best practices

Why Do We Need SCC?

Imagine a malicious container running as the Linux root user.

flowchart LR
    A[Container]
    --> B[Root User]

    B --> C[Host Operating System]

    C --> D[Security Risk]

Potential attacks:

Delete host files
Modify kernel settings
Access other containers
Escalate privileges

SCC prevents these scenarios.

SCC Architecture

flowchart TD
    Developer[Developer]

    --> Deployment

    Deployment

    --> Pod

    Pod

    --> ServiceAccount

    ServiceAccount

    --> SCC

    SCC

    --> KubernetesNode

Every Pod must satisfy an SCC before it is created.

Pod Creation Flow

sequenceDiagram
    participant Developer
    participant API
    participant SCC
    participant Pod

    Developer->>API: Create Deployment

    API->>SCC: Validate Security Rules

    SCC-->>API: Allow / Deny

    API-->>Pod: Create Pod

If the Pod violates the assigned SCC, creation fails.

What is a Security Context Constraint?

A Security Context Constraint (SCC) is an OpenShift security policy that controls how Pods and containers are allowed to run.

It defines rules such as:

User ID (UID)
Group ID (GID)
Privileged Mode
Linux Capabilities
Host Networking
Host Volumes
SELinux Context
Filesystem Access

SCC vs Kubernetes Pod Security

Kubernetes	OpenShift
Pod Security Admission	Security Context Constraints (SCC)
Namespace Policies	SCC Policies
Standard Kubernetes	OpenShift Specific
Policy Based	Role Based + SCC

OpenShift adds SCC as an additional security layer.

Default SCCs

Common SCCs:

SCC	Purpose
restricted-v2	Default secure policy
restricted	Legacy secure policy
nonroot	Force non-root containers
anyuid	Allow any Linux UID
privileged	Full host access
hostnetwork	Allow host networking
hostmount-anyuid	Host volume access

Most Spring Boot applications should use restricted-v2.

Default SCC Architecture

flowchart LR
    SpringBootPod

    --> restricted-v2

    restricted-v2

    --> Node

Running as Non-Root

One of the most important OpenShift security rules:

Applications should not run as root.

flowchart LR
    Root["UID 0"]

    --> Blocked["❌ Blocked"]

    NonRoot["UID 1001"]

    --> Allowed["✅ Allowed"]

Spring Boot Dockerfile

Bad Example

FROM eclipse-temurin:21-jdk

USER root

OpenShift will likely reject this image.

Correct Dockerfile

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/app.jar app.jar

USER 1001

ENTRYPOINT ["java","-jar","app.jar"]

Running as a non-root user is recommended.

Security Context

Deployment YAML

securityContext:

  runAsNonRoot: true

  allowPrivilegeEscalation: false

  readOnlyRootFilesystem: true

These settings improve container security.

Security Context Architecture

flowchart TD
    Pod

    --> SecurityContext

    SecurityContext

    --> NonRoot

    SecurityContext

    --> ReadOnlyFS

    SecurityContext

    --> NoPrivilegeEscalation

Privileged Containers

Some system-level workloads require privileged access.

flowchart LR
    Container

    --> Privileged

    --> HostOS

Privileged containers can:

Access devices
Modify networking
Load kernel modules

Avoid them for business applications.

Privileged Example

securityContext:

  privileged: true

Only cluster administrators should grant this permission.

Read-Only Root Filesystem

Prevent applications from modifying container files.

securityContext:

  readOnlyRootFilesystem: true

Benefits:

Prevent malware
Protect container image
Improve compliance

Linux Capabilities

Linux capabilities divide root privileges into smaller permissions.

Examples:

NET_ADMIN
SYS_TIME
SYS_ADMIN
CHOWN

Drop unnecessary capabilities.

securityContext:

  capabilities:

    drop:

    - ALL

Host Network

Normal Pods:

flowchart LR
    Pod

    --> PodNetwork

Host Network:

flowchart LR
    Pod

    --> HostNetwork

    --> Node

Avoid Host Networking unless absolutely necessary.

HostPath Volumes

Bad architecture:

flowchart LR
    Pod

    --> HostFilesystem

This allows direct access to the host.

Prefer:

flowchart LR
    Pod

    --> PVC

    --> Storage

Service Account and SCC

SCCs are assigned through Service Accounts.

flowchart LR
    ServiceAccount

    --> SCC

    SCC

    --> Pod

Each Service Account can use one or more SCCs.

View SCCs

oc get scc

Example:

restricted-v2

restricted

anyuid

privileged

Describe SCC

oc describe scc restricted-v2

Displays:

Allowed Users
Capabilities
Volumes
UID Rules

Assign SCC

Grant anyuid.

oc adm policy add-scc-to-user anyuid \
-z payment-service-account

Only use this when necessary.

Verify SCC

oc describe pod payment-api

Look for:

openshift.io/scc=restricted-v2

Banking Example

flowchart TD
    PaymentService

    --> ServiceAccount

    --> restricted-v2

    --> Pod

    --> OracleDB

Applications cannot access host resources.

Enterprise Architecture

flowchart TD
    Developer

    --> Git

    --> Jenkins

    --> OpenShift

    --> SCC

    --> SpringBootPod

    SpringBootPod

    --> ConfigMap

    SpringBootPod

    --> Secret

    SpringBootPod

    --> PostgreSQL

Every Pod is validated before deployment.

Common Problems

Pod Creation Failed

Example:

Error creating Pod:

SecurityContextConstraints validation failed

Possible causes:

Running as root
Privileged container
Invalid UID
HostPath usage

Permission Denied

Check:

oc describe pod payment-api

Verify assigned SCC.

Docker Image Runs as Root

Fix Dockerfile.

Use:

USER 1001

instead of:

USER root

Useful Commands

List SCCs

oc get scc

Describe SCC

oc describe scc restricted-v2

Describe Pod

oc describe pod payment-api

List Service Accounts

oc get sa

Best Practices

Always run containers as non-root.
Use the default restricted-v2 SCC whenever possible.
Avoid privileged containers.
Disable privilege escalation.
Use read-only root filesystems.
Drop unnecessary Linux capabilities.
Avoid HostPath volumes.
Assign SCCs through Service Accounts.
Audit SCC usage regularly.

Common Mistakes

❌ Running Spring Boot applications as root.

❌ Using the privileged SCC for business applications.

❌ Allowing HostPath mounts without justification.

❌ Granting the anyuid SCC to every application.

❌ Ignoring container security warnings.

Advantages

Strong container isolation
Protection against privilege escalation
Improved compliance
Secure multi-tenancy
Reduced attack surface
Enterprise-grade security
OpenShift-native protection
Safer application deployments

Summary

Security Context Constraints are a core security feature of OpenShift that enforce safe container execution.

Key takeaways:

SCCs define how Pods and containers are allowed to run.
The restricted-v2 SCC is the recommended default for most Spring Boot applications.
Applications should run as non-root users with minimal privileges.
Service Accounts determine which SCCs a Pod can use.
Proper SCC configuration significantly strengthens the security posture of OpenShift workloads.

Interview Questions

What is a Security Context Constraint (SCC)?
How does SCC differ from Kubernetes Pod Security Admission?
Why should containers run as non-root users?
What is the purpose of the restricted-v2 SCC?
When should the anyuid SCC be used?
What are privileged containers?
Why should HostPath volumes be avoided?
How are SCCs assigned to Pods?
How do you verify which SCC a Pod is using?
What are the best practices for securing Spring Boot applications with SCCs?