IBM Z and LinuxONE - LinuxONE - Group home

Using Red Hat® OpenShift ®with the Compliance Operator and a tailored compliance profile for IBM® Z® and IBM® LinuxONE

  

Authors: Sanidhya (sanidhya.sanidhya@ibm.com), Rishika Kedia (rishika.kedia@in.ibm.com), Madhu Pillai (madhu.pillai1@ibm.com), SHIVA SAI K (shiva.sai.k1@ibm.com)

Organizations want to comply with the security standards. These standards are mostly issued  by national governance, corporate governance, or industrial standard organizations. The Compliance Operator is intended to help on the regulatory readiness of  Red Hat OpenShift clusters.

The Compliance Operator lets administrators describe the required compliance state of a cluster and provides them with an overview of gaps and ways to remediate them. The Compliance Operator assesses compliance of both the Kubernetes API resources of OpenShift Container Platform, as well as the nodes running the cluster. The Compliance Operator installs various profiles for different industry requirements like CIS or NIST. You can select the profile that fits best to your requirements.

Features of the Compliance Operator

·        Automated compliance checks: The operator automates the process of checking that the Red Hat OpenShift cluster and its various components (for ex, pods, services.) are in compliance with industry requirements. This helps ensure that the cluster is always in a compliant state and makes it easier to keep track of compliance status over time.

·        Automated remediation's: Many of the results of one compliance rule check can be remediated automatically. This comes with the Compliance Operator and can be easily configured.

·        Centralized management: The operator provides a centralized way to manage compliance-related tasks and configuration, making it easy to understand and control the compliance status of the entire cluster.

·        Improved security: By automating compliance checks and providing centralized management, the operator helps improve the overall security of the Red Hat OpenShift cluster.

Profiles in Compliance Operator

The Compliance Operator profiles provide rules mandated by a specific organizations or government authorities. Currently, the Compliance Operator for Red Hat OpenShift on IBM Z/IBM® LinuxONE is supporting the CIS and NIST profiles. Additional profiles like PCI-DSS, HIPPA are planned for future releases.

CIS

The CIS profile is a set of best practices and guidelines for securing various platforms and technologies, including Red Hat OpenShift. These guidelines cover a wide range of security controls, such as network security, access controls, and incident response. By following these guidelines, organizations can improve their overall security posture and reduce the risk of data breaches and other security incidents.

NIST

The NIST profile refers to a set of security and compliance standards outlined by the National Institute of Standards and Technology (NIST), a U.S. federal agency that develops and promotes measurement standards and guidelines. Applying the NIST profile in a Red Hat OpenShift cluster means to follow a series of security and compliance best practices and guidelines to ensure that your containerized applications and infrastructure meet certain security and regulatory requirements. These requirements are important for organizations that need to maintain a high level of security and compliance, especially in regulated industries like finance, healthcare, or government.

How to setup and use Compliance Operator on the Red Hat OpenShift cluster

Red Hat OpenShift comes with an OperatorHub, a web console interface in Red Hat OpenShift that cluster administrators use to discover and install Operators. With one click, an Operator can be pulled from its off-cluster source, installed, and subscribed on the cluster.

You can use the UI or the CLI to install the Compliance Operator. The detailed information is found in the Red Hat documentation.

Exploring the profiles and rules bundled with Compliance Operator

After installing the Compliance Operator, you can validate the installation by running the following command.

$ oc get csv -n openshift-compliance

To check the supported profiles in the Compliance Operator, do the following:

$ oc get profiles.compliance

NAME               AGE

ocp4-cis           45h

ocp4-cis-node      45h

ocp4-moderate      45h

ocp4-moderate-node 45h

To check specific rules in the profile, run the “oc describe” command. For example,

$ oc describe profiles.compliance ocp4-cis

One of the rules (e.g., for ocp4-cis) is ‘ocp4-api-server-encryption-provider-cipher’

To find the use case of a specific rule, run the following command:

$ oc describe rules.compliance ocp4-api-server-encryption-provider-cipher

Important excerpts from the description are the following:

Description: To ensure the correct cipher, set the encryption type aescbc in the apiserver object which configures the API server itself.

spec:

 encryption:

   type: aescbc

This describes the compliance state the rule is trying to achieve. We can also see available fixes for this rule in the description.

