🧠 Deploying a Secure OpenShift Cluster with TLS and SCCs

1. Introduction to the OpenShift Security Model

OpenShift’s security architecture is built on Red Hat’s Kubernetes foundation, but with stronger guardrails:

• SCCs (Security Context Constraints) define what pods can and cannot do.

• RBAC controls who can perform cluster operations.

• TLS Everywhere ensures encrypted communication between API server, nodes, pods, and external clients.

• OAuth & Identity Providers ensure secure authentication.

In a real-world enterprise environment, failing to configure TLS or SCCs properly can expose your cluster to privilege escalation, MITM attacks, or container breakout risks.

2. Step-by-Step TLS Setup in OpenShift

Step 1: Generate TLS Certificates

Use your organization’s CA or OpenShift’s oc commands:

Step 2: Apply Certificates to the API Server

Edit the cluster API configuration:

Update the following:

Apply the TLS cert as a secret:

Step 3: Configure Ingress TLS

Edit the Ingress Controller:

Add:

Step 4: Verify TLS

3. SCCs: Default vs Custom

OpenShift ships with built-in SCCs like:

• restricted (recommended default)

• anyuid (dangerous if misused)

• privileged (full host access)

• hostnetwork / hostaccess

Create a Custom SCC

Example: Allow non-root containers but restrict host access.

Apply:

Assign the SCC to a service account:

4. Useful oc Commands

Check SCC assigned to a pod

List all SCCs

Test TLS connectivity

5. Troubleshooting Common Errors

❗ “x509: certificate signed by unknown authority”

• Missing CA trust on clients

• Wrong certificate CN/SAN

• Solution → Re-issue certs with proper DNS entries

❗ Pods stuck in CreateContainerConfigError

• Wrong or missing SCC permissions

• Solution → Assign correct SCC to the ServiceAccount

❗ Ingress routes show default backend - 404

• Router pod failed to load TLS cert

• Solution → Check ingress secret name and cert chain