Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

5.5. Compliance Operator のスキャン

ScanSetting および ScanSettingBinding API は、Compliance Operator でコンプライアンススキャンを実行するために使用することが推奨されます。これらの API オブジェクトの詳細については、以下を実行します。 

$ oc explain scansettings
Copy to Clipboard Toggle word wrap

または 

$ oc explain scansettingbindings
Copy to Clipboard Toggle word wrap

5.5.1. コンプライアンススキャンの実行
リンクのコピー

Center for Internet Security (CIS) プロファイルを使用してスキャンを実行できます。便宜上、Compliance Operator は起動時に適切なデフォルト値を持つ ScanSetting オブジェクトを作成します。この ScanSetting オブジェクトの名前は default です。

注記

オールインワンのコントロールプレーンノードとワーカーノードの場合、コンプライアンススキャンはワーカーノードとコントロールプレーンノードで 2 回実行されます。コンプライアンススキャンは、一貫性のないスキャン結果を生成する可能性があります。ScanSetting オブジェクトで単一のロールのみを定義することにより、一貫性のない結果を回避できます。

手順

  1. 以下を実行して ScanSetting オブジェクトを検査します。 

    $ oc describe scansettings default -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    出力例

    Name:         default
Namespace:    openshift-compliance
Labels:       <none>
Annotations:  <none>
API Version:  compliance.openshift.io/v1alpha1
Kind:         ScanSetting
Metadata:
  Creation Timestamp:  2022-10-10T14:07:29Z
  Generation:          1
  Managed Fields:
    API Version:  compliance.openshift.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:rawResultStorage:
        .:
        f:nodeSelector:
          .:
          f:node-role.kubernetes.io/master:
        f:pvAccessModes:
        f:rotation:
        f:size:
        f:tolerations:
      f:roles:
      f:scanTolerations:
      f:schedule:
      f:showNotApplicable:
      f:strictNodeScan:
    Manager:         compliance-operator
    Operation:       Update
    Time:            2022-10-10T14:07:29Z
  Resource Version:  56111
  UID:               c21d1d14-3472-47d7-a450-b924287aec90
Raw Result Storage:
  Node Selector:
    node-role.kubernetes.io/master:
  Pv Access Modes:
    ReadWriteOnce
    1 
    
  Rotation:  3
    2 
    
  Size:      1Gi
    3 
    
  Tolerations:
    Effect:              NoSchedule
    Key:                 node-role.kubernetes.io/master
    Operator:            Exists
    Effect:              NoExecute
    Key:                 node.kubernetes.io/not-ready
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoExecute
    Key:                 node.kubernetes.io/unreachable
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoSchedule
    Key:                 node.kubernetes.io/memory-pressure
    Operator:            Exists
Roles:
  master
    4 
    
  worker
    5 
    
Scan Tolerations:
    6 
    
  Operator:           Exists
Schedule:             0 1 * * *
    7 
    
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>
    Copy to Clipboard Toggle word wrap

    1
    Compliance Operator は、スキャンの結果が含まれる永続ボリューム (PV) を作成します。デフォルトで、Compliance Operator はクラスターに設定されるストレージクラスについて何らかの仮定をすることができないため、PV はアクセスモード ReadWriteOnce を使用します。さらに、ReadWriteOnce アクセスモードはほとんどのクラスターで利用できます。スキャン結果を取得する必要がある場合は、ボリュームもバインドするヘルパー Pod を使用して実行できます。ReadWriteOnce アクセスモードを使用するボリュームは、一度に 1 つの Pod のみがマウントできるため、必ずヘルパー Pod を削除してください。そうでない場合は、Compliance Operator は後続のスキャンのためにボリュームを再利用できません。
    2
    Compliance Operator は、後続の 3 つのスキャンの結果をボリュームに保持し、古いスキャンはローテーションされます。
    3
    Compliance Operator はスキャンの結果用に 1 GB のストレージを割り当てます。
    4 5
    スキャン設定がクラスターノードをスキャンするプロファイルを使用する場合は、これらのノードロールをスキャンします。
    6
    デフォルトのスキャン設定オブジェクトは、すべてのノードをスキャンします。
    7
    デフォルトのスキャン設定オブジェクトは、毎日 01:00 にスキャンを実行します。

    デフォルトのスキャン設定の代わりに、以下の設定を含む default-auto-apply を使用できます。 

    Name:                      default-auto-apply
Namespace:                 openshift-compliance
Labels:                    <none>
Annotations:               <none>
API Version:               compliance.openshift.io/v1alpha1
Auto Apply Remediations:   true
    1 
    
Auto Update Remediations:  true
    2 
    