Available Fixes:

  Fix Object:

    API Version:  config.openshift.io/v1

    Kind:         APIServer

    Metadata:

      Name:  cluster

    Spec:

      Encryption:

        Type:  aescbc

Instructions: Run the following command:

$ oc get --raw /apis/config.openshift.io/v1/apiservers/cluster | jq [.spec.encryption.type]

The output should return aescbc as the encryption type.

It also provides instructions on how to manually check this state to the cluster administrator.

Finally, we can also see the rationale of why this rule is needed:

Rationale:  Where etcd encryption is used, it is important to ensure that the appropriate set of encryption providers is used. aescbc is currently the strongest encryption provider and supported by Red Hat OpenShift 

Understanding compliance-scan states, result, and rules statuses.

The compliance scan will go through the following cycles as mentioned in the STATE column of the command oc get scans

Status

Meaning

LAUNCHING

In this phase the scan is going through the process of gathering the system information and validating required resources are present or not

RUNNING

As the name implies, this state is where the actual scans are running on the different nodes of the Red Hat OpenShift cluster. During this phase, cluster admins can see the logs from the pods running in the compliance namespace for the respective rule scan.

AGGREGATING

Here the scan will aggregate the scan result from all the different nodes of the cluster and process it show as part of a coherent report.

DONE

This state marks the end of the compliance scan.

ERROR

This might come up if the scan has run into any issues in any of the above phases and cluster admins must troubleshoot the issue.

The RESULT column for the scan, is comprehensive as it provides the overall view of the scan results. This will imply that the rules have passed on some cluster nodes but failed on other nodes. Again, further investigation is needed by the cluster administrator to understand why this had occurred.

Result value

Meaning

COMPLIANT

all the rules on all the nodes have passed

NON-COMPLIANT

If some/all rules have failed across nodes.

INCONSISTENT

This will imply that the rules have passed on some cluster nodes but failed on other nodes.

The compliance status for individual rules of the scan with the command oc get ccr’, where ‘ccr’ stands for ‘compliancecheckresults’. This will show up a list of all the rules failing or passing in the scan, it might also have an error status if the scan for a rule ran into issues.

Creating custom ‘ScanSetting’ and ‘TailoredProfiles’

Compliance scans function through ‘ScanSetting’ and ‘ScanSettingBindings’. ScanSettings are used to define the configuration of scans, such as the schedule of scans, volume claims etc. One prominent feature is the ‘autoApplyRemediation’ option. This feature tries to remediate the failed rules by applying the predefined remediations. To learn more about the ‘scansetting api’, run the following command.

$ oc explain scansettings

ScanSetting binding are objects which, as the name suggests, binds to the ‘ScanSetting’. This object contains the information about the profiles to be included in the scan. Further information can be found using the following command:

$ oc explain scansettingbindings

Now, create a custom profile that is suitable to your organization's needs. It is called ‘TailoredProfile’. Let's look at the following ‘TailoredProfile’

apiVersion: compliance.openshift.io/v1alpha1

kind: TailoredProfile

metadata:

  name: ocp4-manual-scc-check

spec:

  extends: ocp4-cis

  description: This profile extends ocp4-cis by forcing the SCC check to always return MANUAL

  title: OCP4 CIS profile with manual SCC check

  manualRules:

    - name: ocp4-scc-limit-container-allowed-capabilities

rationale: We use third party software that installs its own SCC with extra privileges

This tailored profile will always return the result as MANUAL, implying that the rule should be verified by a human manually or, in this case, that a third-party software is verifying it. ‘TailoredProfiles’ provide the cluster administrator with a variety of customization options, ranging from disabling a rule to including only a few.

While the TailoredProfile CR (custom resource) enables the most common tailoring operations, the XCCDF (Extensible Configuration Checklist Description Format) standard allows more flexibility in tailoring OpenSCAP profiles. If your organization has been using OpenSCAP previously, you may have an existing XCCDF tailoring file that can be reused.

While this is a way to extend existing profiles. We can also create new profiles from scratch using the TailoredProfile CR. In this case we need to leave the extends field blank. And we can disable or enable rules similarly as specified in the previous example.

apiVersion: compliance.openshift.io/v1alpha1

kind: TailoredProfile

metadata:

  name: new-profile

