5.4. Compliance Operator の概念

5.4.1. Compliance Operator について

Compliance Operator を使用すると、OpenShift Container Platform 管理者はクラスターの必要なコンプライアンス状態を記述し、存在するギャップやそれらを修復する方法に関する概要を提供します。Compliance Operator は、OpenShift Container Platform の Kubernetes API リソースと、クラスターを実行するノードの両方のコンプライアンスを評価します。Compliance Operator は、NIST 認定ツールである OpenSCAP を使用して、コンテンツが提供するセキュリティーポリシーをスキャンし、これを適用します。

重要

Compliance Operator は Red Hat Enterprise Linux CoreOS (RHCOS) デプロイメントでのみ利用できます。

5.4.1.1. Compliance Operator のプロファイル

Compliance Operator のインストールの一部として利用可能なプロファイルは複数あります。oc get コマンドを使用して、使用可能なプロファイル、プロファイルの詳細、および特定のルールを表示できます。

利用可能なプロファイルを表示します。

$ oc get profile.compliance -n openshift-compliance

出力例

NAME                       AGE     VERSION
ocp4-cis                   3h49m   1.5.0
ocp4-cis-1-4               3h49m   1.4.0
ocp4-cis-1-5               3h49m   1.5.0
ocp4-cis-node              3h49m   1.5.0
ocp4-cis-node-1-4          3h49m   1.4.0
ocp4-cis-node-1-5          3h49m   1.5.0
ocp4-e8                    3h49m
ocp4-high                  3h49m   Revision 4
ocp4-high-node             3h49m   Revision 4
ocp4-high-node-rev-4       3h49m   Revision 4
ocp4-high-rev-4            3h49m   Revision 4
ocp4-moderate              3h49m   Revision 4
ocp4-moderate-node         3h49m   Revision 4
ocp4-moderate-node-rev-4   3h49m   Revision 4
ocp4-moderate-rev-4        3h49m   Revision 4
ocp4-nerc-cip              3h49m
ocp4-nerc-cip-node         3h49m
ocp4-pci-dss               3h49m   3.2.1
ocp4-pci-dss-3-2           3h49m   3.2.1
ocp4-pci-dss-4-0           3h49m   4.0.0
ocp4-pci-dss-node          3h49m   3.2.1
ocp4-pci-dss-node-3-2      3h49m   3.2.1
ocp4-pci-dss-node-4-0      3h49m   4.0.0
ocp4-stig                  3h49m   V2R1
ocp4-stig-node             3h49m   V2R1
ocp4-stig-node-v1r1        3h49m   V1R1
ocp4-stig-node-v2r1        3h49m   V2R1
ocp4-stig-v1r1             3h49m   V1R1
ocp4-stig-v2r1             3h49m   V2R1
rhcos4-e8                  3h49m
rhcos4-high                3h49m   Revision 4
rhcos4-high-rev-4          3h49m   Revision 4
rhcos4-moderate            3h49m   Revision 4
rhcos4-moderate-rev-4      3h49m   Revision 4
rhcos4-nerc-cip            3h49m
rhcos4-stig                3h49m   V2R1
rhcos4-stig-v1r1           3h49m   V1R1
rhcos4-stig-v2r1           3h49m   V2R1

これらのプロファイルは、複数の異なるコンプライアンスベンチマークを表します。各プロファイルには、適用先の製品名がプロファイル名の接頭辞として追加されます。ocp4-e8 は Essential 8 ベンチマークを OpenShift Container Platform 製品に適用し、rhcos4-e8 は Essential 8 ベンチマークを Red Hat Enterprise Linux CoreOS (RHCOS) 製品に適用します。

以下のコマンドを実行して、rhcos4-e8 プロファイルの詳細を表示します。

$ oc get -n openshift-compliance -oyaml profiles.compliance rhcos4-e8

例5.1 出力例

apiVersion: compliance.openshift.io/v1alpha1
description: 'This profile contains configuration checks for Red Hat Enterprise Linux
  CoreOS that align to the Australian Cyber Security Centre (ACSC) Essential Eight.
  A copy of the Essential Eight in Linux Environments guide can be found at the ACSC
  website: https://www.cyber.gov.au/acsc/view-all-content/publications/hardening-linux-workstations-and-servers'