Kind:                      ScanSetting
Metadata:
  Creation Timestamp:  2022-10-18T20:21:00Z
  Generation:          1
  Managed Fields:
    API Version:  compliance.openshift.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:autoApplyRemediations:
      f:autoUpdateRemediations:
      f:rawResultStorage:
        .:
        f:nodeSelector:
          .:
          f:node-role.kubernetes.io/master:
        f:pvAccessModes:
        f:rotation:
        f:size:
        f:tolerations:
      f:roles:
      f:scanTolerations:
      f:schedule:
      f:showNotApplicable:
      f:strictNodeScan:
    Manager:         compliance-operator
    Operation:       Update
    Time:            2022-10-18T20:21:00Z
  Resource Version:  38840
  UID:               8cb0967d-05e0-4d7a-ac1c-08a7f7e89e84
Raw Result Storage:
  Node Selector:
    node-role.kubernetes.io/master:
  Pv Access Modes:
    ReadWriteOnce
  Rotation:  3
  Size:      1Gi
  Tolerations:
    Effect:              NoSchedule
    Key:                 node-role.kubernetes.io/master
    Operator:            Exists
    Effect:              NoExecute
    Key:                 node.kubernetes.io/not-ready
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoExecute
    Key:                 node.kubernetes.io/unreachable
    Operator:            Exists
    Toleration Seconds:  300
    Effect:              NoSchedule
    Key:                 node.kubernetes.io/memory-pressure
    Operator:            Exists
Roles:
  master
  worker
Scan Tolerations:
  Operator:           Exists
Schedule:             0 1 * * *
Show Not Applicable:  false
Strict Node Scan:     true
Events:               <none>
    Copy to Clipboard Toggle word wrap
    1 2
    autoUpdateRemediations および autoApplyRemediations フラグを true に設定すると、追加の手順なしに自動修復する ScanSetting オブジェクトを簡単に作成できます。

  2. デフォルトの ScanSetting オブジェクトにバインドし、cis および cis-node プロファイルを使用してクラスターをスキャンする ScanSettingBinding オブジェクトを作成します。以下に例を示します。 

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: cis-compliance
  namespace: openshift-compliance
profiles:
  - name: ocp4-cis-node
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
  - name: ocp4-cis
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: default
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1
    Copy to Clipboard Toggle word wrap

  3. 以下を実行して ScanSettingBinding オブジェクトを作成します。 

    $ oc create -f <file-name>.yaml -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    プロセスのこの時点で、ScanSettingBinding オブジェクトは調整され、Binding および Bound 設定に基づいて調整されます。Compliance Operator は ComplianceSuite オブジェクトおよび関連付けられる ComplianceScan オブジェクトを作成します。

  4. 以下を実行してコンプライアンススキャンの進捗を確認します。 

    $ oc get compliancescan -w -n openshift-compliance
    Copy to Clipboard Toggle word wrap

    スキャンはスキャンフェーズに進み、完了すると最終的に DONE フェーズに移行します。ほとんどの場合、スキャンの結果は NON-COMPLIANT になります。スキャン結果を確認し、クラスターがコンプライアンスに基づくように修復の適用を開始することができます。詳細は、Compliance Operator 修復の管理 を参照してください。

5.5.2. ワーカーノードでの結果サーバー Pod のスケジューリング
リンクのコピー

結果サーバー Pod は、生の Asset Reporting Format (ARF) スキャン結果を格納する永続ボリューム (PV) をマウントします。nodeSelector 属性および tolerations 属性を使用すると、結果サーバー Pod の場所を設定できます。

これは、コントロールプレーンノードが永続ボリュームをマウントすることを許可されていない環境で役立ちます。

手順

  • Compliance Operator 用の ScanSetting カスタムリソース (CR) を作成します。

    1. ScanSetting CR を定義し、YAML ファイルを保存します (例: rs-workers.yaml)。 

      apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: rs-on-workers
  namespace: openshift-compliance
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
      1 
      
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3
  size: 1Gi
  tolerations:
  - operator: Exists
      2 
      
roles:
- worker
- master
scanTolerations:
  - operator: Exists
schedule: 0 1 * * *
      Copy to Clipboard Toggle word wrap
      1
      Compliance Operator は、このノードを使用してスキャン結果を ARF 形式で保存します。
      2
      結果のサーバー Pod は、すべてのテイントを許容します。

    2. ScanSetting CR を作成するには、次のコマンドを実行します。 

      $ oc create -f rs-workers.yaml
      Copy to Clipboard Toggle word wrap

検証

  • ScanSetting オブジェクトが作成されたことを確認するには、次のコマンドを実行します。 

    $ oc get scansettings rs-on-workers -n openshift-compliance -o yaml
    Copy to Clipboard Toggle word wrap

    出力例

    apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  creationTimestamp: "2021-11-19T19:36:36Z"
  generation: 1
  name: rs-on-workers
  namespace: openshift-compliance
  resourceVersion: "48305"
  uid: 43fdfc5f-15a7-445a-8bbc-0e4a160cd46e