spec:

  extends:

  description: Sample Tailored profile

  title: Sample tailored profile

  enableRules:

    - name: ocp4-scc-limit-container-allowed-capabilities

      rationale: Create an example profile with one rule

Steps to retrieve compliance results using the oc-compliance plugin

The Compliance Operator is great for the automation of checks and remediation's for a cluster. However, more administrator interaction is required to bring the cluster to a compliant state. For that,  the oc-compliance plugin can be used, a tool that acts as an interface between the administrator and the cluster. To setup the oc-compliance plugin you can refer to the Red Hat documentation or you can get the plugin by using the following command:

$ podman run --rm -v ~/.local/bin:/mnt/out:Z registry.redhat.io/compliance/oc-compliance-rhel8:stable /bin/cp /usr/bin/oc-compliance /mnt/out/

 

Although the ‘compliancecheckresult crd’ contains the result of all rules that had be checked during a scan, an administrator or an auditor might need more details of the scan. The OpenSCAP tool creates an Advanced Recording Format (ARF) formatted file with the detailed results. Since the ARF file is very large, a persistent volume is created to store it.

Let’s see how we can use this. First, we will create a ScanSettingBinding to test our TailoredProfile.

$ oc get tailoredProfiles.compliance

NAME          STATE

new-profile   READY

 

We see that the state of the TailoredProfile is ready. Note: the information is shown under TailoredProfile. The following ScanSettingBinding is created for our tailored profile.

apiVersion: compliance.openshift.io/v1alpha1

kind: ScanSettingBinding

metadata:

  name: ocp4-cis-custom

profiles:

  - apiGroup: compliance.openshift.io/v1alpha1

    kind: TailoredProfile

    name: new-profile

settingsRef:

  apiGroup: compliance.openshift.io/v1alpha1

  kind: ScanSetting

  name: default

 

Here we are using the default scan settings which implies that Compliance Operator will not try to auto remediate the rule. We can see the result of the scan in the following way:

$ oc get scans

NAME          PHASE   RESULT

new-profile   DONE    COMPLIANT

We can also check the individual rules status with the ccr (compliancecheckresults) command

$ oc get ccr

NAME                                                   STATUS   SEVERITY

new-profile-scc-limit-container-allowed-capabilities   PASS     medium

The oc-compliance plugin can generate powerful reports that can be viewed in human readable HTML format, which is very convenient for analysis and presentation. To achieve this, first, we need to extract the raw results from the ScanSettingBinding using the following command.

$ oc compliance fetch-raw scansettingbinding ocp4-cis-custom -o resultsdir/

This will extract the results in the compressed format in the ‘resultsdir’.

$ ls -lrt resultsdir/new-profile/new-profile-api-checks-pod.xml.bzip2

-rw-r--r--. 1 root root 259455 Mar 20 08:20 resultsdir/new-profile/new-profile-api-checks-pod.xml.bzip2

The html format of report file can be created by using the OpenSCAP tool.

$ oscap xccdf generate report resultsdir/new-profile/new-profile-api-checks-pod.xml.bzip2 >> ./ocp4-cis-api-checks.html

The html format can be opened in a browser; below is the preview of our case.

The following picture shows the overview of the compliance scan process.

Summary

The Compliance Operator for Red Hat OpenShift brings a powerful solution for robust security and compliance management in containerized environments on the IBM Z and IBM® LinuxONE platforms. With support for CIS and NIST profiles, it covers to a wide array of regulatory standards, ensuring your Red Hat OpenShift cluster adheres to the highest security benchmarks.

It simplifies the process of scanning and retrieving compliance results, helping administrators to maintain a secure and compliant infrastructure. The integration with the OpenSCAP tool provides a user-friendly graphical interface for viewing the scan results, enabling a quick decision-making.

Moreover, the Compliance Operator goes beyond daily management. It plays a pivotal role in audits, offering a comprehensive record of compliance efforts, which can be useful to demonstrate compliance with legal standards.

The Compliance Operator can be easily adapted to integrate seamlessly into various organizational environments, ensuring a standardized and efficient approach to compliance management. For example, the IBM Z Security and Compliance Center is using the Compliance Operator to scan IBM Z / IBM® LinuxONE environments.

Whether you’re using it for your Red Hat OpenShift cluster or seeking to enhance compliance across your infrastructure, the Compliance Operator is an asset on your journey towards a more secure and compliant future.