id: xccdf_org.ssgproject.content_profile_e8
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/image-digest: pb-rhcos4hrdkm
    compliance.openshift.io/product: redhat_enterprise_linux_coreos_4
    compliance.openshift.io/product-type: Node
  creationTimestamp: "2022-10-19T12:06:49Z"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: rhcos4
  name: rhcos4-e8
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: rhcos4
    uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
  resourceVersion: "43699"
  uid: 86353f70-28f7-40b4-bf0e-6289ec33675b
rules:
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
- rhcos4-audit-rules-dac-modification-chown
- rhcos4-audit-rules-execution-chcon
- rhcos4-audit-rules-execution-restorecon
- rhcos4-audit-rules-execution-semanage
- rhcos4-audit-rules-execution-setfiles
- rhcos4-audit-rules-execution-setsebool
- rhcos4-audit-rules-execution-seunshare
- rhcos4-audit-rules-kernel-module-loading-delete
- rhcos4-audit-rules-kernel-module-loading-finit
- rhcos4-audit-rules-kernel-module-loading-init
- rhcos4-audit-rules-login-events
- rhcos4-audit-rules-login-events-faillock
- rhcos4-audit-rules-login-events-lastlog
- rhcos4-audit-rules-login-events-tallylog
- rhcos4-audit-rules-networkconfig-modification
- rhcos4-audit-rules-sysadmin-actions
- rhcos4-audit-rules-time-adjtimex
- rhcos4-audit-rules-time-clock-settime
- rhcos4-audit-rules-time-settimeofday
- rhcos4-audit-rules-time-stime
- rhcos4-audit-rules-time-watch-localtime
- rhcos4-audit-rules-usergroup-modification
- rhcos4-auditd-data-retention-flush
- rhcos4-auditd-freq
- rhcos4-auditd-local-events
- rhcos4-auditd-log-format
- rhcos4-auditd-name-format
- rhcos4-auditd-write-logs
- rhcos4-configure-crypto-policy
- rhcos4-configure-ssh-crypto-policy
- rhcos4-no-empty-passwords
- rhcos4-selinux-policytype
- rhcos4-selinux-state
- rhcos4-service-auditd-enabled
- rhcos4-sshd-disable-empty-passwords
- rhcos4-sshd-disable-gssapi-auth
- rhcos4-sshd-disable-rhosts
- rhcos4-sshd-disable-root-login
- rhcos4-sshd-disable-user-known-hosts
- rhcos4-sshd-do-not-permit-user-env
- rhcos4-sshd-enable-strictmodes
- rhcos4-sshd-print-last-log
- rhcos4-sshd-set-loglevel-info
- rhcos4-sysctl-kernel-dmesg-restrict
- rhcos4-sysctl-kernel-kptr-restrict
- rhcos4-sysctl-kernel-randomize-va-space
- rhcos4-sysctl-kernel-unprivileged-bpf-disabled
- rhcos4-sysctl-kernel-yama-ptrace-scope
- rhcos4-sysctl-net-core-bpf-jit-harden
title: Australian Cyber Security Centre (ACSC) Essential Eight

以下のコマンドを実行して、rhcos4-audit-rules-login-events ルール の詳細を表示します。

$ oc get -n openshift-compliance -oyaml rules rhcos4-audit-rules-login-events

例5.2 出力例

apiVersion: compliance.openshift.io/v1alpha1
checkType: Node
description: |-
  The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix.rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events:

  -w /var/log/tallylog -p wa -k logins
  -w /var/run/faillock -p wa -k logins
  -w /var/log/lastlog -p wa -k logins

  If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

  -w /var/log/tallylog -p wa -k logins
  -w /var/run/faillock -p wa -k logins
  -w /var/log/lastlog -p wa -k logins
id: xccdf_org.ssgproject.content_rule_audit_rules_login_events
kind: Rule
metadata:
  annotations:
    compliance.openshift.io/image-digest: pb-rhcos4hrdkm
    compliance.openshift.io/rule: audit-rules-login-events
    control.compliance.openshift.io/NIST-800-53: AU-2(d);AU-12(c);AC-6(9);CM-6(a)
    control.compliance.openshift.io/PCI-DSS: Req-10.2.3
    policies.open-cluster-management.io/controls: AU-2(d),AU-12(c),AC-6(9),CM-6(a),Req-10.2.3
    policies.open-cluster-management.io/standards: NIST-800-53,PCI-DSS
  creationTimestamp: "2022-10-19T12:07:08Z"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: rhcos4
  name: rhcos4-audit-rules-login-events
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: rhcos4
    uid: 22350850-af4a-4f5c-9a42-5e7b68b82d7d
  resourceVersion: "44819"
  uid: 75872f1f-3c93-40ca-a69d-44e5438824a4
