How RHCOS Can Help You Secure Your Cluster’s Node Images

Organizations increased their use of Kubernetes in 2020. According to DevProJournal, a 2020 report found that organizations’ use of Kubernetes had grown to 83 percent over the course of that year. That’s up from 78% in 2019.

These findings reflect the benefits that Kubernetes brings to organizations. According to its documentation, Kubernetes helps organizations to manage their containers in a way that ensures their applications don’t suffer downtime. For instance, the container orchestration management platform comes with load balancing capabilities that help to distribute the network’s traffic when it’s too high. This feature helps to prevent the container from going down and from affecting the application’s availability. Kubernetes also comes with self-healing features responsible for killing containers that don’t respond to a user-defined health check and replacing them with new ones, thereby ensuring the continuity of the application.

Even so, Kubernetes suffers from certain limitations that introduce challenges to organizations. StackRox elaborated on how those shortcomings can lead to security issues:

While Kubernetes provides container orchestration capabilities, pod resiliency, services definitions, and deployment constructs, there are many other components required to make it work. For example, Kubernetes does not provide default Container Network Interface (CNI) or default monitoring implementations. It is up to the cluster administrator to bring additional tools to operate and manage the Kubernetes cluster and any applications running. For security teams, this presents new challenges – as an example, these teams need to create new policies and vet images, configurations, and account access for any new applications that will be deployed into the cluster.

Using OCP to Harden Kubernetes Security

Admins need to bring in additional tools to meet their infrastructure’s security needs. That’s where Red Hat’s OpenShift Container Platform (RHOCP) comes in. A consistent Kubernetes platform, RHOCP comes with a user-friendly console through that admins can use to gain complete visibility of their containerized applications across multiple deployments. They can then leverage that visibility to manage all of their clusters on an ongoing basis.

Which brings us to the matter of security. According to Red Hat’s documentation, RHOCP helps admins to ensure their Kubernetes security by drawing upon development tools and other products that exist within Red Hat’s ecosystem. Among those products is the Red Hat Enterprise Linux CoreOS (RHCOS).

What Is RHCOS?

Elsewhere in its documentation, Red Hat notes that RHCOS is a version of Red Hat Enterprise Linux (RHEL) that’s configured to work as master and worker nodes on RHOCP clusters. It comes with various security features that minimize the host environment and implement adjustments in favor of containers. This helps to reduce the attack surface and makes running container workloads with OpenShift more secure than with other platforms.

Provided below are some of the security features that come with RHCOS:

• Linux namespaces: This feature allows admins to create an abstraction of a global system resource. The abstraction will then appear as a separate instance to a particular namespace’s processes, thereby enabling several containers to use the same computing resource without coming into conflict.
• SELinux: Through SELinux, admins can enforce mandatory access controls that help to further isolate individual containers from one another and the host.
• CGroups: Short for “control groups,” CGroups help admins to manage the resource usage for a collection of processes. They give admins a way of ensuring that containers on the same host don’t undermine the operability of one another.
• Seccomp: Finally, admins can create secure computing mode (seecomp) profiles that restrict system calls associated with a container.

Taking RHCOS a Step Further

Admins can take their RHCOS and harden it even further to protect their organization against a node compromise. Towards that end, they might consider using minimal base operating system images and configuring their file systems to “read-only” status. The former will deny attackers a large breadth of tools that they could use to potentially compromise a node, while the latter will prevent nefarious individuals from installing malicious tools and then hijacking the system.

From there, it’s important that admins not directly modify RHCOS systems in RHCOP and modify systems in pools of nodes instead. They can use that approach to change RHCOS before, during and after installation of a cluster. Prior to installation, for instance, admins can add kernel options that enable them to activate security features such as SELinux or disk encryption. During installation, they can change Ignition configurations after interrupting OpenShift’s installation process in order to add their own files and system services to their nodes. They can also change the contents of the install-config.yaml file that affect each node’s initial boot. Finally, once the cluster is already up and running, admins can use MachineConfig and DaemonSets to apply changes across multiple nodes of the same type and to run services on every node in their deployment.

For more information about RHCOS and its security features, check out OpenShift’s documentation here and here.