Accelerate STIG compliance with Red Hat OpenShift’s built-in security features: From 40 CAT I items to 7 (Part 1)

On Sep 8, 2023 the Defense Information Systems Agency (DISA) published the Red Hat OpenShift Container Platform 4.12 Security Technical Implementation Guide (OpenShift STIG).

This three-part blog series begins with an overview of the OpenShift STIG, some of the built-in security features that come with OpenShift, and compares OpenShift with a general Kubernetes implementation. Part two of this series will be a technical walkthrough of the seven highest-priority STIG items and how they’re implemented in OpenShift.

Finally, part three of the series will present the scanning and remediation of an OpenShift cluster using the STIG profile of the Compliance Operator, which uses a National Institute of Standards and Technology (NIST)-validated scanning tool, OpenSCAP, to scan the API components as well as the nodes. It is assumed that readers have some knowledge or experience with STIGs, Kubernetes and OpenShift.

Applying STIGs for government systems can be a daunting and tedious task. The procedure becomes easier as security professionals gain greater knowledge of the technologies that require STIG hardening and adopt automation tools to help apply the STIGs, but security experts are continuously looking for methods to make the process more efficient.

Operating systems and applications that are more secure by default require less hardening, which significantly decreases the time it takes to achieve STIG compliance. Red Hat OpenShift takes the approach of starting out with extensive layers of built-in security capabilities, enabling security professionals to more readily obtain the necessary authorization to get OpenShift into production. Red Hat also provides maintenance support updates with security advisories that keep users informed and help reduce their workload.

Some organizations choose to run their containerized applications in a Kubernetes distribution that requires provisioning the Master/Worker nodes with a full general purpose operating system and then piecing together all the other tools needed to run a full container platform. This also means that they need to download and implement multiple STIGs for the underlying operating system, Kubernetes and harden any other components they include. An example of this do-it-yourself (DIY) approach of piecing everything together to have a full container platform is illustrated below.

STIG items are filtered into three categories in order to prioritize which items need to be applied first—CAT I, CAT II and CAT III. Let’s take a look at what it would take to STIG Kubernetes on Red Hat Enterprise Linux (RHEL).  We will be reviewing RHEL 8 in this example by loading the DISA STIGs for Kubernetes and RHEL 8 into STIG Viewer which is the tool used most widely in the DoD for viewing STIGs and creating checklists.

For the Kubernetes STIG, there are 19 CAT I items.

For RHEL 8, there are 21 CAT I items.

This would require 40 STIG items to be implemented on the operating system and Kubernetes just to be compliant with Category I. Overall, there are 375 STIG items for RHEL 8 and 93 for Kubernetes bringing the total to 468.  

Now let’s take a look at OpenShift. OpenShift does not use a full operating system.  The operating system (OS) used in OpenShift is called Red Hat Enterprise Linux CoreOS (RHCOS) which is a lightweight, immutable, container-specific operating system. NIST SP 800-190, Application Container Security Guide, states to “Use container-specific host OSs instead of general-purpose ones to reduce attack surfaces.”  

OpenShift starts out with a reduced attack surface due to its container-specific OS. Also, the OS is not managed directly by an admin, but through the OpenShift platform itself, leaving less chance for operator error. The OpenShift STIG covers the entire platform which includes the nodes, operating system, Kubernetes layer and additional services which makes implementing security and managing STIG compliance much easier. Below is an illustration of the main components that are included with OpenShift.

Since we’ve looked at the number of CAT I items for Kubernetes and RHEL 8, let’s take a look at the number of CAT I items that will need to be reviewed in OpenShift.  

As you can see, there are only 7 CAT I items for the entire OpenShift Container Platform, with a total of 83 between CAT I, II, and III. This low number of STIG items is due to our security-focused approach which includes our container-specific OS (RHCOS), built-in security features such as read-only file systems, no root SSH logins, SELinux, running containers in restricted mode (rootless) and hardened control planes. Red Hat has thoroughly reviewed the security controls in NIST 800-53 to ensure that the Kubernetes layer included with OpenShift ships with an appropriate level of built-in security, so additional hardening requirements are minimal in comparison to other distributions of Kubernetes. 

Keep in mind that STIGs are checklists of items to review and potentially implement. It is up to each organization to decide which items they need to implement. Do not allow the presence or absence of a STIG to prevent good cybersecurity practices.

As of this writing, the current STIG version is for OpenShift 4.12. If you’re installing a newer version of OpenShift, no need to worry about not having a STIG. DISA provides guidance in their FAQ that if, “a STIG for an older version of the product is available, review the check and fix procedures to determine which of these work with the new product version.” No matter what version you use now, Red Hat has the tools to help implement STIGs and other security controls that are required to obtain the desired level of security and compliance.

Stay tuned for future articles in which we'll talk about how to implement the OpenShift STIG manually and then automate remediations using the Compliance Operator.