rationale: Manual editing of these files may indicate nefarious activity, such as
  an attacker attempting to remove evidence of an intrusion.
severity: medium
title: Record Attempts to Alter Logon and Logout Events
warning: Manual editing of these files may indicate nefarious activity, such as an
  attacker attempting to remove evidence of an intrusion.

5.4.1.1.1. Compliance Operator のプロファイルタイプ

コンプライアンスプロファイルとして、Platform と Node の 2 種類を使用できます。

プラットフォーム: Platform スキャンの対象は、OpenShift Container Platform クラスターです。
ノード: Node スキャンの対象は、クラスターのノードです。

重要

pci-dss コンプライアンスプロファイルなのような、Node アプリケーションと Platform アプリケーションを含むコンプライアンスプロファイルの場合は、OpenShift Container Platform 環境で両方を実行する必要があります。

5.4.1.2. 関連情報

サポートされているコンプライアンスプロファイル

5.4.2. カスタムリソース定義を理解する

OpenShift Container Platform の Compliance Operator は、コンプライアンススキャンを実行するためのいくつかのカスタムリソース定義 (CRD) を提供します。コンプライアンススキャンを実行するには、ComplianceAsCode コミュニティープロジェクトから派生した事前定義されたセキュリティーポリシーを利用します。コンプライアンスオペレーターは、これらのセキュリティーポリシーを CRD に変換します。これを使用して、コンプライアンススキャンを実行し、見つかった問題の修正を取得できます。

5.4.2.1. CRD ワークフロー

CRD は、コンプライアンススキャンを完了するための次のワークフローを提供します。

コンプライアンススキャン要件を定義する
コンプライアンススキャン設定を設定する
コンプライアンススキャン設定を使用してコンプライアンス要件を処理する
コンプライアンススキャンをモニターする
コンプライアンススキャンの結果を確認する

5.4.2.2. コンプライアンススキャン要件の定義

デフォルトでは、Compliance Operator CRD には ProfileBundle オブジェクトと Profile オブジェクトが含まれており、これらのオブジェクトでコンプライアンススキャン要件のルールを定義および設定できます。TailoredProfile オブジェクトを使用して、デフォルトのプロファイルをカスタマイズすることもできます。

5.4.2.2.1. ProfileBundle オブジェクト

Compliance Operator のインストール時に、すぐに実行できる ProfileBundle オブジェクトが含まれます。コンプライアンスオペレーターは、ProfileBundle オブジェクトを解析し、バンドル内のプロファイルごとに Profile オブジェクトを作成します。また、Profile オブジェクトによって使用される Rule オブジェクトと Variable オブジェクトも解析します。

ProfileBundle オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ProfileBundle
  name: <profile bundle name>
  namespace: openshift-compliance
status:
  dataStreamStatus: VALID 1

1: コンプライアンスオペレーターがコンテンツファイルを解析できたかどうかを示します。

注記

contentFile が失敗すると、発生したエラーの詳細を提供する errorMessage 属性が表示されます。

トラブルシューティング

無効なイメージから既知のコンテンツイメージにロールバックすると、ProfileBundle オブジェクトは応答を停止し、PENDING 状態を表示します。回避策として、前のイメージとは異なるイメージに移動できます。または、ProfileBundle オブジェクトを削除して再作成し、作業状態に戻すこともできます。

5.4.2.2.2. プロファイルオブジェクト

Profile オブジェクトは、特定のコンプライアンス標準を評価できるルールと変数を定義します。XCCDF 識別子や Node または Platform タイプのプロファイルチェックなど、OpenSCAP プロファイルに関する解析済みの詳細が含まれています。Profile オブジェクトを直接使用することも、TailorProfile オブジェクトを使用してさらにカスタマイズすることもできます。

注記

Profile オブジェクトは単一の ProfileBundle オブジェクトから派生しているため、手動で作成または変更することはできません。通常、1 つの ProfileBundle オブジェクトに複数の Profile オブジェクトを含めることができます。

