The way to customise the OpenShift Compliance Operator by utilizing a tailor-made profile – IBM Developer

[ad_1]

Overview

Builders now not simply construct functions, but in addition play important roles for infrastructure operations in DevOps and infrastructure as code (IaC) areas. In these conditions, you may additionally be answerable for the operation of take a look at infrastructure that runs on a managed service akin to Purple Hat OpenShift on IBM Cloud. Making certain its safety and regulatory compliance can also be essential and you could wish to automate such work. That automation might be facilitated by an OpenShift Operator known as Compliance Operator, which is a compliance standing test engine for OpenShift clusters.

Nevertheless, it’s not easy to make use of Compliance Operator for an OpenShift cluster working on IBM Cloud as a result of its set up is personalized to supply it as managed service. Because of this, a few of default guidelines and parameters don’t match the precise state and such mismatches trigger false positives. Subsequently, you will need to create a tailor-made profile to align the personalized set up.

Half 1: Introduction of guidelines, variables, profiles, and tailor-made profiles

Guidelines and variables

All the principles verified by the Compliance Operator are outlined within the ComplianceAsCode/content material challenge repository. For instance, contemplate the rule with the kubelet_eviction_thresholds_set_hard_imagefs_available ID as follows:

git clone https://github.com/ComplianceAsCode/content material
...
cd content material
tree functions/openshift/kubelet
functions/openshift/kubelet
...
├── kubelet_eviction_thresholds_set_hard_imagefs_available
│   ├── rule.yml
│   └── checks
...
├── var_kubelet_evictionhard_imagefs_available.var
...

The rule ID is represented by the listing title, whereas the precise rule is outlined in rule.yml underneath the rule listing:

...
title: 'Guarantee Eviction threshold Settings Are Set - evictionHard: imagefs.out there'
...
template:
  title: yamlfile_value
  vars:
    filepath: /and so on/kubernetes/kubelet.conf
    yamlpath: ".evictionHard['imagefs.available']"
    xccdf_variable: var_kubelet_evictionhard_imagefs_available

For this rule, the anticipated parameter worth within the /and so on/kubernetes/kubelet.conf YAML file is specified at yamlpath with a JSONPath expression known as .evictionHard['imagefs.available'], and it ought to match the worth of the var_kubelet_evictionhard_imagefs_available configuration variable. The configuration variable worth is saved in a distinct file; on this case, the file is var_kubelet_evictionhard_imagefs_available.var underneath the kubelet listing:

...
title: 'Configure Kubelet EvictonHard Picture FS Avilable'
...
sort: string
operator: equals
choices:
  default: "10%"
  5pc: "5%"
  10pc: "10%"
  15pc: "15%"
  20pc: "20%"

With the variable values illustrated above, the results of this rule evaluation is a PASS if .evictionHard['imagefs.available'] is the same as "10%" (the default worth).

Profiles

In a typical use case, an inner compliance officer or an exterior auditor requests validation in opposition to business regulation baselines or finest practices akin to NIST SP 800-53 reasonable or CIS Benchmarks. These regulation baselines and finest practices are represented within the ComplianceAsCode challenge as a profile. For instance, you will discover the NIST 800-53 Reasonable-Influence Baseline for Purple Hat OpenShift outlined in ocp4/profiles/reasonable.profile, and the CIS Purple Hat OpenShift Container Platform 4 Benchmark outlined in ocp4/profiles/cis-node.profile as follows:

...
title: 'CIS Purple Hat OpenShift Container Platform 4 Benchmark'
...
choices:
...
    - kubelet_eviction_thresholds_set_hard_imagefs_available
...

Every profile comprises its particular algorithm. The next diagram illustrates the relationships between the principles and the profiles.

Illustration of profiles and rules

Within the ComplianceAsCode/content material repository, many profiles are already outlined for well-known, business laws. See the Compliance Operator Customized Useful resource Definitions documentation for particulars on how admins and compliance engineers can specify a profile for his or her Compliance Operator scans by utilizing ComplianceScan or ComplianceSuite objects.

