13.1 Security model overview

Core Principles of OpenShift Security

OpenShift’s security model is layered and opinionated: it builds on Kubernetes security, then adds defaults, constraints, and tooling to make multi-tenant clusters safer by default. At a high level, it focuses on:

• Defense in depth – multiple, independent controls (API, RBAC, SCCs, networking, image policies, etc.).
• Secure by default – conservative defaults for pods, users, and workloads.
• Multi-tenancy and isolation – projects as security boundaries, namespace-scoped resources, and policy layers.
• Least privilege – minimize what users, service accounts, and workloads can do.
• Compliance and auditability – logs, policy enforcement, and integration with enterprise identity and security tools.

Subsequent chapters (RBAC, SCC, image security, network security, compliance) drill into specific mechanisms; here the focus is on how they fit together conceptually.

Security Layers in OpenShift

OpenShift security can be viewed as a stack of layers, from “who can call the API” down to “what a process in a container can do on the host”:

1. User and identity layer
2. API access control layer (RBAC)
3. Workload isolation and pod-level security (SCCs and pod configuration)
4. Network segmentation and traffic control
5. Image and supply-chain security
6. Cluster and node security
7. Monitoring, audit, and compliance

Each layer is relatively independent: a misconfiguration in one layer does not automatically bypass the others.

1. User and Identity Layer

This layer answers “who are you?”:

• Human users – developers, operators, admins.
• Service accounts – identities used by workloads inside the cluster.
• External identities – from LDAP/AD, OAuth providers, SSO, etc.

Key ideas:

• Authentication is centralized through the OpenShift API server.
• Users and service accounts are only meaningful when combined with authorization rules (RBAC).
• Separation of “human” and “machine” identities is fundamental for auditability and least privilege.

2. API Access Control Layer

The API server is the main control point in OpenShift. All actions—creating pods, changing routes, reading secrets—go through the API.

The security model here is:

• Everything is a request to the API – even oc and the web console.
• Authorization decides whether a given user/service account can perform an action on a resource in a namespace or at cluster scope.
• Permissions are typically granted via roles and bindings (discussed in depth in the RBAC chapter).

Conceptually:

• The API is the gatekeeper.
• RBAC expresses “who can do what, where”:
• Who: user, group, or service account.
• What: verbs (get, list, create, update, delete, exec, etc.).
• Where: namespace or cluster-wide.

This model enables:

• Fine-grained delegation (e.g., devs can manage apps in their project, but not cluster-wide resources).
• Privilege separation between cluster-admins, app teams, and automated systems.

3. Workload Isolation and Pod-Level Security

Once a request to run a workload is allowed, OpenShift enforces how that workload runs via pod-level security controls.

The central concepts are:

• Run as unprivileged by default – containers do not run as root on the host by default.
• Restricted capabilities – Linux capabilities and host access are reduced as much as possible.
• Constraints tied to service accounts/namespaces – policy follows the workload identity and its project.

Key enforcement points include:

• Restrictions on whether containers may:
• Run as root or must run as a non-root user.
• Use host networking or host PID/IPC namespaces.
• Mount host paths or privileged volumes.
• Add extra Linux capabilities.
• Policy is evaluated when pods are created or modified, not at container runtime.

In practice, this layer creates runtime boundaries between workloads, even when they share nodes, and enforces least privilege at the pod level.

4. Network Segmentation and Traffic Control

OpenShift assumes that not all workloads should be able to talk to each other freely. Its security model includes:

• Namespace-based isolation – projects tend to encapsulate an application or team, and networking tools can use that structure.
• Internal service discovery – stable service endpoints so that policies can target services instead of moving pod IPs.
• Policy-based controls – the ability to allow or deny traffic:
• Between namespaces.
• Between groups of pods (labeled sets).
• From or to external endpoints.

From a model perspective:

• Network controls decide “who can talk to whom, and on which ports”.
• They complement API/RBAC controls (which control configuration changes, not runtime traffic).

5. Image and Supply-Chain Security

OpenShift treats container images as software artifacts that must be trusted before running, integrating mechanisms to:

• Control where images can be pulled from (trusted registries, internal registries).
• Enforce constraints on which images are allowed (signatures, policies).
• Scan images for known vulnerabilities and policy violations.

Conceptually:

• The security model extends left into the build and CI/CD process.
• Running workloads are tied to:
• The origin of their images.
• Policies that describe which images are acceptable in which environments.

This ties cluster runtime security back to DevOps practices and the software supply chain.