Profile オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
description: <description of the profile>
id: xccdf_org.ssgproject.content_profile_moderate 1
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/product: <product name>
    compliance.openshift.io/product-type: Node 2
  creationTimestamp: "YYYY-MM-DDTMM:HH:SSZ"
  generation: 1
  labels:
    compliance.openshift.io/profile-bundle: <profile bundle name>
  name: rhcos4-moderate
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: <profile bundle name>
    uid: <uid string>
  resourceVersion: "<version number>"
  selfLink: /apis/compliance.openshift.io/v1alpha1/namespaces/openshift-compliance/profiles/rhcos4-moderate
  uid: <uid string>
rules: 3
- rhcos4-account-disable-post-pw-expiration
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
- rhcos4-audit-rules-dac-modification-chown
title: <title of the profile>

1: プロファイルの XCCDF 名を指定します。スキャンのプロファイル属性の値として ComplianceScan オブジェクトを定義する場合は、この識別子を使用します。
2: Node または Platform のいずれかを指定します。ノードプロファイルはクラスターノードをスキャンし、プラットフォームプロファイルは Kubernetes プラットフォームをスキャンします。
3: プロファイルのルールのリストを指定します。各ルールは 1 つのチェックに対応します。

5.4.2.2.3. ルールオブジェクト

プロファイルを形成する Rule オブジェクトも、オブジェクトとして公開されます。Rule オブジェクトを使用して、コンプライアンスチェック要件を定義し、それを修正する方法を指定します。

Rule オブジェクトの例

    apiVersion: compliance.openshift.io/v1alpha1
    checkType: Platform 1
    description: <description of the rule>
    id: xccdf_org.ssgproject.content_rule_configure_network_policies_namespaces 2
    instructions: <manual instructions for the scan>
    kind: Rule
    metadata:
      annotations:
        compliance.openshift.io/rule: configure-network-policies-namespaces
        control.compliance.openshift.io/CIS-OCP: 5.3.2
        control.compliance.openshift.io/NERC-CIP: CIP-003-3 R4;CIP-003-3 R4.2;CIP-003-3
          R5;CIP-003-3 R6;CIP-004-3 R2.2.4;CIP-004-3 R3;CIP-007-3 R2;CIP-007-3 R2.1;CIP-007-3
          R2.2;CIP-007-3 R2.3;CIP-007-3 R5.1;CIP-007-3 R6.1
        control.compliance.openshift.io/NIST-800-53: AC-4;AC-4(21);CA-3(5);CM-6;CM-6(1);CM-7;CM-7(1);SC-7;SC-7(3);SC-7(5);SC-7(8);SC-7(12);SC-7(13);SC-7(18)
      labels:
        compliance.openshift.io/profile-bundle: ocp4
      name: ocp4-configure-network-policies-namespaces
      namespace: openshift-compliance
    rationale: <description of why this rule is checked>
    severity: high 3
    title: <summary of the rule>

1: このルールが実行するチェックのタイプを指定します。Node プロファイルはクラスターノードをスキャンし、Platform プロファイルは Kubernetes プラットフォームをスキャンします。空の値は、自動チェックがないことを示します。
2: データストリームから直接解析されるルールの XCCDF 名を指定します。
3: 失敗したときのルールの重大度を指定します。

注記

Rule オブジェクトは、関連付けられた ProfileBundle オブジェクトを簡単に識別できるように適切なラベルを取得します。ProfileBundle は、このオブジェクトの OwnerReferences でも指定されます。

5.4.2.2.4. TailoredProfile オブジェクト

TailoredProfile オブジェクトを使用して、組織の要件に基づいてデフォルトの Profile オブジェクトを変更します。ルールを有効または無効にしたり、変数値を設定したり、カスタマイズの正当性を示したりすることができます。検証後、TailoredProfile オブジェクトは ConfigMap を作成します。これは、ComplianceScan オブジェクトから参照できます。

ヒント

ScanSettingBinding オブジェクトで参照することにより、TailoredProfile オブジェクトを使用できます。ScanSettingBinding の詳細は、ScanSettingBinding オブジェクトを参照してください。

TailoredProfile オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: TailoredProfile
metadata:
  name: rhcos4-with-usb
spec:
  extends: rhcos4-moderate 1
  title: <title of the tailored profile>
  disableRules:
    - name: <name of a rule object to be disabled>
      rationale: <description of why this rule is checked>
status:
  id: xccdf_compliance.openshift.io_profile_rhcos4-with-usb 2
  outputRef:
    name: rhcos4-with-usb-tp 3
    namespace: openshift-compliance
  state: READY 4

1: これは任意です。TailoredProfile がビルドされる Profile オブジェクトの名前。値が設定されていない場合は、enableRules リストから新しいプロファイルが作成されます。
2: 調整されたプロファイルの XCCDF 名を指定します。
3: ConfigMap 名を指定します。これは、ComplianceScan の tailoringConfigMap.name 属性の値として使用できます。
4: READY、PENDING、FAILURE などのオブジェクトの状態を表示します。オブジェクトの状態が ERROR の場合、属性 status.errorMessage が失敗の理由を提供します。

TailoredProfile オブジェクトを使用すると、TailoredProfile コンストラクトを使用して新しい Profile オブジェクトを作成できます。新しい Profile を作成するには、次の設定パラメーターを設定します。

適切なタイトル
extends は空でなければなりません
TailoredProfile オブジェクトのスキャンタイプアノテーション:
```
compliance.openshift.io/product-type: Platform/Node
```
注記
product-type のアノテーションを設定していない場合、コンプライアンスオペレーターはデフォルトで Platform スキャンタイプになります。TailoredProfile オブジェクトの名前に -node 接尾辞を追加すると、node スキャンタイプになります。

5.4.2.3. コンプライアンススキャン設定の設定

コンプライアンススキャンの要件を定義した後、スキャンのタイプ、スキャンの発生、およびスキャンの場所を指定することにより、コンプライアンススキャンを設定できます。そのために、Compliance Operator は ScanSetting オブジェクトを提供します。

5.4.2.3.1. ScanSetting オブジェクト

ScanSetting オブジェクトを使用して、スキャンを実行するための運用ポリシーを定義および再利用します。デフォルトでは、コンプライアンスオペレータは次の ScanSetting オブジェクトを作成します。

default - 1Gi Persistent Volume (PV) を使用して、マスターノードとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。修復は自動的に適用も更新もされません。
default - 1Gi Persistent Volume (PV) を使用して、コントロールプレーンとワーカーノードの両方で毎日午前 1 時にスキャンを実行し、最後の 3 つの結果を保持します。autoApplyRemediations と autoUpdateRemediations の両方が true に設定されています。

ScanSetting オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
autoApplyRemediations: true 1
autoUpdateRemediations: true 2
kind: ScanSetting
maxRetryOnTimeout: 3
metadata:
  creationTimestamp: "2022-10-18T20:21:00Z"
  generation: 1
  name: default-auto-apply
  namespace: openshift-compliance
  resourceVersion: "38840"
  uid: 8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/master: ""
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3 3
  size: 1Gi 4
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
roles: 5
- master
- worker
scanTolerations:
- operator: Exists
schedule: 0 1 * * * 6
showNotApplicable: false
strictNodeScan: true
timeout: 30m

1: 自動修復を有効にするには、true に設定します。自動修復を無効にするには、false に設定します。
2: コンテンツ更新の自動修復を有効にするには、true に設定します。コンテンツ更新の自動修復を無効にするには、false に設定します。
3: 生の結果形式で保存されたスキャンの数を指定します。デフォルト値は 3 です。古い結果がローテーションされると、管理者はローテーションが発生する前に結果を別の場所に保存する必要があります。
4: 生の結果を保存するためにスキャン用に作成する必要があるストレージサイズを指定します。デフォルト値は 1Gi です。
6: スキャンを実行する頻度を cron 形式で指定します。
注記
ローテーションポリシーを無効にするには、値を 0 に設定します。
5: node-role.kubernetes.io ラベル値を指定して、Node タイプのスキャンをスケジュールします。この値は、MachineConfigPool の名前と一致する必要があります。

5.4.2.4. コンプライアンススキャン設定を使用したコンプライアンススキャン要件の処理

コンプライアンススキャン要件を定義し、スキャンを実行するように設定すると、コンプライアンスオペレーターは ScanSettingBinding オブジェクトを使用してそれを処理します。

5.4.2.4.1. ScanSettingBinding オブジェクト

ScanSettingBinding オブジェクトを使用して、Profile または TailoredProfile オブジェクトを参照してコンプライアンス要件を指定します。次に、スキャンの操作上の制約を提供する ScanSetting オブジェクトにリンクされます。次に、Compliance Operator は、ScanSetting オブジェクトと ScanSettingBinding オブジェクトに基づいて ComplianceSuite オブジェクトを生成します。

