Resources

Zero Trust on OpenShift

Reference Guide & Implementation Checklist for OCP Environments

Author

Heather Harwell

Subject

Zero Trust controls mapped to the five ZT pillars for Red Hat OpenShift.

Audience

Internal engineering & security colleagues.

Overview

This guide describes a Zero Trust (ZT) approach to securing Red Hat OpenShift Container Platform (OCP) clusters. It assumes a “never trust, always verify” posture: no user, workload, or node is implicitly trusted, and every request is authenticated, authorized, and encrypted.

The controls below are organized around the five Zero Trust pillars — Identity, Networks, Applications & Workloads, Data, and Devices. Each section pairs the reference guidance with a tickable implementation checklist for use during planning, build-out, and audit reviews.

01

Identity

Establish and verify the cryptographic identity of every workload and user before granting access.

Reference Controls

  • Implement workload identities

    Install the Red Hat Zero Trust Workload Identity Manager Operator, which automates the issuance, rotation, and lifecycle management of SPIFFE/SPIRE IDs — proving the identifier assigned to a specific piece of software.

  • Enable mTLS

    Integrate OCP Service Mesh to enforce mutual TLS for secure service-to-service communication.

  • Federate identities

    Securely exchange trust bundles with external Identity Providers (IdPs).

  • Enforce RBAC controls

    Use Open Policy Agent (OPA) for fine-grained policy enforcement.

  • Enable Trustee & Confidential Containers

  • Use the External Secrets Operator

  • Establish Zero Trust pipelines

Implementation Checklist

0 / 7
02

Networks

Segment the cluster by default and explicitly permit only the traffic that is required.

Reference Controls

  • Enable default-deny policies

    Set up segmentation between all namespaces using a Baseline Admin Network Policy (BANP) to enforce "guardrails" across the entire cluster.

    • Create additional policies to explicitly allow necessary traffic, such as DNS or communication with the OCP ingress controller.
    • Use a supported network plugin.
  • Whitelist required traffic

  • Enforce DNS egress

    Must allow pods to reach core DNS resolution.

  • Deploy Service Mesh to automatically handle cryptographic identity

  • Install cert-manager

  • Secure ingress controls

    Set up Egress IP policies.

  • Use an API gateway

    To enforce authorization and rate-limiting.

  • Integrate Advanced Cluster Security (ACS)

    To monitor environments and scan continuously.

  • Apply least-privilege security contexts

Implementation Checklist

0 / 11
03

Applications & Workloads

Authorize only the specific communication paths each workload needs, and constrain what every container is permitted to do.

Reference Controls

  • Deploy Service Mesh

    Configure a PeerAuthentication resource in the mesh root namespace, setting the mode to STRICT to reject all unencrypted traffic.

  • Implement micro-segmentation

    Apply default-deny policies.

  • Write explicit allow rules

    Layer NetworkPolicy rules on top of the default-deny policies to authorize only specific pod-to-pod and pod-to-external communication paths.

  • Leverage Egress Firewall objects

    Strictly limit which external databases, IPs, or APIs a specific workload can call.

  • Enforce Pod Security Standards (PSS)

    Bind namespaces to the restricted pod security profile using admission labels to block privileged containers.

  • Migrate to custom Security Context Constraints (SCCs)

    Explicitly drop Linux capabilities (e.g. chown, net_admin) and force workloads to run as a non-root UID (runAsNonRoot: true).

  • Deploy OCP sandboxed containers

    • Install the Sandboxed Containers Operator.
    • Update deployment manifests with runtimeClassName: kata to isolate untrusted or multi-tenant workloads.
  • Configure ImagePolicyWebhook

    Allow container deployments only from a validated, internal registry.

  • Enforce cosign signature verification

    Deploy ACS to block pods whose container images lack a valid cryptographic signature from the CI/CD pipeline.

  • Automate via GitOps

  • Enable API server logging

    • Configure the advanced audit profile.
    • Forward logs to an external SIEM for real-time analysis of API calls.
  • Deploy RHACS risk profiling

    Continuously scan active containers for new CVEs and runtime anomalies.

