IBM Cloud Docs
CIS Kubernetes ベンチマーク

CIS Kubernetes ベンチマーク

Center for Internet Security ( CIS ) は、 CIS Kubernetes Benchmarkを、 Kubernetes をより安全に、さまざまな業界規制に見合った基準で設定するための具体的な手順の枠組みとして公表している。

新しい Kubernetes バージョンがリリースされると、IBM のエンジニアは、その Kubernetes バージョンを実行するクラスターのデフォルト構成をこのベンチマークと照合して、その照合結果をこの資料で公開します。 お客様は、ご使用の IBM Cloud® Kubernetes Service クラスターの特定バージョンが CIS Kubernetes ベンチマークをどの程度満たしているのかを確認できます。

対応ベンチマークバージョン

サポートされているバージョンの CIS Kubernetes ベンチマークの結果を見つけるには、リストを使用してください。

ベンチマークの使用

セキュリティーの管理者または監査員は、社内の標準および外部の規制要件を CIS Kubernetes ベンチマークと比較することをお勧めします。 ベンチマークの推奨事項は、IBM ではなく Center for Internet Security によって提示されます。 IBM は、すべての推奨事項が満たされるようにデフォルト設定を構成しない場合がありますが、推奨事項が満たされているかどうかを文書化することで、お客様が確認しやすくします。 例えば、お客様はベンチマークを監査で使用して、基本的なセキュリティー対策が実施されていることを確認したり、セキュリティーを強化できる領域を特定したりできます。

ベンチマークの対象は?

このベンチマークの対象となるのは、マスター・コンポーネント、etcd、コントロール・プレーン構成、ワーカー・ノード、およびポリシー (ユーザー、ネットワーク、ポッド・セキュリティーなど) に関する推奨事項です。

ベンチマークの推奨は何を意味するのか?

当ベンチマークの推奨事項には、次のようなスコアリング、レベル、結果状況、および責任が付随します。

  • Scoring
    • スコア対象: 全体的なベンチマーク・スコアは、推奨が満たされているかどうかに応じて増減します。
    • スコア対象外: 推奨が満たされているかどうかに関係なく、全体的なベンチマーク・スコアは影響を受けません。
  • レベル
    • レベル 1: サービスを妨げることなく構成できる実践的なセキュリティー対策です。
    • レベル 2: サービスのパフォーマンスや機能を低下させる可能性のある詳細なセキュリティー対策です。
  • 結果
    • 合格: サービスは、当該ベンチマーク推奨事項に準拠しています。
    • 不合格: サービスは、デフォルトでは当該ベンチマーク推奨事項に準拠していません。 当該ベンチマーク推奨事項に従うために実行できる処置および説明については、修正処置のセクションを参照してください。
  • 責任
    • IBM: IBM は、当ベンチマークで推奨される設定を構成する責任を負います。
    • 共有: お客様と IBM は、当ベンチマークで推奨される設定を構成する責任を共有します。

ベンチマークのどの部分に責任を持つべきか?

IBM Cloud Kubernetes Service はマネージド型のオファリングであるため、多くのセキュリティー設定が IBM 側であらかじめ構成されています。 例えば、IBM は、クラスター・マスターの更新データを管理して自動的に適用します。 ワーカー・ノードについては、IBM はセキュリティーとバージョンの更新データを提供しますが、お客様がこれらの更新データを適用する必要があります。 お客様は、ワークロードのアプリケーションとデータについても責任を負います。 詳しくは、 IBM Cloud Kubernetes Service を使用する際の責任を参照してください。

サービスの一部が勧告に従わなかった場合は?

まず、非準拠状態の説明を参照して、何らかの修正手順がないか確認してください。

次に、自社のセキュリティー要件に従って、その非準拠状態が許容可能かどうかを判断します。 例えば、一部の推奨事項は、自社の特定のプロセスや標準で要求されるよりも詳細な構成要件である場合があります。 また、一部の推奨はスコア対象外であり、全体的なベンチマーク・スコアには影響しません。

次に、該当コンポーネントがお客様の責任範囲内にあるかどうかを判断します。 そうである場合は、必要に応じてそのコンポーネントの構成方法を変更します。 例えば、すべてのアプリ・デプロイメントに対してポッド・セキュリティー・ポリシーを構成することが考えられます。 お客様が直接的に責任を負わないコンポーネントの場合は、別の IBM Cloud サービスを使用してその推奨事項を満たすことができるかどうかを判断します。

クラスタのセキュリティとコンプライアンスを高めるために、他に何ができますか?

IBM Cloud Kubernetes Service のセキュリティーを参照してください。

ワーカー・ノードの CIS Kubernetes ベンチマークの実行

セクション 4: ワーカー・ノード・セキュリティー構成の CIS Kubernetes ベンチマークの結果を確認するには、自分でテストを実行します。 ワーカー・ノードを所有しており、そのコンプライアンスに関する部分的な責任があるので、構成を変更して独自に検証を行う場合もあるでしょう。

始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

  1. ベンチマークを実行するリソースのための名前空間を作成します。

    kubectl create ns ibm-kube-bench-test
    
  2. kube-samples GitHub リポジトリから config および node 設定ファイルを使用して ConfigMap を作成します。

    1. confignode の設定ファイルを、 ibm というローカル・ディレクトリにダウンロードする。 リポジトリーを複製し、ibm ディレクトリーにナビゲートすることもできます。
    2. --from-file オプションを使用して、設定ファイルをダウンロードした ibm ディレクトリを指定して、 ConfigMap を作成します。
      kubectl create cm kube-bench-node -n ibm-kube-bench-test --from-file ibm
      
  3. 以前に作成した構成に基づいてベンチマーク・テストを実行するジョブを作成します。

    kubectl apply -n ibm-kube-bench-test -f https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/cis-kube-benchmark/cis-1.5/ibm/job-node.yaml
    
  4. 仕事が完了したことを確認する。

    kubectl get pods -n ibm-kube-bench-test -l job-name=kube-bench-node
    

    出力例

    NAME                    READY   STATUS      RESTARTS   AGE
    kube-bench-node-hlvhc   0/1     Completed   0          23s
    
  5. ポッドのログを確認して、ワーカー・ノードを対象にした CIS Kubernetes ベンチマークの結果を検討します。

    kubectl logs -n ibm-kube-bench-test -l job-name=kube-bench-node --tail=-1
    

    出力例

    == Summary ==
    20 checks PASS
    2 checks FAIL
    1 checks WARN
    0 checks INFO
    
  6. オプション: 結果を検討し終えたら、作成したリソースを削除します。

    kubectl delete ns ibm-kube-bench-test