Summary
Red Hat OpenShift is an enterprise-grade implementation of Kubernetes, a core computing platform of cloud-native computing. To use it for regulated industries, it is important to ensure the compliance posture of the OpenShift platform. For such a purpose, an administrator of OpenShift can use Compliance Operator, an OpenShift Operator that allows the administrator to run compliance scans. However, Compliance Operator have been mainly focusing on on-premise installations, and therefore it had not supported managed OpenShift clusters.
To add the support for the managedｄ cluster, we have delivered a new functionality for Compliance Operator and ComplianceAsCode, its rule set. We then integrated this new Compliance Operator with Red Hat OpenShift on IBM Cloud as a reference case of the use for managed OpenShift clusters. With this enhancement, the compliance representatives of an enterprise organization can validate including not only the technically-detailed compliance posture of the cluster's worker node but also that of the cluster's master node and control-plane components using a publicly-available (in other words "verifiable") rule set, in addition to the IBM Cloud's support for various regulations such as HIPAA and PCI-DSS.
Rest of this post describes how we designed and implemented the managed service support for Compliance Operator, which is informative for engineers responsible for designing compliance-aware OpenShift infrastructures.
Background and Challenge: compliance check for managed OpenShift clusters
Red Hat OpenShift on IBM Cloud is one of the managed OpenShift services. As similar to other managed OpenShift services, OpenShift users and IBM share responsibilities to maintain a managed OpenShift cluster. In case of Red Hat OpenShift on IBM Cloud, control-plane components of the OpenShift cluster is protected by IBM using HyperShift, a toolkit to manage multiple control-plane components at scale. This protection mechanism prevented Compliance Operator from checking the control-plane components because check target resources (configuration data and configuration files) are located different positions than those of a stand-alone OpenShift cluster.
Solution: runtime rule customization
We provided a new functionality to support runtime customization for both Compliance Operator (check engine) and ComplianceAsCode (rule set). Example of a classic ComplianceAsCode rule is as follows.
template:
name: yamlfile_value
vars:
ocp_data: "true"
entity_check: "none satisfy"
filepath: /api/v1/namespaces/openshift-kube-apiserver/configmaps/config
yamlpath: '.data["config.yaml"]'
values:
- value: '"enable-admission-plugins":\[[^]]*"AlwaysAdmit"'
operation: "pattern match"
type: "string"
The location of check target is hard-coded (api/v1/namespaces/openshift-kube-apiserver/configmaps/config), and thus this rule cannot be used for the Kube API server of HyperShift control planes because the HyperShift operator relocates this resource to another location; the name of resource is changed to kas-config, and its namespace varies on runtime.
In the revised rule below, the location for the check target resource is configurable using variables (var_openshift_kube_apiserver_config_data_name, var_openshift_kube_apiserver_namespace and var_openshift_kube_apiserver_config), and Compliance Operator embeds these values to the rule at runtime. By default, the values are set with the ones used by stand-alone OpenShift installation, and a compliance engineer can specify other values using Tailored Profile capability of Compliance Operator in case of HyperShift environment.
{{% set custom_jqfilter = '[.data."{{.var_openshift_kube_apiserver_config_data_name}}" | fromjson]' %}}
{{% set default_jqfilter = '[.data."config.yaml" | fromjson]' %}}
{{% set custom_api_path = '/api/v1/namespaces/{{.var_openshift_kube_apiserver_namespace}}/configmaps/{{.var_openshift_kube_apiserver_config}}' %}}
{{% set default_api_path = '/api/v1/namespaces/openshift-kube-apiserver/configmaps/config' %}}
{{% set dump_path = default_api_path ~ ',' ~ default_jqfilter ~ ',' ~ custom_jqfilter %}}
...
warnings:
- general: |-
{{{ openshift_filtered_cluster_setting({custom_api_path: dump_path}) | indent(4) }}}
...
template:
name: yamlfile_value
vars:
ocp_data: "true"
check_existence: "none_exist"
filepath: {{{ openshift_filtered_path(default_api_path, default_jqfilter) }}}
yamlpath: '.apiServerArguments["enable-admission-plugins"][:]'
values:
- value: '^AlwaysAdmit$'
operation: "pattern match"
Integration with Managed Service
We have integrated this enhanced Compliance Operator with the development process of Red Hat OpenShift on IBM Cloud, a managed OpenShift service. When a developer requests merging a branch to apply an update to the deployment code of the managed service, a CI (continuous integration) test tool of its code repository triggers a Compliance Operator scan. If the scan result is non-compliant, the merger will not be permitted. This process ensures that the deployment code instantiates an OpenShift cluster onto production environment without violating compliance rules.
More Info
OpenShift and Red Hat OpenShift on IBM Cloud
Kubernetes components and HyperShift
Compliance Operator and CIS Benchmark result of Red Hat OpenShift on IBM Cloud
#Highlights-home
#Highlights