OCP vs EKS vs AKS — clear, real-world comparison

You’re comparing three ways to run Kubernetes:

• Red Hat OpenShift (OCP) → full enterprise platform
• Amazon EKS → AWS-managed Kubernetes
• Azure Kubernetes Service (AKS) → Azure-managed Kubernetes

One-line mental model

• OCP = Kubernetes + platform + opinionated tooling
• EKS / AKS = Kubernetes as a service

⚙️ Core architecture difference

OpenShift (OCP)

• You manage:
  • cluster (unless using ROSA/ARO)
  • nodes
• Comes with:
  • registry
  • CI/CD
  • security policies
  • operators
• Runs:
  • on-prem, cloud, hybrid

EKS (AWS)

• AWS manages:
  • control plane ✅
• You manage:
  • worker nodes (or use Fargate)
• Uses AWS ecosystem:
  • IAM
  • ALB / NLB
  • VPC networking

AKS (Azure)

• Azure manages:
  • control plane ✅
• You manage:
  • node pools
• Uses Azure ecosystem:
  • Azure AD
  • Load Balancer
  • VNets

Security model

OCP is the most locked-down by default.

Networking & exposure

OCP’s Routes = simpler developer experience
EKS/AKS = more cloud-native integrations

CI/CD & Developer Experience

OCP is a developer platform, not just infra.

Operations & automation

Cost model (important)

• OCP
  • license + infra cost
• EKS
  • control plane fee + AWS resources
• AKS
  • control plane often free + Azure resources

OCP is usually the most expensive.

Where each shines

Use OpenShift when:

• enterprise / regulated environments
• on-prem or hybrid cloud
• need built-in CI/CD + security
• platform engineering teams

Use EKS when:

• you’re deep in AWS ecosystem
• want flexibility + AWS integrations
• prefer DIY platform setup

Use AKS when:

• you’re in Azure ecosystem
• want simplest managed Kubernetes
• using Azure AD, DevOps, etc.

Real-world differences that matter

1. Developer experience

• OCP → “push code → app runs”
• EKS/AKS → you wire everything yourself

2. Security defaults

• OCP → restrictive (safe by default)
• EKS/AKS → flexible (you configure security)

3. Lock-in

• OCP → Red Hat ecosystem
• EKS → AWS lock-in
• AKS → Azure lock-in

Interview-ready answer

“OpenShift is a full Kubernetes platform with built-in CI/CD, registry, and strong security, while EKS and AKS are managed Kubernetes services where the cloud provider manages the control plane. OCP is more opinionated and enterprise-focused, whereas EKS and AKS provide more flexibility but require assembling additional components.”

In OpenShift (OCP), Ingress is the mechanism that allows external traffic (HTTP/HTTPS) to reach services inside your cluster. While Kubernetes has a standard “Ingress” resource, OpenShift has historically used its own evolved version called Routes.

As of 2026, the landscape has expanded to include the Gateway API, which is the modern successor to both.

1. The Three Ways to Expose Apps

2. How the “Router” Works

The Ingress Controller in OCP is an Operator-managed deployment of HAProxy (by default).

• It sits at the edge of the cluster.
• It watches for new Routes or Ingresses.
• It automatically updates its configuration and starts proxying traffic to the correct Pods.

3. Key Concepts for Admins

Ingress Controller Sharding

In large clusters, a single router can become a bottleneck. You can “shard” your ingress traffic by creating multiple Ingress Controllers.

• Example: Create one router for *.public.example.com and a separate, isolated router for *.internal.example.com.
• Benefit: Performance isolation and security (e.g., PCI-compliant traffic on specific nodes).

TLS Termination Patterns

Routes support four types of security:

1. Edge: SSL is decrypted at the Router. Traffic to the Pod is plain HTTP. (Most common).
2. Passthrough: SSL is sent directly to the Pod. The Router doesn’t see the data.
3. Re-encryption: SSL is decrypted at the Router, inspected, then re-encrypted before being sent to the Pod.
4. None: Simple plain HTTP.

4. Interview “Pro” Tips

