OpenShift Security: Challenges and 5 Critical Best Practices
What Is OpenShift Security?
OpenShift security refers to the set of practices, processes, and tools used to protect the Red Hat OpenShift Container Platform, a Kubernetes-based container orchestration platform, from potential threats and vulnerabilities. OpenShift offers several built-in security features and follows best practices to ensure a secure environment for deploying, managing, and scaling containerized applications.
This is part of a series of articles about Kubernetes security.
In this article:
OpenShift Security Challenges
While OpenShift provides several built-in security features and follows best practices to ensure a secure environment for deploying, managing, and scaling containerized applications, it is not immune to security challenges. Some of the common security challenges faced when using OpenShift include:
- Misconfigurations: Incorrect configuration of security settings or features within OpenShift can lead to vulnerabilities, exposing the platform and applications to potential threats.
- Container image vulnerabilities: Container images may contain vulnerabilities due to outdated software, insecure code, or misconfigurations. Ensuring that container images are regularly scanned, vulnerabilities are patched, and only trusted images are used is crucial for maintaining a secure environment.
- Insider threats: Malicious or negligent actions by users with access to the OpenShift platform can result in security breaches or data leaks.
- Compliance: Depending on the industry, organizations using OpenShift may need to adhere to specific regulations or standards, such as GDPR, HIPAA, or PCI DSS.
- Scaling security: As organizations scale their OpenShift deployments, managing security across multiple clusters, projects, and teams can become increasingly complex.
5 OpenShift Security Best Practices
1. Use Projects and Namespaces
Projects and namespaces are fundamental concepts in OpenShift and Kubernetes that help you organize and isolate resources within a cluster. Implementing projects and namespaces can significantly enhance the security of your OpenShift environment.
Namespaces
Namespaces are a Kubernetes feature that allows you to create logical partitions within a cluster to separate and manage resources based on application, team, or any other criteria. Namespaces provide a way to isolate resources like pods, services, and deployments, ensuring that they don’t interfere with each other and can be managed independently.
Projects
Projects are an OpenShift extension of the Kubernetes namespaces concept. In addition to the namespace isolation, projects also provide a layer of access control, allowing you to define which users or groups can access, modify, or manage resources within a project. This ensures that only authorized users can perform specific actions within a project, helping to maintain the security and integrity of your resources.
Using projects and namespaces simplifies management and enhances security by:
- Limiting the potential impact of compromised applications or user accounts.
- Segregating resources based on application, team, or environment, making it easier to manage and monitor resources.
- Ensuring that users can only access the resources they are authorized to use, reducing the risk of unauthorized access or modification.
2. Limit Container Runtime Privileges
Containers should be executed with the least possible privileges to minimize the attack surface and reduce the risk of container breakout or privilege escalation. To achieve this, you can use security context constraints (SCCs) and pod security policies (PSPs) to define and enforce limits on container capabilities.
Security Context Constraints (SCCs)
SCCs are an OpenShift-specific feature that allows you to define and enforce security settings for containers. These constraints restrict the capabilities and access of containers to the host system.
Some common SCC settings include running containers as non-root users, disabling privileged mode, and limiting access to host resources like volumes, network interfaces, or IPC namespaces.
Pod Security Policies (PSPs)
PSPs are a Kubernetes feature that enables you to define and enforce security settings at the pod level. Similar to SCCs, PSPs can restrict pod-level privileges, such as running containers with a specific user ID, disallowing the use of host networking, or preventing the use of certain volume types.
Note that PSPs may not be enabled by default in OpenShift, so you might need to enable them in your cluster if you want to use this feature.
Limiting container runtime privileges helps to:
- Reduce the attack surface by restricting container capabilities, making it more difficult for an attacker to exploit vulnerabilities within a container or the host system.
- Mitigate the risk of container breakout by limiting the access and capabilities of containers, reducing the potential impact if a container is compromised.
- Improve overall security posture by ensuring that applications run with the minimum privileges required to function correctly.
3. Monitor and Analyze Audit Logs
Enabling audit logging helps maintain a record of actions performed by users, system components, and applications within the OpenShift cluster. It helps in identifying unauthorized access, troubleshooting issues, and complying with regulatory requirements. Audit logs should be monitored and analyzed regularly to detect potential security threats and anomalies.
OpenShift generates audit logs for the API server, which contain essential information about the cluster’s state and operations. These logs should be collected and stored in a centralized, secure location for further analysis.
4. Secure etcd
etcd is a distributed key-value store used by Kubernetes and OpenShift as the primary data store for maintaining the configuration data, state data, and metadata of the cluster. Securing etcd is crucial to ensure the integrity and confidentiality of the data stored within it. Some best practices for securing etcd include:
- Encryption: Enable encryption for both data in transit and data at rest. Use TLS for communication between etcd members and between etcd and other components like the Kubernetes API server. Additionally, you can configure encryption for data stored in etcd using Kubernetes’s built-in encryption-at-rest features.
- Access control: Limit access to the etcd API by using authentication and role-based access control (RBAC). This ensures that only authorized components can interact with etcd and perform specific actions based on their assigned roles.
- Backup and recovery: Regularly create backups of etcd data to protect against data loss or corruption. Test the backup and recovery process to ensure that you can quickly restore the etcd cluster in case of a failure or disaster.
5. Use the OpenShift Container Security Operator
The OpenShift Container Security Operator is a component that helps to enhance the security of container images within an OpenShift cluster. It works by integrating with the Quay container registry, a container image storage and distribution solution developed by Red Hat. The operator provides several key security features:
- Image scanning: Automatically scans container images for known vulnerabilities, ensuring that the applications running in your cluster are built on secure images. This scanning process leverages the Clair vulnerability scanner, which is part of the Quay registry, to identify and report any security risks in the images.
- Vulnerability management: Allows you to set policies on how to handle vulnerable images, such as blocking deployments of images with critical vulnerabilities or notifying administrators when an issue is detected. This proactive approach helps to minimize the risk of deploying insecure applications.
- Policy enforcement: Enables you to define and enforce security policies for container images, ensuring that only images that meet specific criteria, such as being signed by trusted sources or containing no known vulnerabilities, are deployed in the cluster.
OpenShift Security with Calico
Calico provides zero-trust security to enable platform engineers to reduce the attack surface of microservices-based applications, mitigate security breaches, and deliver zero trust-based, defense-in-depth capabilities for cloud-native applications on Red Hat OpenShift. Features include:
- Zero-trust workload access controls – Granular access controls between individual pods, namespaces, and services in Kubernetes clusters and external resources, including databases, internal applications, 3rd-party cloud APIs, and SaaS applications.
- Egress Gateway – Allocates static IPs to pods to enable firewalls outside the Red Hat OpenShift cluster to identify these pods and apply appropriate security controls. This enables the cluster to securely scale while preserving the limited number of routable IPs and leveraging non-routable IPs for all other pod traffic within the cluster.
- Universal firewall integration – Calico’s egress gateway works with any firewall, including Palo Alto Networks, Fortinet, Check Point, and others. Enterprise firewall managers can be used to create a zone-based architecture for your Openshift cluster.
- Identity-aware microsegmentation – Achieve workload isolation and secure lateral communication between pods, namespaces, and services. Works across network and application-layer protocols to rapidly scale workloads in milliseconds in your OpenShift clusters without having to change security policies.
- Policy tiering – Enforce enterprise-wide policies that take precedence over any application-specific policy, thus ensuring continuous compliance.
- Policy recommendation – Inspects traffic within Red Hat OpenShift clusters and recommends appropriate security policies at workload and namespace levels to secure traffic. Enables OpenShift platform teams to author, preview, deploy, and manage policies without writing a single line of code.
- Data-in-transit encryption with WireGuard – Protect sensitive data and meet compliance requirements with high-performance encryption for data in transit.
Further reading:
