Skip to content

OpenShift Security Architecture

OpenShift's security is built on top of Kubernetes and hardened with additional features to secure the cluster, the applications, and the development process.

1. Control Plane Security (Master Nodes)

This is the heart of the cluster, and its security is paramount.

  • API Server and etcd: The Kubernetes API server is the front-end. etcd is the distributed key-value store holding all cluster configuration and sensitive data (like Secrets).
    • Architecture Control: Strong authentication (e.g., OAuth, LDAP) and Role-Based Access Control (RBAC) are enforced for all access.
    • Data Protection: etcd data should be encrypted at rest to protect sensitive information even if the backup is exposed.
  • Authentication and Authorization:
    • RBAC: Carefully defining Roles/ClusterRoles and RoleBindings/ClusterRoleBindings to adhere to the principle of least privilege. Avoid using broad, cluster-wide administrator roles.

2. Node Security (Worker Nodes)

These nodes run your container workloads.

  • Immutable OS: OpenShift uses Red Hat CoreOS (RHCOS), a minimal, security-focused, immutable operating system that minimizes the attack surface.
  • SELinux: Used to enforce mandatory access controls, which provides an extra layer of isolation between containers and the host OS, as well as between containers themselves.
  • CRI-O: The default container runtime, which is lightweight and security-focused, designed specifically for Kubernetes.
  • Host Hardening: Following general Linux security best practices (e.g., promptly patching the OS, disabling unused services).

3. Application and Container Security

This focuses on the running workloads and their associated images.

  • Security Context Constraints (SCCs): This is an OpenShift-specific feature that controls what actions a pod can perform, what resources it can access, and what privileges it can run with. SCCs are crucial for enforcing the principle of least privilege for containers (e.g., running as non-root, limiting volume types, restricting host access).
  • Image Security:
    • Vulnerability Scanning: Integrating tools (like the built-in image registry scanner or Red Hat Advanced Cluster Security - RHACS) into your CI/CD pipeline to scan container images for known Common Vulnerabilities and Exposures (CVEs).
    • Content Trust: Using image signing to verify the integrity and source of the images before deployment.
  • Secrets Management: Utilizing dedicated services (like IBM Cloud Secrets Manager, Vault, or OpenShift's Secrets) to store and manage sensitive data, rather than embedding them in container images or configuration files.

4. Network and Multi-Tenancy Security

Isolation is key in a shared environment.

  • Projects and Namespaces: OpenShift's Projects (an extension of Kubernetes Namespaces) are fundamental for resource organization and isolation between teams or applications.
  • Network Policies: These define how groups of pods are allowed to communicate with each other and with external network endpoints, enforcing a zero-trust network model.

Threat Awareness and Mitigation

A security architecture is only as good as the understanding of the threats it is designed to mitigate.

Threat Category Specific Threats Mitigation in OpenShift
Vulnerable Containers Exploitable CVEs in application dependencies or base OS images. Image Scanning in CI/CD, using trusted/minimal base images, and enabling Image Security Enforcement admission controllers.
Misconfigurations Overly permissive RBAC roles, insecure default settings, or exposed services. Strict RBAC Granularity and regular Audit/Review of roles and constraints. Using Network Policies for egress/ingress control.
Container Breakout/Escalation A compromised container gains access to the host node's operating system or other containers. SCCs to run containers as non-root with limited capabilities. Strong SELinux profiles on the nodes.
Data Breach Sensitive data (secrets, configuration) stored in an unencrypted or exposed manner. Encrypting etcd at rest. Using dedicated Secrets Managers and limiting access to Secrets via RBAC.
Supply Chain Attack Malicious code injected into the CI/CD pipeline, often through compromised base images or third-party dependencies. Image Signing/Content Trust to verify image source. Reviewing and hardening the CI/CD pipeline itself.
Insider Threats Users (or service accounts) with excessive permissions causing intentional or accidental damage. Strict adherence to Least Privilege. Audit Logging and monitoring to track all API server actions.

Continuous Monitoring and Response

A secure environment requires continuous vigilance:

  • Audit Logging: OpenShift automatically generates detailed audit logs for the API server. These logs must be collected, stored centrally, and monitored for suspicious activity.
  • Runtime Security: Tools like Red Hat Advanced Cluster Security (RHACS) provide runtime detection and response for anomalous container behavior, even for zero-day attacks.
  • Compliance Operator: OpenShift provides an operator to automate checking and reporting against compliance benchmarks (like CIS).