CIS Kubernetes ベンチマーク
インターネットセキュリティセンター( CIS )は、「 CIS 」 Kubernetes ベンチマークを公開しています。これは、 Kubernetes をより安全に構成するための具体的な手順の枠組みであり、さまざまな業界規制に見合った基準に基づいています。
新しい Kubernetes バージョンが、サポート対象の Red Hat OpenShift バージョンの一部としてリリースされると、IBM のエンジニアは、その Kubernetes バージョンを実行するデフォルト構成のクラスターをベンチマークと比較し、その結果をこの資料で公開します。 お客様は、ご使用の Red Hat® OpenShift® on IBM Cloud® クラスターの特定バージョンが CIS Kubernetes ベンチマークをどの程度満たしているのかを確認できます。
対応ベンチマークバージョン
このリストを参照して、 CIS Kubernetes のサポート対象バージョンに関するベンチマーク結果を確認してください。
ベンチマークの使用
セキュリティーの管理者または監査員は、社内の標準および外部の規制要件を CIS Kubernetes ベンチマークと比較することをお勧めします。 ベンチマークの推奨事項は、IBM ではなく Center for Internet Security によって提示されます。 IBM は、すべての推奨事項が満たされるようにデフォルト設定を構成しない場合がありますが、推奨事項が満たされているかどうかを文書化することで、お客様が確認しやすくします。 例えば、お客様はベンチマークを監査で使用して、基本的なセキュリティー対策が実施されていることを確認したり、セキュリティーを強化できる領域を特定したりできます。
このベンチマークではどのような項目が対象となっていますか?
このベンチマークの対象となるのは、マスター・コンポーネント、etcd、コントロール・プレーン構成、ワーカー・ノード、およびポリシー (ユーザー、ネットワーク、ポッド・セキュリティーなど) に関する推奨事項です。
ベンチマークの推奨事項とはどういう意味ですか?
当ベンチマークの推奨事項には、次のようなスコアリング、レベル、結果状況、および責任が付随します。
- Scoring
- スコア対象: 全体的なベンチマーク・スコアは、推奨が満たされているかどうかに応じて増減します。
- スコア対象外: 推奨が満たされているかどうかに関係なく、全体的なベンチマーク・スコアは影響を受けません。
- レベル
- レベル 1: サービスを妨げることなく構成できる実践的なセキュリティー対策です。
- レベル 2: サービスのパフォーマンスや機能を低下させる可能性のある詳細なセキュリティー対策です。
- 結果
- 合格: サービスは、当該ベンチマーク推奨事項に準拠しています。
- 不合格: サービスは、デフォルトでは当該ベンチマーク推奨事項に準拠していません。 当該ベンチマーク推奨事項に従うために実行できる処置および説明については、修正処置のセクションを参照してください。
- 責任
- IBM: IBM は、当ベンチマークで推奨される設定を構成する責任を負います。
- 共有: お客様と IBM は、当ベンチマークで推奨される設定を構成する責任を共有します。
ベンチマークのどの部分を担当すればよいのでしょうか?
Red Hat OpenShift on IBM Cloud はマネージド型のオファリングであるため、多くのセキュリティー設定が IBM 側であらかじめ構成されています。 例えば、IBM は、クラスター・マスターの更新データを管理して自動的に適用します。 ワーカー・ノードについては、IBM はセキュリティーとバージョンの更新データを提供しますが、お客様がこれらの更新データを適用する必要があります。 お客様は、ワークロードのアプリケーションとデータについても責任を負います。 詳しくは、Red Hat OpenShift on IBM Cloud を使用するうえでの責任を参照してください。
もし、サービスの一部が推奨事項に準拠していなかった場合はどうなるのでしょうか?
まず、非準拠状態の説明を参照して、何らかの修正手順がないか確認してください。
次に、自社のセキュリティー要件に従って、その非準拠状態が許容可能かどうかを判断します。 例えば、一部の推奨事項は、自社の特定のプロセスや標準で要求されるよりも詳細な構成要件である場合があります。 また、一部の推奨はスコア対象外であり、全体的なベンチマーク・スコアには影響しません。
次に、該当コンポーネントがお客様の責任範囲内にあるかどうかを判断します。 そうである場合は、必要に応じてそのコンポーネントの構成方法を変更します。 例えば、すべてのアプリ・デプロイメントに対してセキュリティー・コンテキスト制約を構成することが考えられます。 お客様が直接的に責任を負わないコンポーネントの場合は、別の IBM Cloud サービスを使用してその推奨事項を満たすことができるかどうかを判断します。
クラスターのセキュリティとコンプライアンスをさらに強化するには、他にどのような対策がありますか?
Red Hat OpenShift on IBM Cloud のセキュリティーを参照してください。
ワーカー・ノードの CIS Kubernetes ベンチマークの実行
セクション 4: ワーカー・ノード・セキュリティー構成の CIS Kubernetes ベンチマークの結果を確認するには、自分でテストを実行します。 ワーカー・ノードを所有しており、そのコンプライアンスに関する部分的な責任があるので、構成を変更して独自に検証を行う場合もあるでしょう。
この手順は、Red Hat OpenShift バージョン 4.5 以降を実行するクラスターにのみ適用されます。
始める前に: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。
-
ベンチマークを実行するリソースのためのプロジェクトを作成します。
oc create ns ibm-kube-bench-test -
kube-samples GitHub リポジトリにある
configおよびnode設定ファイルを使用して、 ConfigMap を作成します。- 「
config」および「node」の設定ファイルを、ibmという名前のローカルディレクトリにダウンロードしてください。 リポジトリーを複製し、ibmディレクトリーにナビゲートすることもできます。 - 「
--from-file」オプションを使用して、設定ファイルをダウンロードした「ibm」ディレクトリを指定し、「 ConfigMap 」を作成します。
oc create cm kube-bench-node -n ibm-kube-bench-test --from-file ibm ``` - 「
-
以前に作成した構成に基づいてベンチマーク・テストを実行するジョブを作成します。
oc 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 -
ジョブが完了したことを確認してください。
oc 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 -
ポッドのログを確認して、ワーカー・ノードを対象にした CIS Kubernetes ベンチマークの結果を検討します。
oc 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 -
オプション: 結果を検討し終えたら、作成したリソースを削除します。
oc delete ns ibm-kube-bench-test