Implementation Checklist

0 / 12
04

Data

Encrypt data at rest and in transit, control access to it, and audit how it is used.

Reference Controls

  • Enable etcd encryption

    Modify the APIServer cluster object to use the aescbc or secretbox type to encrypt secrets, configmaps, and tokens.

  • Configure node-level disk encryption

    • Utilize RHCOS disk encryption.
    • During install, enable Tang or TPM 2.0 with Network-Bound Disk Encryption (NBDE) to encrypt root/data partitions on all worker and master nodes.
  • Implement persistent volume (PV) encryption

    Use OpenShift Data Foundation (ODF).

  • Enforce ingress TLS termination

    Configure all routes and ingress objects to use edge, reencrypt, or passthrough TLS profiles with secure ciphers — reject any plain HTTP.

  • Secure pod-to-pod traffic

    Apply a global PeerAuthentication policy set to STRICT mode, ensuring all inter-service data movement is encrypted using mTLS.

  • Enable OVN-Kubernetes IPsec

    Enable IPsec encryption within the OVN-Kubernetes network plugin config to secure node-to-node traffic automatically.

  • Deploy ACS for secret discovery

  • Integrate external secrets management

    Install the External Secrets Operator to pull cryptographic keys dynamically into pods from external vaults using short-lived tokens.

  • Apply RBAC to data APIs

  • Enforce Egress Firewall

  • Block host volume mounts

    Deny apps the ability to use hostPath mounts — this prevents compromised workloads from reading data directly from the node's filesystem.

  • Configure advanced audit logging

    Update cluster APIServer configs to log data metadata and request bodies (RequestResponse level) for critical data resources.

  • Forward logs to a secure SIEM

Implementation Checklist

0 / 13
05

Devices

Ensure every node boots trusted software, stays compliant with its secure baseline, and exposes no unnecessary access.

Reference Controls

  • Enable UEFI Secure Boot

    Ensures RHCOS nodes only boot with cryptographically signed, trusted software kernels.

  • Implement TPM 2.0 verification

    • Utilize Trusted Platform Modules on hardware nodes.
    • Use MachineConfig objects to bind node disk encryption to the hardware's TPM chip — ensuring data can't be read if the drive is moved to an unauthorized device.
  • Install the Compliance Operator

    Configure it to scan against official Zero Trust benchmarks (NIST SP 800-53, FedRAMP, or CIS Benchmark).

  • Remediate node config drift

    Use the Compliance Operator to automatically apply MachineConfig fixes when a node drifts from its secure baseline.

  • Enforce FIPS mode

  • Isolate the control plane

    Set the API server to private to hide management endpoints from the public internet.

  • Disable host SSH access

    Use MachineConfig to disable or lock down the SSH daemon (sshd) on all nodes.

  • Configure node firewalls

    Use the NodeNetworkConfigurationPolicy to configure strict host-level packet filtering (iptables/nftables) on nodes.

  • Monitor host file integrity (AIDE)

    Use the Advanced Intrusion Detection Environment via the Compliance Operator to continuously monitor the integrity of critical system files.

  • Forward host OS security logs

    Configure the logging operator (ClusterLogForwarder) to scrape system-level logs from every node and stream them in real time to an immutable external SIEM for device-anomaly detection.

  • Use identity providers supporting MFA

  • Enforce conditional access policies

Implementation Checklist

0 / 12

Content by Heather Harwell. This document was transcribed and formatted from Heather’s original handwritten working notes; product and resource names reflect Red Hat OpenShift terminology.

Turtini uses cookies to improve your experience, analyze site traffic, and personalize content. By clicking Accept, you consent to our use of cookies. Privacy Policy

Wally

Your Turtini assistant

Hi, I'm Wally!

Ask me anything about Turtini — features, pricing, how things work, and more.

or

Already have an account? Sign in

Wally can make mistakes — verify important info.