ScanSettingBinding オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: <name of the scan>
profiles: 1
  # Node checks
  - name: rhcos4-with-usb
    kind: TailoredProfile
    apiGroup: compliance.openshift.io/v1alpha1
  # Cluster checks
  - name: ocp4-moderate
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef: 2
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

1: Profile または TailoredProfile オブジェクトの詳細を指定して、環境をスキャンします。
2: スケジュールやストレージサイズなどの運用上の制約を指定します。

ScanSetting オブジェクトと ScanSettingBinding オブジェクトを作成すると、コンプライアンススイートが作成されます。コンプライアンススイートのリストを取得するには、次のコマンドを実行します。

$ oc get compliancesuites

重要

ScanSettingBinding を削除すると、コンプライアンススイートも削除されます。

5.4.2.5. コンプライアンススキャンの追跡

コンプライアンススイートの作成後、ComplianceSuite オブジェクトを使用して、デプロイされたスキャンのステータスをモニターできます。

5.4.2.5.1. ComplianceSuite オブジェクト

ComplianceSuite オブジェクトは、スキャンの状態を追跡するのに役立ちます。スキャンと全体的な結果を作成するための生の設定が含まれています。

Node タイプのスキャンの場合、問題の修正が含まれているため、スキャンを MachineConfigPool にマップする必要があります。ラベルを指定する場合は、それがプールに直接適用されることを確認してください。

ComplianceSuite オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: <name of the scan>
spec:
  autoApplyRemediations: false 1
  schedule: "0 1 * * *" 2
  scans: 3
    - name: workers-scan
      scanType: Node
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc...
      rule: "xccdf_org.ssgproject.content_rule_no_netrc_files"
      nodeSelector:
        node-role.kubernetes.io/worker: ""
status:
  Phase: DONE 4
  Result: NON-COMPLIANT 5
  scanStatuses:
  - name: workers-scan
    phase: DONE
    result: NON-COMPLIANT

1: 自動修復を有効にするには、true に設定します。自動修復を無効にするには、false に設定します。
2: スキャンを実行する頻度を cron 形式で指定します。
3: クラスターで実行するスキャン仕様のリストを指定します。
4: スキャンの進行状況を示します。
5: スイートの全体的な判断を示します。

バックグラウンドのスイートは、scans パラメーターに基づいて ComplianceScan オブジェクトを作成します。プログラムで ComplianceSuites イベントを取得できます。スイートのイベントを取得するには、次のコマンドを実行します。

$ oc get events --field-selector involvedObject.kind=ComplianceSuite,involvedObject.name=<name of the suite>

重要

手動で ComplianceSuite を定義すると、XCCDF 属性が含まれているため、エラーが発生する可能性があります。

5.4.2.5.2. 高度な ComplianceScan オブジェクト

コンプライアンスオペレーターには、デバッグまたは既存のツールとの統合のための上級ユーザー向けのオプションが含まれています。ComplianceScan オブジェクトを直接作成しないことを推奨しますが、代わりに、ComplianceSuite オブジェクトを使用してオブジェクトを管理できます。

高度な ComplianceScan オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: <name of the scan>
spec:
  scanType: Node 1
  profile: xccdf_org.ssgproject.content_profile_moderate 2
  content: ssg-ocp4-ds.xml
  contentImage: registry.redhat.io/compliance/openshift-compliance-content-rhel8@sha256:45dc... 3
  rule: "xccdf_org.ssgproject.content_rule_no_netrc_files" 4
  nodeSelector: 5
    node-role.kubernetes.io/worker: ""
status:
  phase: DONE 6
  result: NON-COMPLIANT 7

1: Node または Platform のいずれかを指定します。ノードプロファイルはクラスターノードをスキャンし、プラットフォームプロファイルは Kubernetes プラットフォームをスキャンします。
2: 実行するプロファイルの XCCDF 識別子を指定します。
3: プロファイルファイルをカプセル化するコンテナーイメージを指定します。
4: これはオプションです。単一のルールを実行するスキャンを指定します。このルールは XCCDF ID で識別され、指定されたプロファイルに属している必要があります。
注記
rule パラメーターをスキップすると、指定されたプロファイルで使用可能なすべてのルールに対してスキャンが実行されます。
5: OpenShift Container Platform を使用していて、修復を生成したい場合は、nodeSelector ラベルが MachineConfigPool ラベルと一致する必要があります。
注記
nodeSelector パラメーターを指定しないか、MachineConfig ラベルと一致しない場合でも、スキャンは実行されますが、修復は作成されません。
6: スキャンの現在のフェーズを示します。
7: スキャンの判定を示します。