Examine outcomes

The test outcomes for every profile are registered as compliancecheckresult sources. Its title consists of the next three components:

${profile_name}-${role_name}-${rule_name}

  • profile_name is the title of the Profile or TailoredProfile specified within the ScanSettingBinding, ComplianceScan, or ComplianceSuite useful resource.
  • role_name is the .roles within the ScanSetting useful resource.
  • rule_name is the rule ID the place its underscores (_) had been changed with hyphens (-).

Subsequently, for instance, a compliancecheckresult useful resource named ocp-worker-kubelet-eviction-thresholds-set-hard-imagefs-available is the results of a rule during which the rule_id is kubelet_eviction_thresholds_set_hard_imagefs_available.

You’ll be able to specify a number of profiles (and tailor-made profiles) for a single cluster. For instance, once you configure the profiles named profile1 and profile2 for a rule known as rule1, you will note two compliancecheckresult sources with names which are profile1_rule1 and profile2_rule1 for every profile. The outcomes could differ as a result of every profile has its personal customized variables, which we are going to talk about in Half 3.

TailoredProfile

As you might have observed, the Compliance Operator guidelines and profiles are written in YAML format. Nevertheless, the Compliance Operator scans are executed in a Kubernetes cluster and its nodes with the oscap command, which solely accepts guidelines and profiles outlined in XCCDF format. Subsequently, you will need to compile the principles and the profiles which are in YAML format into an XCCDF knowledge stream file previous to utilizing Compliance Operator, and bundle the compiled contents as a Docker picture, which is sometimes called the content material picture. Whenever you try and customise the principles and the profiles, you will need to rebuild the XCCDF knowledge stream recordsdata as a content material picture along with modifying the contents.

To mitigate the customization workload, you possibly can customise the profile and the variables by utilizing a Compliance Operator mechanism known as TailoredProfile, which takes much less work than constructing your individual content material picture. With a tailor-made profile, you possibly can disable guidelines chosen in predefined profiles and set customized values for XCCDF variables. The next diagram describes the relationships between a predefined profile, a tailor-made profile, guidelines, and variables. On this instance, solely rule3 and the var1 = Y customized variable are utilized once you use this tailor-made profile for the Compliance Operator scan.

Illustration of a tailored profile

A tailor-made profile might be utilized utilizing ScanSetting and ScanSettingBinding sources. Be taught extra within the TailoredProfile part and ScanSetting and ScanSettingBinding part of the Customized Useful resource Definitions documentation for Compliance Operator.

Half 2: Tailoring course of

