What is OpenShift?

OpenShift, developed by Red Hat, is a Kubernetes-based container platform tailored for enterprise use. It extends Kubernetes with integrated developer tools, monitoring, security policies, and robust multi-cloud support. OpenShift’s enterprise-grade features make it particularly suited for organizations with complex compliance and operational requirements.

Who Uses OpenShift?

OpenShift is designed for organizations needing secure, scalable, and compliant infrastructure. Typical adopters include:

1. Financial Services: High stability and compliance for regulated environments.
2. Telecommunications: Reliable hybrid cloud workload management.
3. Healthcare and Government: Strict security and policy-driven architectures.
4. Large Enterprises: Complex application ecosystems with demanding regulatory and operational needs.

Engineering Challenges to Support OpenShift

Adapting RAD Security’s runtime anomaly detection capabilities for OpenShift required significant engineering effort, particularly around its container runtime, security policies, and access controls.

1. Supporting CRI-O

OpenShift uses CRI-O as its default container runtime, diverging from Docker or containerd used in many Kubernetes environments. To support CRI-O, we:

• Reconfigured the eBPF Agent: CRI-O’s metadata structure differs significantly from Docker’s. Our agent was updated to read and process these differences, ensuring accurate monitoring.
• Tested Compatibility: Adjustments were made to capture runtime events seamlessly, enabling anomaly detection without gaps in telemetry.

2. Navigating OpenShift’s SecurityContextConstraints (SCC)

OpenShift enforces SecurityContextConstraints (SCC) as part of its security model. SCCs define the permissions and restrictions applied to pods, including:

• Whether pods can run as root.
• Access to host-level resources (e.g., hostPID, hostNetwork).
• Allowed volume types and syscalls.

Why SCCs Are Important

Unlike Kubernetes’ PodSecurityPolicies (PSPs) or Pod Security Standards, SCCs provide a finer level of control tailored to OpenShift. For an eBPF-based agent like ours, adapting to SCCs was critical to maintain functionality while adhering to OpenShift’s stricter security boundaries.

What We Changed

To integrate with SCCs, we needed permissions for:

• hostPID: Essential for accessing the host process namespace (discussed in detail below).
• Host Directory Mounts: Required for accessing logs and system files.
• Syscall Permissions: Some SCCs restrict syscalls critical for eBPF. Adjustments ensured compliance while retaining detection capabilities.

Balancing Security and Functionality
SCCs are stringent for a reason: they limit attack vectors by controlling privileged operations. However, our anomaly detection relies on host-level access to monitor runtime events effectively. We worked closely with OpenShift’s security model to:

• Ensure the least-privilege principle by scoping changes to the eBPF agent’s pod.
• Validate security implications through rigorous testing, ensuring no unintended exposures.

3. Enabling hostPID

What is hostPID?
The hostPID setting allows a pod to share the process namespace of the host node. When enabled, containers in the pod can view and interact with all processes running on the host, not just within the container.

Why Does the eBPF Agent Require hostPID?
To provide comprehensive runtime anomaly detection, our eBPF-based agent needs visibility into system-level activity, including:

• Host-Level Process Monitoring: Without hostPID, the agent would be restricted to processes inside its container, missing critical system events.
• Syscall Tracking Across the Host: eBPF sensors track syscalls system-wide, providing vital telemetry for detecting suspicious activity.
• Mapping Containerized Processes: In OpenShift, processes are tied to the host namespace via CRI-O. Enabling hostPID ensures the agent can accurately correlate events with specific containers.

Navigating SCC Restrictions

By default, SCCs prohibit hostPID due to its elevated privileges, which could be exploited if a pod is compromised. To safely enable it, we:

• Modified SCCs for the Agent: Only the eBPF agent’s pod was granted the hostPID privilege.
• Scoped Permissions Narrowly: Restricted access to host-level resources to minimize potential risks.

4. Expanding Role-Based Access Control (RBAC)

OpenShift provides a more granular RBAC system compared to Kubernetes, allowing precise control over user and service account permissions. This required:

• Permissions to mount host directories as volumes.
• Access to configure security profiles like seccomp and apparmor, essential for eBPF operations.
• Capability requests tailored to OpenShift’s RBAC model.

By integrating with OpenShift’s RBAC, we ensured our agent could operate securely while maintaining compliance with its advanced access control mechanisms.

Conclusion

Expanding support for OpenShift demonstrates RAD Security’s commitment to delivering robust security solutions across diverse Kubernetes environments. Adapting to OpenShift’s unique requirements, such as CRI-O, SCCs, and RBAC, was essential to ensure our runtime anomaly detection provides the same depth of coverage and reliability that customers expect.

With OpenShift support, organizations can confidently adopt this powerful platform while maintaining secure, compliant, and scalable workloads.