重要

ComplianceSuite オブジェクトを削除すると、関連するすべてのスキャンが削除されます。

スキャンが完了すると、ComplianceCheckResult オブジェクトのカスタムリソースとして結果が生成されます。ただし、生の結果は ARF 形式で入手できます。これらの結果は、スキャンの名前に関連付けられた永続ボリュームクレーム (PVC) を持つ永続ボリューム (PV) に保存されます。プログラムで ComplianceScans イベントを取得できます。スイートのイベントを生成するには、次のコマンドを実行します。

oc get events --field-selector involvedObject.kind=ComplianceScan,involvedObject.name=<name of the suite>

5.4.2.6. コンプライアンス結果の表示

コンプライアンススイートが DONE フェーズに達すると、スキャン結果と可能な修正を表示できます。

5.4.2.6.1. ComplianceCheckResult オブジェクト

特定のプロファイルでスキャンを実行すると、プロファイル内のいくつかのルールが検証されます。これらのルールごとに、ComplianceCheckResult オブジェクトが作成され、特定のルールのクラスターの状態が提供されます。

ComplianceCheckResult オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceCheckResult
metadata:
  labels:
    compliance.openshift.io/check-severity: medium
    compliance.openshift.io/check-status: FAIL
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
  name: workers-scan-no-direct-root-logins
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceScan
    name: workers-scan
description: <description of scan check>
instructions: <manual instructions for the scan>
id: xccdf_org.ssgproject.content_rule_no_direct_root_logins
severity: medium 1
status: FAIL 2

1

スキャンチェックの重大度を説明します。

2

チェックの結果を説明します。以下の値を使用できます。

PASS: チェックは成功しました。
FAIL: チェックに失敗しました。
INFO: チェックは成功し、エラーと見なされるほど深刻ではないものが見つかりました。
MANUAL: チェックではステータスを自動的に評価できないため、手動チェックが必要です。
INCONSISTENT: ノードが異なれば、報告される結果も異なります。
ERROR: チェックは正常に実行されましたが、完了できませんでした。
NOTAPPLICABLE: 該当しないため、チェックは実行されませんでした。

スイートからすべてのチェック結果を取得するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l compliance.openshift.io/suite=workers-compliancesuite

5.4.2.6.2. ComplianceRemediation オブジェクト

特定のチェックには、データストリームで指定された修正を行うことができます。ただし、Kubernetes 修正が利用可能な場合、コンプライアンスオペレーターは ComplianceRemediation オブジェクトを作成します。

ComplianceRemediation オブジェクトの例

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  labels:
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
    machineconfiguration.openshift.io/role: worker
  name: workers-scan-disable-users-coredumps
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: workers-scan-disable-users-coredumps
    uid: <UID>
spec:
  apply: false 1
  object:
    current: 2
       apiVersion: machineconfiguration.openshift.io/v1
       kind: MachineConfig
       spec:
         config:
           ignition:
             version: 2.2.0
           storage:
             files:
             - contents:
                 source: data:,%2A%20%20%20%20%20hard%20%20%20core%20%20%20%200
               filesystem: root
               mode: 420
               path: /etc/security/limits.d/75-disable_users_coredumps.conf
    outdated: {} 3

1: true は、修復が適用されたことを示します。false は、修復が適用されなかったことを示します。
2: 修復の定義が含まれています。
3: 以前のバージョンのコンテンツから以前に解析された修復を示します。コンプライアンスオペレーターは、古いオブジェクトを引き続き保持して、管理者が新しい修復を適用する前に確認できるようにします。

スイートからすべての修復を取得するには、次のコマンドを実行します。

oc get complianceremediations \
-l compliance.openshift.io/suite=workers-compliancesuite

自動的に修正できるすべての失敗したチェックをリスト表示するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),compliance.openshift.io/automated-remediation'

手動で修正できるすべての失敗したチェックをリスト表示するには、次のコマンドを実行します。

oc get compliancecheckresults \
-l 'compliance.openshift.io/check-status in (FAIL),!compliance.openshift.io/automated-remediation'