Security in OpenShift

How Security Works in OpenShift

Security in OpenShift is not an afterthought or an optional add-on. It is designed as a built-in, layered model that spans:

• The cluster and its control plane
• The applications and containers running in it
• The users and automation interacting with it
• The software supply chain that feeds it

This chapter gives a conceptual overview of OpenShift’s security model and where the main mechanisms (covered in later subsections) fit into that model.

Core Principles of OpenShift Security

OpenShift’s security design is largely driven by a few core principles:

• Secure by default: Many potentially risky capabilities are disabled or constrained out of the box (for example, containers are not allowed to run as root by default).
• Least privilege: Users, service accounts, and workloads are given only the permissions they need to perform their tasks, enforced through RBAC and Security Context Constraints.
• Multi-tenancy and isolation: Multiple teams and applications can share a cluster while being logically and, where needed, network-level isolated.
• Defense in depth: Multiple layers of protection (identity, network, runtime, image, storage, audit, etc.) limit the impact of misconfigurations or compromises.
• Policy-driven: Security behavior is encoded as declarative policy (YAML resources, Operator-managed components) that can be versioned, reviewed, and automated.

Understanding these principles helps interpret why certain defaults and restrictions exist in OpenShift and how to work with them rather than against them.

Security Layers in an OpenShift Cluster

OpenShift security can be thought of in several interlocking layers. Later subsections of this module go deeper into specific mechanisms; here the focus is the overall picture.

1. Identity and Access at the Cluster Level

At the outermost layer, OpenShift controls:

• Who can access the cluster (users, service accounts, automation)
• What they can do (permissions to read, modify, or administer resources)

Key ideas:

• Authentication: Verifying identity (for example, via OAuth, external providers like LDAP/OIDC, or kubeconfigs).
• Authorization: Determining if an authenticated identity is allowed to perform a given action on a resource, based on Kubernetes-style RBAC.
• Separation between human and non-human identities: People use user accounts; workloads use service accounts. These are distinct and governed by different policies.

Later in this module, Role-Based Access Control is treated in detail; here it is enough to recognize that most security-sensitive actions in OpenShift pass through this gate.

2. Project and Namespace Isolation

OpenShift uses projects (Kubernetes namespaces with additional metadata and policy) as the main multi-tenancy boundary for workloads.

Security implications of this boundary include:

• Objects (pods, services, routes, etc.) are isolated per project; by default, one project cannot modify another’s resources.
• Access control (RBAC) often uses projects as a scope: for example, granting a user admin in a single project but not cluster-wide.
• Network policies and Security Context Constraints can be applied differently per project, enabling different security postures for dev, test, and prod spaces.

From a security perspective, proper project design helps:

• Limit the blast radius of a compromised application
• Separate duties between teams
• Enforce different policies in different environments

3. Workload and Container Runtime Security

OpenShift puts strong guardrails around how containers run:

• Default non-root execution: Pods are often denied the ability to run as UID 0 (root) unless explicitly allowed by policy.
• Restricted capabilities: Linux capabilities, privilege escalation, and host-level access (host networking, host PID/IPC) are curbed by default.
• Mandatory use of Security Context Constraints (SCCs): SCCs define what is allowed for pods: user IDs, volume types, privilege level, SELinux contexts, and so on.

This layer aims to ensure that even if application code is vulnerable, the container’s ability to harm the host or other workloads is limited.

Later in this module, Security Context Constraints are covered in more detail; for now, understand them as a key OpenShift-specific policy mechanism around workload execution.

4. Network and Traffic Control

Network security in OpenShift focuses on:

• Controlling which pods and services can talk to which others
• Defining how and when external traffic can reach workloads

Important aspects:

• Intra-cluster isolation: By default in many configurations, pods may communicate freely across namespaces; network policies can be used to restrict this.
• Perimeter exposure: Only certain objects (like routes or ingress) are intended to expose applications externally.
• Integration with underlying network plugins and load balancers to enforce segmentation, encryption, or traffic shaping as required.

From a security standpoint, fine-grained network controls:

• Reduce lateral movement possibilities in case of compromise
• Allow implementing zero-trust style communication patterns

Network security specifics, including policies and ingress behavior, are expanded upon in the dedicated network security subsection.

5. Image and Supply Chain Security

OpenShift recognizes that the code and images you run are a major source of risk. Security in this area focuses on:

• Image provenance: Where images come from (trusted registries vs unknown public sources).
• Image scanning: Detecting known vulnerabilities (CVEs), misconfigurations, or embedded secrets.
• Image policy enforcement: Preventing the use of images that are out-of-policy (for example, unscanned or from unapproved registries).

Common patterns include:

• Using internal registries and image streams as controlled sources.
• Integrating scanners and admission policies to block risky images from being deployed.
• Combining CI/CD with image security so that vulnerabilities are identified early.

Later in this module, image security and scanning are explored in-depth.

6. Configuration and Secret Handling

Applications need configuration, credentials, and sensitive keys. OpenShift provides mechanisms to:

• Separate static configuration from code (for example, in ConfigMaps).
• Keep sensitive data in dedicated objects (Secrets) that have stricter handling.
• Control how and where such data is projected into running pods (environment variables, files, volumes).

From a security perspective:

• Proper use of Secrets reduces accidental exposure of credentials in images, logs, or source control.
• Access to configuration objects is subject to RBAC, allowing fine-grained control over who can read what.

While this course has a separate module for configuration and secrets management, in the security context the important point is: use the platform’s dedicated mechanisms, not ad-hoc approaches.

7. Platform Hardening and Node Security

Beneath the Kubernetes and OpenShift abstractions, the cluster runs on operating systems and hosts that must be hardened.

Security-related aspects include:

• Using hardened, minimal host operating systems (e.g. Red Hat Enterprise Linux CoreOS in many OpenShift deployments).
• Managing OS patches and kernel updates, often through cluster-managed over-the-air updates.
• Ensuring that access to nodes (SSH, console) is tightly controlled and audited.
• Applying disk encryption, FIPS mode, and other host-level security features as appropriate to compliance requirements.

The platform aims to minimize the need for manual node-level configuration by operators, which in turn reduces configuration drift and security risk.

8. Monitoring, Auditing, and Compliance

A crucial security layer is visibility:

• Auditing: Recording who did what, when, and from where, at the Kubernetes API and platform levels.
• Logging: Capturing application and infrastructure logs for incident detection and forensic analysis.
• Metrics and alerts: Monitoring abnormal behavior (for example, spikes in error rates, unexpected restarts, or resource consumption).

OpenShift includes:

• An API server audit logging capability that can be configured for different levels of detail.
• Integration points for centralized log collectors and SIEM systems.
• Tools and Operators to check for compliance with various standards and recommended benchmarks.

Security is not only about preventing incidents, but also about detecting, investigating, and learning from them.

Shared Responsibility: Who Secures What?

OpenShift usually runs in environments where different parties share responsibility:

• Platform provider / infrastructure team:
• Installs, configures, and upgrades the cluster
• Secures the control plane, the underlying OS, and core services
• Manages baseline policies (SCCs, network policies, cluster-wide RBAC)
• Application teams:
• Write secure code and containerize it safely
• Use ConfigMaps and Secrets appropriately
• Choose images and dependencies responsibly
• Define resource-level policies (such as per-project network policies)
• Security and compliance teams:
• Define global policies, approved registries, and standards
• Integrate logging, monitoring, and scanning with broader enterprise tools
• Review and audit cluster configurations and access patterns

OpenShift’s design reflects this shared responsibility by:

• Providing clear policy abstraction layers
• Allowing central governance, but with room for team-level autonomy
• Making security posture partly declarative and version-controlled

Understanding where your role sits in this model helps you decide which security controls you should focus on when working with OpenShift.

Balancing Security and Developer Productivity

Strict security measures can conflict with developers’ expectations, especially when they are used to running containers with broad privileges. OpenShift aims to strike a balance by:

• Providing secure defaults that block common risky behaviors.
• Allowing exceptions through explicit policies (for example, using different SCCs for specific projects).
• Encouraging patterns that are both secure and convenient, such as:
• Building images that do not require root
• Using service accounts with scoped permissions
• Using internal registries and automated scanning instead of ad-hoc images

From a practical standpoint:

• Many “it doesn’t work on OpenShift” problems are actually security policy violations (for example, running as root, needing hostPath volumes, or using unsupported capabilities).
• The recommended approach is to adapt workloads to the platform’s security model where possible, rather than weaken the cluster-wide security posture.

How This Security Module is Organized

The remainder of the security module breaks down the main security mechanisms in OpenShift:

• Security model overview (this chapter): Big-picture view of the layers and principles.
• Role-Based Access Control: How to define and apply permissions and roles for controlling actions on resources.
• Security Context Constraints: How OpenShift controls what pods are allowed to do on the host and in the kernel.
• Image security and scanning: How to manage images safely, check for vulnerabilities, and enforce policies on what can be deployed.
• Network security: How to restrict and shape network communication inside and outside the cluster.
• Compliance and auditing: How to observe, prove, and maintain a desired security posture over time.

Together, these topics give you the tools to design, operate, and use OpenShift clusters in a way that meets real-world security and compliance expectations.