5.5. Compliance Operator のスキャン


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

$ oc explain scansettings

または

$ oc explain scansettingbindings

5.5.1. コンプライアンススキャンの実行

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

注記

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

手順

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

    $ oc describe scansettings default -n openshift-compliance

    出力例

    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>

    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>
    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
  3. 以下を実行して ScanSettingBinding オブジェクトを作成します。

    $ oc create -f <file-name>.yaml -n openshift-compliance

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

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

    $ oc get compliancescan -w -n openshift-compliance

    スキャンはスキャンフェーズに進み、完了すると最終的に 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 * * *
      1
      Compliance Operator は、このノードを使用してスキャン結果を ARF 形式で保存します。
      2
      結果のサーバー Pod は、すべてのテイントを許容します。
    2. ScanSetting CR を作成するには、次のコマンドを実行します。

      $ oc create -f rs-workers.yaml

検証

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

    $ oc get scansettings rs-on-workers -n openshift-compliance -o yaml

    出力例

    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

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>

個々のコンテナーに対してのみ要求と制限を指定できますが、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"

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

© 2024 Red Hat, Inc.