rawResultStorage:
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  pvAccessModes:
  - ReadWriteOnce
  rotation: 3
  size: 1Gi
  tolerations:
  - operator: Exists
roles:
- worker
- master
scanTolerations:
- operator: Exists
schedule: 0 1 * * *
strictNodeScan: true
    Copy to Clipboard Toggle word wrap

5.5.3. ScanSetting カスタムリソース
リンクのコピー

ScanSetting カスタムリソースでは、scan limits 属性を使用して、スキャナー Pod のデフォルトの CPU およびメモリー制限をオーバーライドできるようになりました。Compliance Operator は、スキャナーコンテナーに 500Mi メモリー、100m CPU のデフォルトを使用し、api-resource-collector コンテナーに 100m CPU の 200Mi メモリーを使用します。Operator のメモリー制限を設定するには、OLM または Operator デプロイメント自体を介してインストールされている場合は Subscription オブジェクトを変更します。

Compliance Operator のデフォルトの CPU およびメモリーの制限を増やすには、Compliance Operator リソース制限の増加 を参照してください。

重要

デフォルトの制限が十分ではなく、Operator またはスキャナー Pod が Out Of Memory (OOM) プロセスによって終了した場合は、Compliance Operator または Scanner Pod のメモリー制限を増やす必要があります。

5.5.4. リソース要求および制限の適用
リンクのコピー

kubelet が Pod の一部としてコンテナーを起動すると、kubelet はそのコンテナーの要求および制限をメモリーおよび CPU の要求および制限をコンテナーランタイムに渡します。Linux では、コンテナーランタイムは、定義した制限を適用して有効にするカーネル cgroup を設定します。

CPU 制限は、コンテナーが使用できる CPU 時間を定義します。各スケジューリング期間中、Linux カーネルはこの制限を超えるかどうかを確認します。その場合、カーネルは、cgroup の実行を再開できるようにするまで待機します。

複数の異なるコンテナー (cgroup) を競合するシステムで実行する場合、CPU 要求が大きいワークロードには、要求が小さいワークロードよりも多くの CPU 時間が割り当てられます。メモリー要求は Pod のスケジューリング時に使用されます。cgroups v2 を使用するノードでは、コンテナーランタイムがメモリーリクエストをヒントとして使用して、memory.min および memory.low の 値を設定する場合があります。

コンテナーがこの制限を超えるメモリーを割り当てようとすると、Linux カーネルのメモリー不足サブシステムがアクティブになり、メモリーを割り当てようとしたコンテナー内のプロセスの 1 つを停止して介入します。Pod またはコンテナーのメモリー制限は、emptyDir などのメモリーベースのボリュームのページにも適用できます。

kubelet は、ローカルの一時ストレージとしてではなく、コンテナーメモリーが使用されているときに tmpfs emptyDir ボリュームを追跡します。コンテナーがメモリー要求を超え、それが実行されているノードが全体的にメモリー不足になった場合、Pod のコンテナーが削除される可能性があります。

重要

コンテナーは、長期間にわたって CPU 制限を超えることはできません。コンテナーのランタイムは、CPU 使用率が過剰に使用されている場合も Pod またはコンテナーを停止しません。リソース制限のためにコンテナーをスケジュールできないか、強制終了されているかを判断するには、Compliance Operator のトラブルシューティング を参照してください。

5.5.5. コンテナーリソース要求を使用した Pod のスケジューリング
リンクのコピー

Pod が作成されると、スケジューラーは Pod を実行するノードを選択します。各ノードには、リソースタイプごとに、Pod に提供できる CPU とメモリーの最大容量があります。スケジューラーは、スケジュールされたコンテナーのリソース要求の合計が、各リソースタイプの容量ノードよりも少なくなるようにします。

ノードのメモリーまたは CPU リソースの使用率が非常に低い場合でも、容量チェックでノードのリソース不足を防ぐことができない場合、スケジューラーはノードへの Pod の配置を拒否することがあります。

コンテナーごとに、以下のリソース制限および要求を指定できます。 

spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>
Copy to Clipboard Toggle word wrap

個々のコンテナーに対してのみ要求と制限を指定できますが、Pod の全体的なリソース要求と制限を考慮することも役立ちます。特定のリソースの場合には、コンテナーリソースの要求または制限は、Pod 内にあるコンテナーごとに割り当てられた、対象タイプのリソース要求または制限を合計したものです。

コンテナーリソース要求および制限の例

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
1 

        memory: "64Mi"
        cpu: "250m"
      limits:
2 

        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
Copy to Clipboard Toggle word wrap

1
コンテナーは 64 Mi のメモリーと 250 m CPU を要求しています。
2
コンテナーの制限は 128 Mi のメモリーと 500 m CPU です。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat