5.14. oc-compliance プラグインの使用
コンプライアンス Operator はクラスターのチェックおよび修復の多くを自動化しますが、クラスターを準拠させる完全なプロセスでは、管理者がコンプライアンス Operator API や他のコンポーネントと対話する必要があります。oc-compliance
プラグインはプロセスを容易にします。
5.14.1. oc-compliance プラグインのインストール
手順
oc-compliance
イメージを展開して、oc-compliance
バイナリーを取得します。$ 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/
出力例
W0611 20:35:46.486903 11354 manifest.go:440] Chose linux/amd64 manifest from the manifest list.
oc-compliance
を実行できるようになりました。
5.14.2. 未加工の結果の取得
コンプライアンススキャンが完了すると、個別のチェックの結果は生成される ComplianceCheckResult
カスタムリソース (CR) に一覧表示されます。ただし、管理者または監査担当者にはスキャンの詳細情報が必要になる場合があります。OpenSCAP ツールは、詳細な結果で Advanced Recording Format (ARF) 形式のファイルを作成します。この ARF ファイルは設定マップまたは他の標準の Kubernetes リソースに保存するには大き過ぎるため、永続ボリューム (PV) がこれを組み込むように作成されます。
手順
コンプライアンス Operator を使用した PV からの結果の取得は 4 つの手順で実行されます。ただし、
oc-compliance
プラグインでは、単一のコマンドを使用できます。$ oc compliance fetch-raw <object-type> <object-name> -o <output-path>
-
<object-type>
は、スキャンの機能に使用されたオブジェクトによって、scansettingbinding
、compliancescan
またはcompliancesuite
のいずれかにすることができます。 <object-name>
は、ARF ファイルを収集に使用するバインディング、スイート、またはスキャンオブジェクトの名前です。<output-path>
は、結果を配置するローカルディレクトリーです。以下に例を示します。
$ oc compliance fetch-raw scansettingbindings my-binding -o /tmp/
出力例
Fetching results for my-binding scans: ocp4-cis, ocp4-cis-node-worker, ocp4-cis-node-master Fetching raw compliance results for scan 'ocp4-cis'....... The raw compliance results are available in the following directory: /tmp/ocp4-cis Fetching raw compliance results for scan 'ocp4-cis-node-worker'........... The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-worker Fetching raw compliance results for scan 'ocp4-cis-node-master'...... The raw compliance results are available in the following directory: /tmp/ocp4-cis-node-master
ディレクトリー内のファイルの一覧を表示します。
$ ls /tmp/ocp4-cis-node-master/
出力例
ocp4-cis-node-master-ip-10-0-128-89.ec2.internal-pod.xml.bzip2 ocp4-cis-node-master-ip-10-0-150-5.ec2.internal-pod.xml.bzip2 ocp4-cis-node-master-ip-10-0-163-32.ec2.internal-pod.xml.bzip2
結果を抽出します。
$ bunzip2 -c resultsdir/worker-scan/worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 > resultsdir/worker-scan/worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml
結果を表示します。
$ ls resultsdir/worker-scan/
出力例
worker-scan-ip-10-0-170-231.us-east-2.compute.internal-pod.xml worker-scan-stage-459-tqkg7-compute-0-pod.xml.bzip2 worker-scan-stage-459-tqkg7-compute-1-pod.xml.bzip2
5.14.3. スキャンの再実行
スキャンをスケジュールされたジョブとして実行することは可能ですが、多くの場合、修復の適用後、またはクラスターへの他の変更が加えられるなどの場合にとくにスキャンをオンデマンドで再実行する必要があります。
手順
コンプライアンス Operator でスキャンを再実行するには、スキャンオブジェクトでアノテーションを使用する必要があります。ただし、
oc-compliance
プラグインを使用すると、1 つのコマンドでスキャンを再実行できます。以下のコマンドを入力して、my-binding
という名前のScanSettingBinding
オブジェクトのスキャンを再実行します。$ oc compliance rerun-now scansettingbindings my-binding
出力例
Rerunning scans from 'my-binding': ocp4-cis Re-running scan 'openshift-compliance/ocp4-cis'
5.14.4. ScanSettingBinding カスタムリソースの使用
コンプライアンス Operator が提供する ScanSetting
および ScanSettingBinding
カスタムリソース (CR) を使用する場合、schedule
、machine roles
、tolerations
などのスキャンオプションのセットを使用している間に、複数のプロファイルに対してスキャンを実行できます。複数の ComplianceSuite
オブジェクトまたは ComplianceScan
オブジェクトを使用することがより容易になりますが、新規ユーザーが混乱を生じさせる可能性があります。
oc compliance bind
サブコマンドは、ScanSettingBinding
CR の作成に役立ちます。
手順
以下を実行します。
$ oc compliance bind [--dry-run] -N <binding name> [-S <scansetting name>] <objtype/objname> [..<objtype/objname>]
-
-S
フラグを省略する場合、コンプライアンス Operator によって提供されるdefault
のスキャン設定が使用されます。 -
オブジェクトタイプは、Kubernetes オブジェクトタイプです。
profile
またはtailoredprofile
にすることができます。複数のオブジェクトを指定できます。 -
オブジェクト名は、
.metadata.name
などの Kubernetes リソースの名前です。 --dry-run
オプションを追加して、作成されるオブジェクトの YAML ファイルを表示します。たとえば、以下のプロファイルとスキャン設定を指定します。
$ oc get profile.compliance -n openshift-compliance
出力例
NAME AGE ocp4-cis 9m54s ocp4-cis-node 9m54s ocp4-e8 9m54s ocp4-moderate 9m54s ocp4-ncp 9m54s rhcos4-e8 9m54s rhcos4-moderate 9m54s rhcos4-ncp 9m54s rhcos4-ospp 9m54s rhcos4-stig 9m54s
$ oc get scansettings -n openshift-compliance
出力例
NAME AGE default 10m default-auto-apply 10m
-
default
設定をocp4-cis
およびocp4-cis-node
プロファイルに適用するには、以下を実行します。$ oc compliance bind -N my-binding profile/ocp4-cis profile/ocp4-cis-node
出力例
Creating ScanSettingBinding my-binding
ScanSettingBinding
CR が作成されると、バインドされたプロファイルは、関連する設定で両方のプロファイルのスキャンを開始します。全体的に、これはコンプライアンス Operator でスキャンを開始するための最も高速な方法です。
5.14.5. コントロールの表示
コンプライアンス標準は通常、以下のように階層に編成されます。
- ベンチマークは、特定の標準についての一連のコントロールの最上位の定義です。例: FedRAMP Moderate または Center for Internet Security (CIS) v.1.6.0。
- コントロールは、ベンチマークへの準拠を確保するために満たさなければならない要件のファミリーを説明します。例: FedRAMP AC-01(アクセス制御ポリシーおよび手順)。
- ルールは、コンプライアンスを取るシステムに固有の単一のチェックでありで、これらの 1 つ以上のルールがコントロールにマップされます。
- コンプライアンス Operator は、単一のベンチマークについてのプロファイルへのルールのグループ化に対応します。プロファイルの一連のルールの条件を満たすコントロールを判別することが容易ではない場合があります。
手順
oc compliance
controls
サブコマンドは、指定されたプロファイルが満たす標準およびコントロールのレポートを提供します。$ oc compliance controls profile ocp4-cis-node
出力例
+-----------+----------+ | FRAMEWORK | CONTROLS | +-----------+----------+ | CIS-OCP | 1.1.1 | + +----------+ | | 1.1.10 | + +----------+ | | 1.1.11 | + +----------+ ...
5.14.6. コンプライアンス修復の詳細情報の取得
コンプライアンス Operator は、クラスターが準拠できるようにする必要な変更を自動化するために使用される修復オブジェクトを提供します。fetch-fixes
サブコマンドは、使用する設定の修復を正確に理解するのに役立ちます。fetch-fixes
サブコマンドを使用して、検査するディレクトリーにプロファイル、ルール、または ComplianceRemediation
オブジェクトから修復オブジェクトを展開します。
手順
プロファイルの修復を表示します。
$ oc compliance fetch-fixes profile ocp4-cis -o /tmp
出力例
No fixes to persist for rule 'ocp4-api-server-api-priority-flowschema-catch-all' 1 No fixes to persist for rule 'ocp4-api-server-api-priority-gate-enabled' No fixes to persist for rule 'ocp4-api-server-audit-log-maxbackup' Persisted rule fix to /tmp/ocp4-api-server-audit-log-maxsize.yaml No fixes to persist for rule 'ocp4-api-server-audit-log-path' No fixes to persist for rule 'ocp4-api-server-auth-mode-no-aa' No fixes to persist for rule 'ocp4-api-server-auth-mode-node' No fixes to persist for rule 'ocp4-api-server-auth-mode-rbac' No fixes to persist for rule 'ocp4-api-server-basic-auth' No fixes to persist for rule 'ocp4-api-server-bind-address' No fixes to persist for rule 'ocp4-api-server-client-ca' Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-cipher.yaml Persisted rule fix to /tmp/ocp4-api-server-encryption-provider-config.yaml
- 1
- ルールが自動的に修復されないか、または修復が行われないために対応する修復のないルールがプロファイルにある場合は常に、
No fixes to persist
の警告が出されることが予想されます。
YAML ファイルのサンプルを表示できます。
head
コマンドは、最初の 10 行を表示します。$ head /tmp/ocp4-api-server-audit-log-maxsize.yaml
出力例
apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: maximumFileSizeMegabytes: 100
スキャン後に作成される
ComplianceRemediation
オブジェクトから修復を表示します。$ oc get complianceremediations -n openshift-compliance
出力例
NAME STATE ocp4-cis-api-server-encryption-provider-cipher NotApplied ocp4-cis-api-server-encryption-provider-config NotApplied
$ oc compliance fetch-fixes complianceremediations ocp4-cis-api-server-encryption-provider-cipher -o /tmp
出力例
Persisted compliance remediation fix to /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml
YAML ファイルのサンプルを表示できます。
head
コマンドは、最初の 10 行を表示します。$ head /tmp/ocp4-cis-api-server-encryption-provider-cipher.yaml
出力例
apiVersion: config.openshift.io/v1 kind: APIServer metadata: name: cluster spec: encryption: type: aescbc
修復を直接適用するには注意が必要です。一部の修復は、適度なプロファイルの usbguard ルールなどのように一括して適用できない場合があります。このような場合、コンプライアンス Operator は依存関係に対応し、クラスターは正常な状態のままになるため、ルールを適用できます。
5.14.7. ComplianceCheckResult オブジェクトの詳細の表示
スキャンの実行が終了すると、ComplianceCheckResult
オブジェクトが個別のスキャンルールについて作成されます。view-result
サブコマンドは、ComplianceCheckResult
オブジェクトの詳細の人間が判読できる出力を提供します。
手順
以下を実行します。
$ oc compliance view-result ocp4-cis-scheduler-no-bind-address