• The “503 Service Unavailable” Error: If a developer sees this on their Route, it almost always means the Readiness Probe for the Pod is failing. The Router won’t send traffic to a Pod that isn’t “Ready.”
• Host vs Path Routing: OCP Routes excel at host-based routing (app-a.com vs app-b.com). If you need complex path-based routing (e.g., app.com/v1/api going to one service and /v2/api to another), the Gateway API is now the recommended tool over standard Routes.
• Wildcard DNS: OCP creates a default wildcard (e.g., *.apps.cluster.example.com). Every time you create a Route without a host, OCP generates one for you using this pattern.

5. Troubleshooting Command Cheat Sheet

# Check the status of the Ingress Operator
oc get ingresscontroller -n openshift-ingress-operator
# See the HAProxy pods actually doing the work
oc get pods -n openshift-ingress
# Check if a Route is "Admitted" (Successfully configured)
oc get route <route-name> -o yaml | grep -A 5 status
# Look at router logs to see traffic errors
oc logs -n openshift-ingress deployment/router-default
In a high-scale enterprise environment, you often want to isolate traffic. For example, your **Internal HR App** 
shouldn't share the same entry point (the router) as your **Public Marketing Site**. This is called **Ingress Sharding**.
In OpenShift, we achieve this by creating a second **Ingress Controller** and using **Namespace Selectors**.
---
### 1. The Strategy: Router Sharding
By default, OpenShift has a `default` Ingress Controller that handles everything. To split traffic, we will:
1.  Create a new Ingress Controller named `sharded-router`.
2.  Tell it to only watch namespaces with a specific label (e.g., `type: public`).
3.  Label our target namespace.
---
### 2. Implementation Steps
#### **Step A: Label the Namespace**
First, identify which projects should use the new, isolated router.
```bash
oc label namespace my-public-app type=public
```
#### **Step B: Create the New Ingress Controller**
This YAML creates a new set of HAProxy pods that only serve traffic for namespaces with the `type=public` label.
```yaml
apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: sharded-public
  namespace: openshift-ingress-operator
spec:
  domain: public.apps.mycluster.com  # A dedicated subdomain
  endpointPublishingStrategy:
    type: LoadBalancerService       # Creates a new Cloud Load Balancer
  namespaceSelector:
    matchLabels:
      type: public                  # The magic filter
  nodePlacement:                    # Optional: Run on specific "DMZ" nodes
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
```
---
### 3. Verification
Once applied, OpenShift will spin up new pods in the `openshift-ingress` namespace.
* **Check Pods:** `oc get pods -n openshift-ingress` (You'll see `router-sharded-public-...`)
* **Check Load Balancer:** `oc get svc -n openshift-ingress` (You'll see a new service with a unique External IP).
Now, any Route created in the `my-public-app` namespace will be picked up by the **new** router and ignored by the **default** one.
---
### 💡 Interview Questions on Sharding
* **Q: Why would you shard an Ingress Controller?**
    * **A:** For **Security** (isolating internal vs. external traffic), **Performance** (preventing a noisy neighbor from hogging the CPU/bandwidth of the router), and **Compliance** (ensuring certain data only flows through nodes that meet specific regulatory standards).
* **Q: How does the Route know which router to use?**
    * **A:** The Route doesn't "choose." The **Ingress Controllers** choose the Routes based on the `namespaceSelector` or `routeSelector` defined in their configuration.
* **Q: Can a single Route be served by two different Routers?**
    * **A:** Yes, if both Ingress Controllers have selectors that match that Route's namespace or labels. This is sometimes used during migrations.
---

OpenShift (OCP) Architecture — Clear, Practical Breakdown

Red Hat OpenShift (OCP) is a Kubernetes-based platform with extra layers for:

• security
• developer workflows
• enterprise operations

Think of it as:

Kubernetes + opinionated enterprise tooling + automation

High-Level Architecture

At the highest level, OpenShift has 3 main layers:

1. Control Plane (Master Nodes)

Manages the cluster

2. Worker Nodes

Run your applications

3. Infrastructure Layer

Networking, storage, registry, ingress

1. Control Plane (Master Nodes)

Core brain of the cluster:

Key components:

• kube-apiserver
  • entry point for all API calls
• etcd
  • stores cluster state
• kube-scheduler
  • assigns pods to nodes
• kube-controller-manager
  • maintains desired state

OpenShift-specific additions:

• OpenShift API Server
  • adds OCP-specific APIs (routes, builds, etc.)
• Controller Manager (OpenShift)
  • handles builds, deployments, image streams

2. Worker Nodes

Where workloads run.

Components:

• kubelet
  • manages pods on node
• Container runtime
  • usually CRI-O (default in OpenShift)
• Pods
  • your apps + sidecars

3. Networking Layer

Key pieces:

• Cluster Network
  • pod-to-pod communication
• Service Network
  • stable virtual IPs
• Ingress / Routes (OpenShift-specific)

OpenShift uses Routes instead of standard Ingress:

• external traffic → router → service → pod

OpenShift Router (Ingress Controller)

• based on HAProxy
• handles:
  • TLS termination
  • load balancing
  • external exposure

4. Image & Build System (OCP unique)

This is where OpenShift stands out.

Image Registry

• internal container registry

Image Streams

• track image versions
• trigger deployments automatically

BuildConfig

• builds images from:
  • Git
  • Dockerfile
  • Source-to-Image (S2I)

5. Security Layer (very important)

OpenShift is stricter than Kubernetes.

Features:

• Security Context Constraints (SCC)
  • control what pods can do
  • similar to Pod Security Policies
• No root containers by default
• SELinux enforced
• integrated RBAC

6. Operators (Automation Engine)

OpenShift heavily uses Operators.

• manage apps like:
  • databases
  • monitoring
  • logging

Built-in operators:

• cluster version operator
• ingress operator
• etc.

7. Observability & Logging

Built-in:

• Prometheus (monitoring)
• Grafana (dashboards)
• EFK / Loki stack (logging)

Full Flow Example

Deploying an app:

1. Push code to Git
2. BuildConfig builds image
3. Image stored in registry
4. Deployment created
5. Pod runs on worker node
6. Service exposes pod internally
7. Route exposes app externally

OpenShift vs Kubernetes (quick view)

Simple mental model

• Kubernetes = engine
• OpenShift = full platform

Interview-ready summary

“OpenShift architecture is built on Kubernetes with control plane and worker nodes, but adds enterprise features like integrated registry, build pipelines, enhanced security via SCC, and a routing layer for external traffic. It also uses operators extensively to automate cluster management.”

For an OpenShift (OCP) interview in 2026, you should expect questions that move beyond basic Kubernetes concepts and focus on enterprise operations, automation (Operators), and security.

Here is a curated list of high-value interview questions categorized by role and complexity.

1. Architectural Concepts

• What is the role of the Cluster Version Operator (CVO)?
  • Answer: The CVO is the heart of OCP 4.x upgrades. It monitors the “desired state” of the cluster’s operators (the “payload”) and ensures the cluster is updated in a safe, coordinated manner across all components.
• Explain the difference between an Infrastructure Node and a Worker Node.
  • Answer: Infrastructure nodes are used to host “cluster-level” services like the Router (Ingress), Monitoring (Prometheus/Grafana), and Registry. By labeling nodes as infra, companies can often save on Red Hat subscription costs, as these nodes typically don’t require the same licensing as nodes running application workloads.
• What is the “Etcd Quorum” and why is it important in OCP?
  • Answer: OpenShift typically requires an odd number of Control Plane nodes (usually 3) to maintain a quorum in the etcd database. If you lose more than half of your masters, the cluster becomes read-only to prevent data corruption.

2. Networking & Traffic (The Gateway API Era)

• Explain Ingress vs. Route vs. Gateway API. (See previous discussion)
  • Key Focus: Interviewers want to know if you understand that Routes are OCP-native, Ingress is K8s-standard, and Gateway API is the future standard for advanced traffic management (canary, mirroring, etc.).
• How does “Service Serving Certificate Secrets” work in OCP?
  • Answer: OCP can automatically generate a TLS certificate for a Service. You annotate a Service with service.beta.openshift.io/serving-cert-secret-name. OCP then creates a secret containing a cert/key signed by the internal Cluster CA, allowing for easy end-to-end encryption.

3. Security (The “Hardest” Category)

• Scenario: A developer says their pod won’t start because of a “Security Context” error. What do you check?
  • Answer: I would check the Security Context Constraints (SCC). By default, OCP runs pods with the restricted-v2 SCC, which prevents running as root. If the pod requires root or host access, I’d check if the ServiceAccount has been granted a more permissive SCC like anyuid or privileged.
• What are NetworkPolicies vs. EgressFirewalls?
  • Answer: NetworkPolicies control traffic between pods inside the cluster (East-West). EgressFirewalls (part of OCP’s OVN-Kubernetes) control traffic leaving the cluster to external IPs or CIDR blocks (North-South).

4. Troubleshooting & Operations

• How do you recover a cluster if the Control Plane certificates have expired?
  • Answer: This usually involves using the oc adm certificate approve command to approve pending CSRs (Certificate Signing Requests) or manually rolling back the cluster clock if it’s an emergency. OCP 4.x generally tries to auto-renew these, but clock drift can break it.
• Describe the Source-to-Image (S2I) workflow.
  • Answer: S2I takes source code from Git, injects it into a “builder image” (like Node.js or Java), and outputs a ready-to-run container image. It simplifies the CI/CD process for developers who don’t want to write Dockerfiles.

5. Advanced / 2026 Trends

• What is OpenShift Virtualization (KubeVirt)?
  • Answer: It allows you to run legacy Virtual Machines (VMs) as pods on OpenShift. This is critical for “modernizing” apps where one part is a container and the other is a legacy Windows or Linux VM that can’t be containerized yet.
• How does Red Hat Advanced Cluster Management (RHACM) help in a multi-cluster setup?
  • Answer: RHACM provides a single pane of glass to manage security policies, application placement, and cluster lifecycle (creation/deletion) across multiple OCP clusters on AWS, Azure, and on-prem.

Quick Tip for the Interview

Whenever you answer, use the phrase “Operator-led design.” OpenShift 4 is built entirely on Operators. If the interviewer asks, “How do I fix the registry?” the best answer starts with, “I would check the status of the Image Registry Operator using oc get clusteroperator.” This shows you understand the fundamental architecture of the platform.

As an OpenShift Administrator, your interview will focus heavily on cluster stability, lifecycle management (upgrades), security enforcement, and the “Day 2” operations that keep an enterprise cluster running.

Here are the top admin-focused interview questions for 2026, divided by functional area.

1. Cluster Lifecycle & Maintenance

• How does the Cluster Version Operator (CVO) manage upgrades, and what do you check if an upgrade hangs at 57%?
  • Answer: The CVO coordinates with all other cluster operators to reach a specific “desired version.” If it hangs, I check oc get clusteroperators to see which specific operator is degraded. Usually, it’s the Machine Config Operator (MCO) waiting for nodes to drain or the Authentication Operator having issues with etcd.
• What is the “Must-Gather” tool, and when would you use it?
  • Answer: oc adm must-gather is the primary diagnostic tool. It launches a pod that collects logs, CRD states, and operating system debugging info. I use it before opening a Red Hat support ticket or when a complex issue involves multiple operators.
• Explain how to back up and restore the etcd database.
  • Answer: I use the etcd-snapshot.sh script provided on the control plane nodes. For restoration, I must stop the static pods for the API server and etcd, then use the backup to restore the data directory. It’s critical to do this on a single control plane node first to re-establish a quorum.

2. Node & Infrastructure Management

• What is a MachineConfigPool (MCP), and why would you pause it?
  • Answer: An MCP groups nodes (like master or worker) so the MCO can apply configurations to them. I would pause an MCP during a sensitive maintenance window or when troubleshooting a configuration change that I don’t want to roll out to all nodes at once.
• How do you add a custom SSH key or a CronJob to the underlying RHCOS nodes?
  • Answer: You don’t log into the nodes manually. You create a MachineConfig YAML. The MCO then detects this, reboots the nodes (if necessary), and applies the change to the immutable filesystem.
• What happens if a node enters a NotReady state?
  • Answer: First, I check node pressure (CPU/Memory/Disk). Then I check the kubelet and crio services on the node using oc debug node/<node-name>. I also check for network reachability between the node and the Control Plane.

3. Networking & Security

• What is the benefit of OVN-Kubernetes over the legacy OpenShift SDN?
  • Answer: OVN-K is the default in 4.x. It supports modern features like IPsec encryption for pod-to-pod traffic, smarter load balancing, and Egress IPs for specific projects to exit the cluster via a fixed IP address for firewall white-listing.
• A user is complaining they can’t reach a service in another project. What do you check?
  • Answer:
    1. NetworkPolicies: Is there a policy blocking “Cross-Namespace” traffic?
    2. Service/Endpoints: Does the Service have active Endpoints (oc get endpoints)?
    3. Namespace labels: If using a high-isolation network plugin, do the namespaces have the correct labels to “talk” to each other?
• How do you restrict a specific group of users from creating LoadBalancer type services?
  • Answer: I would use an Admission Controller or a specialized RBAC role that removes the update/create verbs for the services/status resource, or more commonly, use a Policy Engine like Gatekeeper/OPA to deny the request.

4. Storage & Capacity Planning

• How do you handle “Volume Expansion” if a database runs out of space?
  • Answer: If the underlying StorageClass supports allowVolumeExpansion: true, I simply edit the PersistentVolumeClaim (PVC) and increase the storage value. OpenShift and the CSI driver handle the resizing of the file system on the fly.
• What is the difference between ReadWriteOnce (RWO) and ReadWriteMany (RWX)?
  • Answer: RWO allows only one node to mount the volume (good for databases). RWX allows multiple nodes/pods to mount it simultaneously (required for shared file storage like NFS or ODF).

5. Scenario-Based: “The Midnight Call”

• Scenario: The Web Console is down, and oc commands are timing out. Where do you start?
  • Answer: This sounds like an API Server or etcd failure. I would:
    1. Log into a Control Plane node directly via SSH.
    2. Check the status of static pods in /etc/kubernetes/manifests.
    3. Run crictl ps to see if the kube-apiserver or etcd containers are crashing.
    4. Check the node’s disk space (etcd often fails if the disk is 100% full).

Pro-Tip for Admin Interviews:

In 2026, emphasize GitOps. Mention that you prefer managing cluster configurations (like HTPasswd providers or Quota objects) via ArgoCD rather than manual oc apply commands. This shows you are an admin who values Idempotency and Disaster Recovery.

Flux (or FluxCD) is a GitOps continuous delivery tool for Kubernetes. Here’s a concise breakdown:

What it does

Flux is an operator that runs in your Kubernetes cluster, constantly comparing the cluster’s live state to the state defined in your Git repo. If they differ, Flux automatically makes changes to the cluster to match the repo. In other words, Git is the single source of truth — you push a change to Git, Flux detects it and applies it to the cluster automatically, with no manual kubectl apply needed.

How it works — core components

Core components of FluxCD (the GitOps Toolkit) include the Source Controller, Kustomize Controller, Helm Controller, and Notification Controller. Each is a separate Kubernetes controller responsible for one concern:

• Source Controller — watches Git repos, Helm repos, OCI registries, and S3 buckets for changes
• Kustomize Controller — applies raw YAML and Kustomize overlays to the cluster
• Helm Controller — manages HelmRelease objects (declarative Helm chart deployments)
• Notification Controller — sends alerts to Slack, Teams, etc. when syncs succeed or fail

Key characteristics

• Pull-based model: Flux enables pure pull-based GitOps application deployments — no access to clusters is needed by the source repo or by any other cluster. This is more secure than push-based pipelines where your CI system needs cluster credentials.
• Drift detection: If your live cluster diverges from Git (e.g., due to manual edits), Flux will detect the drift and revert it, ensuring deterministic deployments.
• Kubernetes-native: Flux v2 is built from the ground up to use Kubernetes’ API extension system. Everything is a CRD — GitRepository, Kustomization, HelmRelease, etc.
• Security-first: Flux uses true Kubernetes RBAC via impersonation and supports multiple Git repositories. It follows a pull vs. push model, least amount of privileges, and adheres to Kubernetes security policies with tight integration with security tools.
• Multi-cluster: Flux can use one Kubernetes cluster to manage apps in either the same or other clusters, spin up additional clusters, and manage cluster fleets.

CNCF standing & adoption

Flux is a Cloud Native Computing Foundation (CNCF) graduated project, used in production by various organisations and cloud providers. Notable users include Deutsche Telekom (managing 200+ clusters with just 10 engineers), the US Department of Defense, and Microsoft Azure (which uses Flux natively in AKS and Azure Arc).

Flux vs. Argo CD (the main alternative)

Flux CD is highly composable — use only the controllers you need. It’s preferred by teams who already think in CRDs and reconciliation loops, and is excellent for infrastructure-as-code and complex dependency handling. The main trade-off is that Flux has some drawbacks such as lack of a native UI and a steep learning curve. Argo CD is the better choice if your team wants a rich visual dashboard out of the box.

Relation to OCP

Flux is commonly used with OpenShift as the GitOps engine for managing cluster configuration and application deployments. Red Hat also ships OpenShift GitOps (based on Argo CD) as an official operator, so in OCP environments you’ll encounter both — Flux tends to be chosen by platform engineering teams who want tighter Kubernetes-native control, while OpenShift GitOps is the supported out-of-the-box option from Red Hat.

Here’s a thorough breakdown of how Flux integrates with OCP:

Installation — two options

Option 1: Flux Operator via OperatorHub (recommended)

Flux can be installed on a Red Hat OpenShift cluster directly from OperatorHub using the Flux Operator — an open-source project part of the Flux ecosystem that provides a declarative API for the lifecycle management of the Flux controllers on OpenShift.

Once installed, you declare a FluxInstance CR with cluster.type: openshift:

apiVersion: fluxcd.controlplane.io/v1
kind: FluxInstance
metadata:
  name: flux
  namespace: flux-system
spec:
  distribution:
    version: "2.x"
    registry: "ghcr.io/fluxcd"
  cluster:
    type: openshift       # ← tells Flux it's on OCP
    multitenant: true
    networkPolicy: true
  sync:
    kind: GitRepository
    url: "https://my-git-server.com/my-org/my-fleet.git"
    ref: "refs/heads/main"
    path: "clusters/my-cluster"

Option 2: flux bootstrap CLI

The best way to install Flux on OpenShift via CLI is to use the flux bootstrap command. This command works with GitHub, GitLab, as well as generic Git providers. You require cluster-admin privileges to install Flux on OpenShift.

The OCP-specific challenge: SCCs

OCP’s default restricted-v2 SCC blocks containers from running as root — and Flux controllers, like many Kubernetes tools, need specific adjustments to run cleanly. The official integration handles this by:

• Shipping a scc.yaml manifest that grants Flux controllers the correct non-root SCC permissions
• Patching the Kustomization to remove the default SecComp profile and enforce the correct UID expected by Flux images, preventing OCP from altering the container user

The cluster.type: openshift flag in the FluxInstance spec automatically applies these adjustments — no manual SCC patching needed when using the Flux Operator.

What the integration looks like end-to-end

┌─────────────────────────────────────────────────────┐
│                   Git Repository                     │
│  clusters/my-cluster/                               │
│    ├── flux-system/   (Flux bootstrap manifests)    │
│    ├── namespaces/    (OCP Projects)                │
│    ├── rbac/          (Roles, RoleBindings, SCCs)   │
│    └── apps/          (Deployments, Routes, etc.)   │
└────────────────────┬────────────────────────────────┘
                     │  pull (every ~1 min)
                     ▼
┌─────────────────────────────────────────────────────┐
│              OCP Cluster (flux-system ns)           │
│  source-controller   → watches Git/OCI/Helm repos  │
│  kustomize-controller→ applies YAML/Kustomize       │
│  helm-controller     → manages HelmReleases         │
│  notification-ctrl   → sends alerts to Slack etc.  │
└─────────────────────────────────────────────────────┘

Multi-tenancy on OCP

When multitenant: true is set, Flux uses true Kubernetes RBAC via impersonation — meaning each tenant’s Kustomization runs under its own service account, scoped to its own namespace. This maps naturally to OCP Projects, where each team or app gets an isolated namespace with its own SCC and RBAC policies.

The pattern looks like this in Git:

# tenants/team-a/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-a-apps
  namespace: flux-system
spec:
  serviceAccountName: team-a-reconciler  # impersonates this SA
  targetNamespace: team-a               # deploys into this OCP Project
  path: ./tenants/team-a/apps
  sourceRef:
    kind: GitRepository
    name: fleet-repo

Each team-a-reconciler service account only has permissions within team-a‘s namespace — enforced by both RBAC and the namespace’s SCC policies.

Key considerations for OCP + Flux

Identity & Access Control

• RBAC & Least Privilege: Every user, service account, and process should possess only the absolute minimum permissions needed. Isolate workloads using distinct service accounts, each bound to Roles containing relevant permissions, and avoid attaching sensitive permissions directly to user accounts.
• Strong Authentication: Implement robust authentication mechanisms such as multi-factor authentication (MFA) or integrate with existing identity management systems to prevent unauthorized access.
• Audit Regularly: Regularly audit Roles, ClusterRoles, RoleBindings, and SCC usage to ensure they remain aligned with the principle of least privilege and current needs.
• Avoid kubeadmin: Don’t use the default kubeadmin superuser account in production — integrate with an enterprise identity provider instead.

Cluster & Node Hardening

• Use RHCOS for nodes: It is best to leverage OpenShift’s relationship with cloud providers and use the most recent Red Hat Enterprise Linux CoreOS (RHCOS) for all OCP cluster nodes. RHCOS is designed to be as immutable as possible, and any changes to the node must be authorized through the Red Hat Machine Operator — no direct user access needed.
• Control plane HA: A minimum of three control-plane nodes should be configured to allow accessibility in a node outage event.
• Network isolation: Strict network isolation prevents unauthorized external ingress to OpenShift cluster API endpoints, nodes, or pod containers. The DNS, Ingress Controller, and API server can be set to private after installation.

Container Image Security

• Scan images continuously: Use image scanning tools to detect vulnerabilities and malware within container images. Use trusted container images from reputable sources and regularly update them to include the latest security patches.
• Policy enforcement: Define and enforce security policies for container images, ensuring that only images meeting specific criteria — such as being signed by trusted sources or containing no known vulnerabilities — are deployed.
• No root containers: OpenShift has stricter security policies than vanilla Kubernetes — running a container as root is forbidden by default.

Security Context Constraints (SCCs)

OpenShift uses Security Context Constraints (SCCs) that give your cluster a strong security base. By default, OpenShift prevents cluster containers from accessing protected Linux features such as shared file systems, root access, and certain core capabilities like the KILL command. Always use the most restrictive SCC that still allows your workload to function.

Network Security

• Zero-trust networking: Apply granular access controls between individual pods, namespaces, and services in Kubernetes clusters and external resources, including databases, internal applications, and third-party cloud APIs.
• Use NetworkPolicies to restrict east-west traffic between namespaces and pods by default.
• Egress control: Use Egress Gateways or policies to control outbound traffic from pods.

Compliance & Monitoring

• Compliance Operator: The OpenShift Compliance Operator supports profiles for standards including PCI-DSS versions 3.2.1 and 4.0, enabling automated compliance scanning across the cluster.
• Continuous monitoring: Use robust logging and monitoring solutions to gain visibility into container behavior, network flows, and resource utilization. Set up alerts for abnormalities like unusually high memory or CPU usage that could indicate compromise.
• Track CVEs proactively: Security, bug fix, and enhancement updates for OCP are released as asynchronous errata through the Red Hat Network. Registry images should be scanned upon notification and patched if affected by new vulnerabilities.

Namespace & Project Isolation

Using projects and namespaces simplifies management and enhances security by limiting the potential impact of compromised applications, segregating resources based on application/team/environment, and ensuring users can only access the resources they are authorized to use.

Key tools to leverage: Advanced Cluster Security (ACS/StackRox), Compliance Operator, OpenShift built-in image registry with scanning, and NetworkPolicy/Calico for zero-trust networking.

SCCs (Security Context Constraints) are OpenShift’s pod-level security gate — separate from RBAC. The golden rules are: always start from restricted-v2, never modify built-in SCCs, create custom ones when needed, assign them to dedicated service accounts (not users), and never grant anyuid or privileged to app workloads.

RBAC controls what users and service accounts can do via the API. The key principle is deny-by-default — bind roles to groups rather than individuals, keep bindings namespace-scoped unless cross-namespace is genuinely needed, audit regularly with oc auth can-i and oc policy who-can, and never touch default system ClusterRoles.

Network Policies implement microsegmentation at the pod level. The pattern is always: default-deny first, then explicitly open only what’s needed — ingress from the router, traffic from the same namespace, and specific app-to-app flows. For egress, use EgressNetworkPolicy to whitelist specific CIDRs or domains and block everything else.

All three layers work together: RBAC controls the API plane, SCCs control the node plane, and NetworkPolicies control the network plane. A strong OCP security posture needs all three.