The precise tailoring course of consists of the next steps:

  1. Choose a predefined (also called a base) profile (for instance, cis-node), and carry out a scan with that profile.
  2. Get the FAIL rule names with the next command:

    oc get compliancecheckresult | grep FAIL
    

    You must see outcomes much like the next:

    ocp-master-kubelet-eviction-thresholds-set-hard-imagefs-available    FAIL     medium
    ocp-worker-kubelet-eviction-thresholds-set-hard-imagefs-available    FAIL     medium
    

  3. For every FAIL rule, when the remediation just isn’t an choice, contemplate disabling the rule itself or customizing the variables of the rule in a tailor-made profile.

    On this step, you will need to first discover the precise test logic of a rule. As we described earlier within the Examine outcomes part, you possibly can extract rule_id from the title of a compliancecheckresult useful resource. Through the use of the rule_id, now you can discover rule.yml, which comprises the precise test logic for that rule. To take action, use the next command:

     cd content material  # go to ComplianceAsCode/content material listing
     discover . -name kubelet_eviction_thresholds_set_hard_imagefs_available./functions/openshift/kubelet/kubelet_eviction_thresholds_set_hard_imagefs_available
     cat ./functions/openshift/kubelet/kubelet_eviction_thresholds_set_hard_imagefs_available/rule.yml
     ...
     title: 'Guarantee Eviction threshold Settings Are Set - evictionHard: imagefs.out there'
     ...
     template:
       title: yamlfile_value
       vars:
         filepath: /and so on/kubernetes/kubelet.conf
         yamlpath: ".evictionHard['imagefs.available']"
         xccdf_variable: var_kubelet_evictionhard_imagefs_available
    

    If a test logic comprises references to a variable, you will discover the file that defines the variable by linking collectively the xccdf_variable string with the .var suffix. For instance, the XCCDF variable known as var_kubelet_evictionhard_imagefs_available might be discovered within the var_kubelet_evictionhard_imagefs_available.var file:

     cd content material  # go to ComplianceAsCode/content material listing
     discover . -name var_kubelet_evictionhard_imagefs_available.var./functions/openshift/kubelet/var_kubelet_evictionhard_imagefs_available.var
    

    Lastly, create the tailor-made profile useful resource by specifying the disabled guidelines and new anticipated values. The rule title conference is ${profile_bundle_name}-${rule_name}:

    • ${profile_bundle_name} is often ocp4as a result of OpenShift guidelines are owned by an ocp4 profile bundle by default.
    • ${rule_name} is a hyphen-joined title (for instance,kubelet-eviction-thresholds-set-hard-imagefs-available), whereas a rule ID is a underscore-joined title (for instance, kubelet_eviction_thresholds_set_hard_imagefs_available).

      The next TailoredProfile instance reveals easy methods to specify a customized worth for the var_kubelet_evictionhard_imagefs_available variable and easy methods to disable the file_permissions_kube_apiserver rule. Observe that the rule and variable names begin with ocp4-, whereas the underscores (_) within the names are changed with hyphens (-).

      apiVersion: compliance.openshift.io/v1alpha1
      sort: TailoredProfile
      metadata:
      title: my-tailored-profile
      spec:
      setValues:
        - title: ocp4-var-kubelet-evictionhard-imagefs-available
          rationale: "stricter than default"
          worth: "5%"
      disableRules:
        - title: ocp4-file-permissions-kube-apiserver
          rationale: Goal file is hidden and no must test
      extends: ocp4-cis-node
      title: CIS Benchmark for OpenShift on IBM Cloud
      

Half 3: Executing concurrent scans of tailor-made profiles of the identical base profile

Assume that two compliance engineers tailor-made the identical base profile, cis-node.profile, as mycis-node-tailored-profile1 and mycis-node-tailored-profile2 with totally different values for the ocp4-var-kubelet-evictionhard-imagefs-available variable. The Compliance Operator checks the principles in each tailor-made profiles in keeping with the set anticipated variable values, and shops two outcomes for one rule as ComplianceCheckResults sources.

For instance, the test outcomes for the kubelet-eviction-thresholds-set-hard-imagefs-available rule are saved as follows (observe that the naming conference of ComplianceCheckResults is ${profile_name}-${role_name}-${rule_name} as described above):

NAME                                                                                         STATUS   SEVERITY
mycis-node-tailored-profile1-worker-kubelet-eviction-thresholds-set-hard-imagefs-available   PASS     medium
...
mycis-node-tailored-profile2-worker-kubelet-eviction-thresholds-set-hard-imagefs-available   FAIL     medium

Conclusion

The OpenShift Compliance Operator offers an adaptive means for an infrastructure operator to run compliance scans and confirm whether or not a Kubernetes cluster and its underlying nodes adjust to a number of specified regulatory profiles.

Our subsequent step is to facilitate the mixing of Compliance Operator into the IBM Cloud Safety and Compliance Middle for a compliance officer to handle safety and compliance controls and regulatory profiles throughout the IBM Cloud platform, together with Kubernetes, from a unified dashboard.

[ad_2]

Leave a Reply

Your email address will not be published. Required fields are marked *