6. Cluster and Node Security

Beneath Kubernetes and OpenShift abstractions, the cluster runs on operating system nodes.

The OpenShift security model assumes:

• Nodes are hardened and managed (updates, configuration, baseline security).
• The Kubernetes node agents and OpenShift components run with necessary but controlled privileges.
• There is a clear separation between:
• Cluster control components.
• User workloads.
• Host OS.

Important ideas:

• Nodes are often treated as trusted infrastructure, while workloads are untrusted or semi-trusted.
• Host-level security configuration and lifecycle management are part of the security model, even if often managed by platform teams.

7. Monitoring, Audit, and Compliance

Security is not only about prevention; it’s also about detection, investigation, and proof of control.

OpenShift’s model includes:

• Audit logging at the API level:
• Who did what, when, and from where.
• Integration with logging and monitoring stacks:
• To detect anomalies, failures, and potential security incidents.
• Tools and operators for compliance checks:
• Validating the cluster’s state against standards or internal policies.

Conceptually:

• Audit and observability create feedback loops:
• Confirm policies are working as intended.
• Provide evidence for regulatory/compliance needs.
• They support forensic analysis and continuous improvement of security posture.

Multi-Tenancy and Isolation Model

Multi-tenancy is a core design goal of OpenShift. The security model achieves tenant separation by combining several mechanisms:

• Projects/namespaces as tenant boundaries:
• Logical grouping of resources, identity, and policies.
• RBAC to control who can access or modify resources within those boundaries.
• Service accounts scoped to namespaces, tying workloads to a specific tenant context.
• Pod-level security controls that differ per namespace, allowing different security postures (e.g., dev vs production).
• Network policies and routing to control communication within and across projects.
• Quota and limits (covered elsewhere) to protect tenants from each other’s resource usage.

In this model:

• Each project is like a security micro-environment:
• Defined set of users and service accounts.
• Policies about how workloads may run.
• Network rules governing communication.
• Cluster-wide roles and operations are reserved for platform administrators, strongly separating platform management from application development.

Security Responsibilities and Shared Model

OpenShift fits into a broader shared responsibility model:

• Cluster/platform administrators are typically responsible for:
• Cluster installation, configuration, and upgrades.
• Node security, storage, networking, and core operators.
• Defining global policies (RBAC baselines, default SCCs, image and network policies).
• Integrating with enterprise security systems (IdP, SIEM, vulnerability scanners).
• Application teams are typically responsible for:
• Writing secure application code.
• Choosing and maintaining base images (within allowed policies).
• Defining application-level configuration, secrets usage, and resource needs.
• Adjusting their manifests to comply with platform security controls (e.g., running as non-root, proper ports, probes).

This separation is reflected in the security model:

• Platform teams define guardrails.
• Application teams operate within those guardrails, with enough flexibility to build and run their workloads.

Putting It All Together: Typical Flow

A simplified end-to-end flow illustrates how the security model operates:

1. A developer logs into OpenShift via the web console or oc:
• Identity is verified through the configured authentication provider.
2. The developer creates or modifies resources in a project:
• The API server checks RBAC rules to determine if the action is allowed.
3. A new application deployment is created:
• The pod spec is validated against security policies (pod security constraints).
• If it violates required policies (e.g., tries to run privileged), the request is rejected.
4. The scheduler places the pod on a node:
• Node and cluster-level security configurations determine isolation from other workloads.
5. The pod starts, pulling an image:
• Image policies and registries govern which images are permitted.
• Scanning or signing policies might block or warn about risky images.
6. The application begins communicating:
• Network policies determine which pods/services it can reach.
• External access is governed by routes/ingress and potentially external firewalls.
7. All API calls and key events are logged:
• Audit logs and metrics feed into monitoring and compliance systems.

At each step, a different part of the security model has a chance to enforce policy or provide visibility, ensuring that no single control is the only line of defense.

Key Takeaways

• OpenShift’s security model is layered, opinionated, and designed for multi-tenant environments.
• Security controls span:
• Identity and access (users, service accounts, RBAC).
• Workload behavior (pod-level restrictions).
• Network communication (policies and routing).
• Image trust and supply chain.
• Node and cluster hardening.
• Audit, monitoring, and compliance.
• Responsibilities are shared between platform administrators and application teams, with clear boundaries and guardrails.

Subsequent chapters break down each of these layers—RBAC, SCCs, image security, network security, and compliance—into concrete mechanisms and practices.