CIS 1.23 セルフアセスメントガイド

CIS Kubernetes Benchmark v1.23 - RKE2

概要

この文書は、RKE2 セキュリティハードニングガイドの補足資料です。ハードニングガイドは、RKE2の本番インストールをハードニングするための指針を提供し、このベンチマークガイドは、CIS Kubernetes ベンチマークの各コントロールに対するハードニングされたクラスターのセキュリティレベルを評価するのに役立つことを目的としています。これは、RKE2オペレーター、セキュリティチーム、監査人、意思決定者によって使用されることを想定しています。

このガイドは、RKE2の*v1.25*リリースラインおよびCIS Kubernetes ベンチマークの*v1.23*リリースに特化しています。

各コントロールの詳細については、CIS Kubernetes ベンチマーク v1.23 の該当セクションを参照してください。 CISecurity.orgにログイン後、ベンチマークをダウンロードできます。

コントロールテストの方法論

CIS Kubernetes ベンチマークの各コントロールは、付随するハードニングガイドに従って構成されたRKE2クラスターに対して評価されました。

コントロール監査が元のCISベンチマークと異なる場合、RKE2に特有の監査コマンドがテスト用に提供されます。

各コントロールの可能な結果は次のとおりです：

合格 - テスト対象のRKE2クラスターは、ベンチマークに記載された監査に合格しました。
該当せず - コントロールは、RKE2の設計上の動作により該当しません。修正セクションでは、なぜそうなるのかを説明します。
手動 - オペレーター依存 - コントロールはCISベンチマークで手動であり、クラスターの使用ケースやクラスターオペレーターによって決定されるべき他の要因に依存します。これらのコントロールは、RKE2がその実装を妨げないことを確認するために評価されましたが、テスト対象のクラスターに対するさらなる構成や監査は行われていません。

コントロール

1 マスターノードのセキュリティ構成

1.1 マスターノードの設定ファイル

1.1.1

APIサーバーポッドの設定ファイルの権限が644以下に設定されていることを確認してください（自動化）。

理由

APIサーバーポッドの設定ファイルは、APIサーバーの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
644

是正措置: デフォルトでは、RKE2はこれらのファイルを`644`の権限で作成します。手動での修正は必要ありません。

1.1.2

APIサーバーポッドの仕様ファイルの所有権が`root:root`に設定されていることを確認してください（自動）。

理由

APIサーバーポッドの仕様ファイルは、APIサーバーの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有者を設定する必要があります。ファイルの所有者は`root:root`であるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-apiserver.yaml
root:root

是正措置: デフォルトでは、RKE2はこれらのファイルを`root:root`の所有者で作成します。手動での修正は必要ありません。

1.1.3

コントローラーマネージャーポッドの仕様ファイルの権限が`644`以下に設定されていることを確認してください（自動化）。

理由

コントローラーマネージャーポッドの仕様ファイルは、マスターノード上のコントローラーマネージャーの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
644

是正措置: デフォルトでは、RKE2はこれらのファイルを`644`の権限で作成します。手動での修正は必要ありません。

1.1.4

コントローラーマネージャーポッドの仕様ファイルの所有権が`root:root`に設定されていることを確認してください（自動）。

理由

コントローラーマネージャーポッドの仕様ファイルは、マスターノードのさまざまなコンポーネントの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有者を設定する必要があります。ファイルの所有者はroot:rootであるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-controller-manager.yaml
root:root

是正措置: デフォルトでは、RKE2はこれらのファイルを`root:root`の所有者で作成します。手動での修正は必要ありません。

1.1.5

スケジューラーポッドの仕様ファイルの権限が`644`以下に設定されていることを確認してください（自動化）。

理由

スケジューラーポッドの仕様ファイルは、マスターノードのスケジューラーサービスの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
644

是正措置: デフォルトでは、RKE2はこれらのファイルを`644`の権限で作成します。手動での修正は必要ありません。

1.1.6

スケジューラーポッドの仕様ファイルの所有権が`root:root`に設定されていることを確認してください（自動）。

理由

スケジューラーポッドの仕様ファイルは、マスターノードのkube-schedulerサービスの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有者を設定する必要があります。ファイルの所有者はroot:rootであるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/kube-scheduler.yaml
root:root

是正措置: デフォルトでは、RKE2はこれらのファイルを`root:root`の所有者で作成します。手動での修正は必要ありません。

1.1.7

etcdポッドの仕様ファイルの権限が`644`以下に設定されていることを確認してください（自動化）。

理由

etcdポッドの仕様ファイル/var/lib/rancher/rke2/agent/pod-manifests/etcd.yamlは、マスターノードのetcdサービスの動作を設定するさまざまなパラメータを制御します。etcdは、KubernetesがすべてのREST APIオブジェクトの永続ストレージに使用する高可用性のキー・バリュー・ストアです。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
644

是正措置: デフォルトでは、RKE2はこれらのファイルを`644`の権限で作成します。手動での修正は必要ありません。

1.1.8

etcdポッドの仕様ファイルの所有者が`root:root`に設定されていることを確認してください（自動化）。

理由

etcdポッドの仕様ファイル/var/lib/rancher/rke2/agent/pod-manifests/etcd.yamlは、マスターノードのetcdサービスの動作を設定するさまざまなパラメータを制御します。etcdは、KubernetesがすべてのREST APIオブジェクトの永続ストレージに使用する高可用性のキー・バリュー・ストアです。ファイルの整合性を維持するために、そのファイルの所有者を設定する必要があります。ファイルの所有者はroot:rootであるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/agent/pod-manifests/etcd.yaml
root:root

是正措置: デフォルトでは、RKE2はこれらのファイルを`root:root`の所有者で作成します。手動での修正は必要ありません。

1.1.9

コンテナネットワークインタフェースファイルの権限が644以下に設定されていることを確認してください（手動）。

理由

コンテナネットワークインタフェースは、オーバーレイネットワーク用のさまざまなネットワーキングオプションを提供します。ドキュメントを参照し、それぞれのファイルの権限を制限して、ファイルの整合性を維持する必要があります。これらのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
644

是正措置: RKE2は、Helmチャートを使用してデフォルトのCNIであるCanalをデプロイします。チャートは、`644`の権限を持つファイル内のカスタムリソースとして定義されています。手動での修正は必要ありません。

1.1.10

コンテナネットワークインタフェースファイルの所有権が`root:root`に設定されていることを確認してください（手動）。

理由

コンテナネットワークインタフェースは、オーバーレイネットワーク用のさまざまなネットワーキングオプションを提供します。ドキュメントを参照し、それぞれのファイルの権限を制限して、ファイルの整合性を維持する必要があります。これらのファイルはroot:rootが所有するべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/manifests/rke2-canal.yaml
root:root

是正措置: RKE2は、Helmチャートを使用してデフォルトのCNIであるCanalをデプロイします。チャートは、`root:root`の所有権を持つファイル内のカスタムリソースとして定義されています。手動での修正は必要ありません。

1.1.11

etcdディレクトリの権限が700以下に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによるすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。このディレクトリは、無許可の読み取りや書き込みから保護されるべきです。グループのいかなるメンバーや全世界によっても読み取りや書き込みが行われないようにするべきです。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/server/db/etcd
700

是正措置: RKE2はetcdディレクトリを管理し、その権限を700に設定します。手動での修正は必要ありません。

1.1.12

etcdディレクトリの所有権が`etcd:etcd`に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによるすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。このディレクトリは、無許可の読み取りや書き込みから保護されるべきです。それはetcd:etcdによって所有されるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/db/etcd
etcd:etcd

是正措置: RKE2を`profile`フラグを`cis-1.23`に設定して実行すると、ホストに`etcd`ユーザーとグループが存在しない場合、RKE2は起動を拒否します。それが存在する場合、RKE2は自動的にetcdディレクトリの所有権を`etcd:etcd`に設定し、そのユーザーとグループでetcd静的ポッドが起動されることを確認します。

1.1.13

`admin.conf`ファイルの権限が`644`またはそれ以上に制限されていることを確認してください（自動化）。

理由

admin.confは、クラスターの管理に関するさまざまな設定を定義する管理者のkubeconfigファイルです。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/admin.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/server/cred/admin.kubeconfig
644

是正措置: デフォルトでは、RKE2はこのファイルを`/var/lib/rancher/rke2/server/cred/admin.kubeconfig`に作成し、その権限を`644`に自動的に設定します。手動での修正は必要ありません。

1.1.14

admin.confファイルの所有権が`root:root`に設定されていることを確認してください（自動化）。

理由

admin.confファイルには、クラスターの管理者資格情報が含まれています。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。ファイルの所有者はroot:rootであるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/admin.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig
root:root

是正措置: デフォルトでは、RKE2はこのファイルを`stat -c %U:%G /var/lib/rancher/rke2/server/cred/admin.kubeconfig`に作成し、その所有権を自動的に`root:root`に設定します。

1.1.15

`scheduler.conf`ファイルの権限が`644`またはそれ以上に制限されていることを確認してください（自動化）。

理由

scheduler.confファイルは、スケジューラーのためのkubeconfigファイルです。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
644

是正措置: デフォルトでは、RKE2はこのファイルを`/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig`に作成し、その権限を`644`に自動的に設定します。手動での修正は必要ありません。

1.1.16

`scheduler.conf`ファイルの所有権が`root:root`に設定されていることを確認してください（自動化）。

理由

scheduler.confファイルは、スケジューラーのためのkubeconfigファイルです。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。そのファイルはroot:rootによって所有されるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
root:root

是正措置: デフォルトでは、RKE2はこのファイルを`/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig`に作成し、その所有権を自動的に`root:root`に設定します。

1.1.17

`controller.kubeconfig`ファイルの権限が`644`またはそれ以上に制限されていることを確認してください（自動化）。

理由

controller.kubeconfigファイルは、スケジューラーのためのkubeconfigファイルです。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/controller.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %a /var/lib/rancher/rke2/server/cred/controller.kubeconfig
644

是正措置: デフォルトでは、RKE2はこのファイルを`/var/lib/rancher/rke2/server/cred/controller.kubeconfig`に作成し、その権限を`644`に自動的に設定します。手動での修正は必要ありません。

1.1.18

`controller.kubeconfig`ファイルの所有権が`root:root`に設定されていることを確認してください（自動化）。

理由

controller.kubeconfigファイルは、スケジューラーのためのkubeconfigファイルです。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。そのファイルはroot:rootによって所有されるべきです。

RKE2では、このファイルは`/var/lib/rancher/rke2/server/cred/controller.kubeconfig`にあります。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/cred/controller.kubeconfig
root:root

是正措置: デフォルトでは、RKE2はこのファイルを`/var/lib/rancher/rke2/server/cred/controller.kubeconfig`に作成し、その所有権を自動的に`root:root`に設定します。

1.1.19

Kubernetes PKIディレクトリとファイルの所有権が`root:root`に設定されていることを確認してください（自動化）。

理由

Kubernetesは、その操作の一部として多数の証明書を使用します。PKI情報を含むディレクトリとそのディレクトリ内のすべてのファイルの所有権を設定して、その整合性を維持する必要があります。ディレクトリとファイルはroot:rootによって所有されるべきです。

*結果:*パス

Audit（監査）:

stat -c %U:%G /var/lib/rancher/rke2/server/tls
root:root

是正措置: デフォルトでは、RKE2は期待される所有権`root:root`でディレクトリとファイルを作成します。手動での修正は必要ないはずです。

1.1.20

Kubernetes PKI証明書ファイルの権限が`644`またはそれ以上の制限に設定されていることを確認してください（自動化）。

理由

Kubernetesは、そのコンポーネントの操作の一部として多数の証明書ファイルを使用します。これらのファイルの権限は、整合性を保護するために644またはそれよりも厳しい設定にするべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.crt

権限が`644`またはそれ以上の制限になっていることを確認してください。

是正措置: デフォルトでは、RKE2は期待される権限`644`でファイルを作成します。手動での修正は必要ありません。

1.1.21

Kubernetes PKIキーファイルの権限が`600`に設定されていることを確認してください（自動化）。

理由

Kubernetesは、コンポーネントの操作の一部としていくつかのキーファイルを使用します。これらのファイルの権限は、整合性と機密性を保護するために600またはそれよりも厳しい設定にする必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %n\ %a /var/lib/rancher/rke2/server/tls/*.key

権限が`600`またはそれ以上の制限になっていることを確認してください。

是正措置: デフォルトでは、RKE2は期待される権限`600`でファイルを作成します。手動での修正は必要ありません。

1.2 APIサーバー

このセクションには、APIサーバーの設定フラグに関する推奨事項が含まれています。

1.2.1

--anonymous-auth引数がfalseに設定されていることを確認してください（手動）。

理由

有効にすると、他の設定された認証方法によって拒否されないリクエストは、匿名リクエストとして扱われます。これらのリクエストは、APIサーバーによって処理されます。アクセスを認可するために認証に依存し、匿名リクエストを許可しないようにしてください。

RBAC認可を使用している場合、ヘルスチェックや発見目的のためにAPIサーバーへの匿名アクセスを許可することは一般的に合理的と見なされるため、この推奨は手動です。ただし、匿名の発見があなたの目的にとって許容できるリスクであるかどうかを検討する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--anonymous-auth=false`が存在することを確認してください。

是正措置: デフォルトでは、RKE2 kube-apiserverはこのフラグと値で実行されるように設定されています。手動での修正は必要ありません。

1.2.2

--token-auth-fileパラメータが設定されていないことを確認してください（自動化）。

理由

トークンベースの認証は、apiserverへのリクエストを認証するために静的トークンを利用します。トークンはapiserver上のファイルに平文で保存され、apiserverを再起動しない限り取り消したり回転させたりすることはできません。したがって、静的トークンベースの認証は使用しないでください。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--token-auth-file`引数が存在しないことを確認してください。

是正措置: デフォルトでは、RKE2はトークン認証を有効にして実行されません。手動での修正は必要ありません。

1.2.3

--DenyServiceExternalIPsが設定されていないことを確認してください（自動化）。

理由

このアドミッションコントローラーは、ServiceフィールドexternalIPsの新規使用をすべて拒否します。この機能は非常に強力で（ネットワークトラフィックの傍受を許可）、ポリシーによって十分に制御されていません。有効にすると、クラスターのユーザーはexternalIPsを使用する新しいサービスを作成できず、既存のサービスオブジェクトのexternalIPsに新しい値を追加できません。既存のexternalIPsの使用は影響を受けず、ユーザーは既存のサービスオブジェクトのexternalIPsから値を削除できます。

ほとんどのユーザーはこの機能をまったく必要とせず、クラスター管理者は無効にすることを検討すべきです。この機能を使用する必要があるクラスターは、その使用を管理するためにカスタムポリシーを使用することを検討すべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--enable-admission-plugins`引数に`DenyServiceExternalIPs`が含まれていないことを確認してください。

是正措置: デフォルトでは、RKE2は`DenyServiceExternalIPs`をアドミッションプラグインフラグに設定しません。手動での修正は必要ありません。

1.2.4

`--kubelet-https`引数がtrueに設定されていることを確認してください（自動）。

理由

apiserverからkubeletへの接続は、シークレットやキーなどの機密データを運ぶ可能性があります。したがって、apiserverとkubelet間の通信には、トランジット中の暗号化を使用することが重要です。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--kubelet-https`引数が存在しないことを確認してください。

是正措置: デフォルトでは、RKE2 kube-apiserverはTLSで実行されるため、`--kubelet-https`パラメータを使用していません。手動での修正は必要ありません。

1.2.5

--kubelet-client-certificate`および--kubelet-client-key`引数が適切に設定されていることを確認してください（自動）。

理由

デフォルトでは、apiserverはkubeletのHTTPSエンドポイントに対して自己認証を行いません。apiserverからのリクエストは匿名として扱われます。リクエストを送信する際にapiserverがkubeletに対して自己認証を行うことを確実にするために、証明書ベースのkubelet認証を設定する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--kubelet-client-certificate`および--kubelet-client-key`引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 kube-apiserverはkubeletとの安全な通信のためにこれらの引数で実行されます。手動での修正は必要ありません。

1.2.6

`--kubelet-certificate-authority`引数が適切に設定されていることを確認してください（自動）。

理由

apiserverからkubeletへの接続は、ポッドのログを取得したり、実行中のポッドに（kubectlを通じて）接続したり、kubeletのポートフォワーディング機能を使用したりするために使用されます。これらの接続はkubeletのHTTPSエンドポイントで終了する。デフォルトでは、apiserverはkubeletのサーバー証明書を検証しないため、接続は中間者攻撃の対象となり、信頼できないおよび/または公共のネットワーク上で実行するのは安全ではありません。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--kubelet-certificate-authority`引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 kube-apiserverはkubeletとの安全な通信のためにこの引数で実行されます。手動での修正は必要ありません。

1.2.7

`--authorization-mode`引数が`AlwaysAllow`に設定されていないことを確認してください（自動）。

理由

APIサーバーは、すべてのリクエストを許可するように構成できます。このモードは、いかなる本番クラスターでも使用すべきではありません。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

引数の値に`AlwaysAllow`が含まれていないことを確認してください。

是正措置: デフォルトでは、RKE2は`--authorization-mode`引数に対して`Node,RBAC`をパラメーターとして設定します。手動での修正は必要ありません。

1.2.8

`--authorization-mode`引数に`Node`が含まれていることを確認してください（自動化）。

理由

ノード認可モードは、kubeletが自分のノードに関連するSecret、ConfigMap、PersistentVolume、およびPersistentVolumeClaimオブジェクトを読み取ることのみを許可します。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

引数のパラメーターとして`Node`が存在することを確認してください。

是正措置: デフォルトでは、RKE2は`--authorization-mode`引数に対して`Node,RBAC`をパラメーターとして設定します。手動での修正は必要ありません。

1.2.9

`--authorization-mode`引数に`RBAC`が含まれていることを確認してください（自動化）。

理由

ロールベースのアクセス制御（RBAC）は、異なるエンティティがクラスター内の異なるオブジェクトに対して実行できる操作を細かく制御することを可能にします。RBAC認可モードを使用することをお勧めします。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

引数のパラメーターとして`RBAC`が存在することを確認してください。

是正措置: デフォルトでは、RKE2は`--authorization-mode`引数に対して`Node,RBAC`をパラメーターとして設定します。手動での修正は必要ありません。

1.2.10

admission control プラグイン EventRateLimit が設定されていることを確認してください（手動）。

理由

EventRateLimit admission controlを使用すると、APIサーバーが特定の時間スライス内で受け入れるイベントの数に制限が課されます。不適切に動作するワークロードはAPIサーバーを圧倒し、DoS攻撃を引き起こし、利用できなくする可能性があります。これは特にマルチテナントクラスターに当てはまり、少数の不適切に動作するテナントがクラスター全体のパフォーマンスに大きな影響を与える可能性があります。したがって、APIサーバーが受け入れるイベントのレートを制限することをお勧めします。

これはKubernetes 1.15リリースのアルファ機能です。

結果:*手動 - オペレーター依存*

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--enable-admission-plugins 引数が EventRateLimit を含む値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--enable-admission-plugins`引数に対して`NodeRestriction,PodSecurityPolicy`をパラメーターとしてのみ設定します。これを設定するには、Kubernetes のドキュメントに従い、設定ファイルに希望の制限を設定してください。次に、kube-apiserver-arg パラメーターを介して追加の API サーバー設定を提供する方法について、RKE2 のドキュメントを参照してください。

1.2.11

admission control プラグイン AlwaysAdmit が設定されていないことを確認してください（自動）。

理由

admission control プラグイン AlwaysAdmit を設定すると、すべてのリクエストが許可され、リクエストはフィルタリングされません。

AlwaysAdmit admission コントローラーは、Kubernetes v1.13で廃止されました。その動作は、すべての admission コントローラーをオフにすることと同等でした。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--enable-admission-plugins 引数が設定されている場合、その値が AlwaysAdmit を含まないことを確認してください。

是正措置: デフォルトでは、RKE2は`--enable-admission-plugins`引数に対して`NodeRestriction,PodSecurityPolicy`をパラメーターとしてのみ設定します。手動での修正は必要ありません。

1.2.12

admission control プラグイン AlwaysPullImages が設定されていることを確認してください（手動）。

理由

admission control ポリシーを AlwaysPullImages に設定すると、新しいポッドは毎回必要なイメージをプルすることが強制されます。マルチテナントクラスターでは、ユーザーは自分のプライベートイメージがそれをプルする資格を持つ者のみが使用できることを保証されます。この admission control ポリシーがない場合、一度ノードにイメージがプルされると、任意のユーザーの任意のポッドがそのイメージの名前を知っているだけで使用でき、イメージの所有権に対する認可チェックは行われません。このプラグインが有効になっている場合、イメージはコンテナを起動する前に常にプルされるため、有効な資格情報が必要です。

結果:*手動 - オペレーター依存*

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--enable-admission-plugins 引数が AlwaysPullImages を含む値に設定されていることを確認してください。

1.2.13

PodSecurityPolicy が使用されていない場合、admission control プラグイン SecurityContextDeny が設定されていることを確認してください（手動）。

理由

SecurityContextDeny は、PodSecurityPolicies が有効でないクラスターに対してセキュリティの層を提供するために使用できます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

PodSecurityPolicy が含まれていない場合、--enable-admission-plugins 引数が SecurityContextDeny を含む値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は自動的に PodSecurityPolicy プラグインを有効にします。したがって、SecurityContextDeny プラグインは有効にする必要はありません。手動での修正は必要ありません。

1.2.14

admission control プラグイン ServiceAccount が設定されていることを確認してください（自動）。

理由

ポッドを作成する際に、サービスアカウントを指定しない場合、同じネームスペース内の default サービスアカウントが自動的に割り当てられます。独自のサービスアカウントを作成し、API サーバーにそのセキュリティトークンの管理を任せるべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--disable-admission-plugins 引数が ServiceAccount を含まない値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 はこの引数を使用しません。この引数を使用したい場合は、ドキュメントに従って、環境に応じた ServiceAccount オブジェクトを作成してください。次に、kube-apiserver-arg パラメーターを介して追加の API サーバー設定を提供する方法について、RKE2 のドキュメントを参照してください。

1.2.15

admission control プラグイン NamespaceLifecycle が設定されていることを確認してください（自動）。

理由

admission control ポリシーを NamespaceLifecycle に設定することで、存在しないネームスペースでオブジェクトが作成されないことが保証され、終了中のネームスペースが新しいオブジェクトの作成に使用されないことが確保されます。これは、ネームスペースの終了プロセスの整合性を強制し、新しいオブジェクトの可用性を確保するために推奨されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--disable-admission-plugins 引数が NamespaceLifecycle を含まない値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 はこの引数を使用しません。手動での修正は必要ありません。

1.2.16

admission control プラグイン NodeRestriction が設定されていることを確認してください（自動）。

理由

NodeRestriction プラグインを使用することで、kubelet が定義された通りに変更できる Node および Pod オブジェクトに制限されることが保証されます。その kubelet は、自分自身の Node API オブジェクトのみを変更でき、ノードにバインドされた Pod API オブジェクトのみを変更できます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--enable-admission-plugins 引数が NodeRestriction を含む値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --enable-admission-plugins 引数に対して NodeRestriction をパラメータとして設定するだけです。手動での修正は必要ありません。

1.2.17

--secure-port 引数が 0 に設定されていないことを確認してください（自動化）。

理由

セキュアポートは、認証と認可を伴う https を提供するために使用されます。これを無効にすると、https トラフィックは提供されず、すべてのトラフィックが暗号化されずに提供されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--secure-port 引数が設定されていないか、1 から 65535 の間の整数値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --secure-port 引数に対して 6443 のパラメータを設定します。手動での修正は必要ありません。

1.2.18

--profiling 引数が false に設定されていることを確認してください（自動化）。

理由

プロファイリングは、特定のパフォーマンスボトルネックを特定することを可能にします。それは、システムやプログラムの詳細を明らかにするために悪用される可能性のある大量のプログラムデータを生成します。ボトルネックが発生しておらず、トラブルシューティングの目的でプロファイラが必要ない場合は、潜在的な攻撃面を減らすためにオフにすることをお勧めします。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--profiling 引数が false に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --profiling フラグパラメータを false に設定します。手動での修正は必要ありません。

1.2.19

--audit-log-path 引数が設定されていることを確認してください（自動化）。

理由

Kubernetes API サーバーの監査は、個々のユーザー、管理者、またはシステムの他のコンポーネントによってシステムに影響を与えた活動のシーケンスを文書化した、セキュリティに関連する時系列の記録を提供します。現在、Kubernetes は基本的な監査機能のみを提供していますが、有効にするべきです。適切な監査ログパスを設定することで有効にできます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--audit-log-path 引数が適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --audit-log-path 引数とパラメータを設定します。手動での修正は必要ありません。

1.2.20

--audit-log-maxage 引数が 30 または適切に設定されていることを確認してください（自動化）。

理由

ログを少なくとも30日間保持することで、過去に遡って調査や相関を行うことができます。監査ログの保持期間を30日間またはビジネス要件に応じて設定してください。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--audit-log-maxage 引数が30または適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --audit-log-maxage 引数パラメータを30に設定します。手動での修正は必要ありません。

1.2.21

--audit-log-maxbackup 引数が 10 または適切に設定されていることを確認してください（自動化）。

理由

Kubernetesは自動的にログファイルをローテーションします。古いログファイルを保持することで、調査や相関を行うために十分なログデータが利用可能になります。例えば、ファイルサイズを100MB、保持する古いログファイルの数を10に設定した場合、約1GBのログデータが分析に使用できることになります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--audit-log-maxbackup 引数が10または適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --audit-log-maxbackup 引数パラメータを10に設定します。手動での修正は必要ありません。

1.2.22

`--audit-log-maxsize`引数が`100`または適切に設定されていることを確認してください（自動化）。

理由

Kubernetesは自動的にログファイルをローテーションします。古いログファイルを保持することで、調査や相関を行うために十分なログデータが利用可能になります。ファイルサイズを100MB、保持する古いログファイルの数を10に設定した場合、約1GBのログデータが分析に使用できることになります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--audit-log-maxsize 引数が100または適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --audit-log-maxsize 引数パラメータを100に設定します。手動での修正は必要ありません。

1.2.23

--request-timeout 引数が適切に設定されていることを確認してください（自動化）。

理由

グローバルリクエストタイムアウトを設定することで、APIサーバーのリクエストタイムアウト制限をユーザーの接続速度に適した期間に延長できます。デフォルトでは、60秒に設定されており、遅い接続では問題が発生する可能性があり、リクエストのデータ量が60秒以内に送信できる量を超えると、クラスターリソースにアクセスできなくなります。しかし、このタイムアウト制限を大きく設定しすぎると、APIサーバーのリソースが枯渇し、サービス拒否攻撃に対して脆弱になります。したがって、この制限を適切に設定し、必要な場合にのみデフォルトの60秒の制限を変更することが推奨されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--request-timeout 引数が設定されていないか、適切な値に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --request-timeout 引数を設定しません。手動での修正は必要ありません。

1.2.24

--service-account-lookup 引数が true に設定されていることを確認してください（自動化）。

理由

`--service-account-lookup`が有効でない場合、apiserverは認証トークンが有効であることのみを確認し、リクエストに記載されたサービスアカウントトークンが実際にetcdに存在するかどうかは検証しません。これにより、対応するサービスアカウントが削除された後でもサービスアカウントトークンを使用できます。これは、チェック時から使用時までのセキュリティ問題の一例です。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--service-account-lookup 引数が存在する場合、それが true に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 はデフォルトの効果を優先してこの引数を設定しません。手動での修正は必要ありません。

1.2.25

--service-account-key-file 引数が適切に設定されていることを確認してください（自動化）。

理由

デフォルトでは、apiserverに --service-account-key-file が指定されていない場合、TLSサービング証明書からの秘密鍵を使用してサービスアカウントトークンを検証します。サービスアカウントトークンの鍵を必要に応じてローテーションできるようにするために、サービスアカウントトークンに署名するための別の公開/秘密鍵ペアを使用する必要があります。したがって、公開鍵は --service-account-key-file を使用して apiserver に指定する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--service-account-key-file 引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --service-account-key-file を明示的に設定します。手動での修正は必要ありません。

1.2.26

--etcd-certfile と --etcd-keyfile の引数が適切に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリューストアです。これらのオブジェクトは機密性が高いため、クライアント認証によって保護されるべきです。これには、APIサーバーがクライアント証明書とキーを使用してetcdサーバーに自己を識別させる必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

引数 --etcd-certfile および --etcd-keyfile が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --etcd-certfile および --etcd-keyfile 引数を明示的に設定します。手動での修正は必要ありません。

1.2.27

引数 --tls-cert-file および --tls-private-key-file が適切に設定されていることを確認してください（自動化）。

理由

APIサーバーの通信には、転送中に暗号化されるべき機密パラメータが含まれています。APIサーバーがHTTPSトラフィックのみ提供するように構成してください。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

--tls-cert-file`および--tls-private-key-file`の引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--tls-cert-file`および`--tls-private-key-file`の引数を明示的に設定します。手動での修正は必要ありません。

1.2.28

`--client-ca-file`引数が適切に設定されていることを確認してください（自動化）。

理由

APIサーバーの通信には、転送中に暗号化されるべき機密パラメータが含まれています。APIサーバーがHTTPSトラフィックのみ提供するように構成してください。`--client-ca-file`の引数が設定されている場合、`client-ca-file`の権限のいずれかによって署名されたクライアント証明書を提示するリクエストは、クライアント証明書のCommonNameに対応するアイデンティティで認証されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--client-ca-file`の引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--client-ca-file`の引数を明示的に設定します。手動での修正は必要ありません。

1.2.29

`--etcd-cafile`引数が適切に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリューストアです。これらのオブジェクトは機密性が高いため、クライアント認証によって保護されるべきです。これには、APIサーバーがSSL CAファイルを使用してetcdサーバーに自己を識別させる必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--etcd-cafile`の引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--etcd-cafile`の引数を明示的に設定します。手動での修正は必要ありません。

1.2.30

`--encryption-provider-config`引数が適切に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリューストアです。これらのオブジェクトは機密性が高いため、開示を避けるために静止時に暗号化されるべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--encryption-provider-config`の引数がEncryptionConfigfileに設定されていることを確認してください。さらに、`EncryptionConfigfile`が特にすべてのシークレットをカバーするように必要なリソースを持っていることを確認してください。

是正措置: デフォルトでは、RKE2は`--encryption-provider-config`の引数を明示的に設定します。手動での修正は必要ありません。RKE2のデフォルトの暗号化プロバイダー構成ファイルは`/var/lib/rancher/rke2/server/cred/encryption-config.json`にあり、シークレットを暗号化するように構成されています。

1.2.31

暗号化プロバイダーが適切に構成されていることを確認してください（自動化）。

理由

etcd`の暗号化を使用する場合、適切な暗号化プロバイダーセットが選択されていることを確認することが重要です。現在、`aescbc、kms、および`secretbox`が適切な選択肢である可能性が高いです。

*結果:*パス

是正措置: Kubernetesのドキュメントに従って、`EncryptionConfig`ファイルを構成してください。このファイルでは、暗号化プロバイダーとして*aescbc*、kms、または*secretbox*を選択してください。

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep aescbc /var/lib/rancher/rke2/server/cred/encryption-config.json

マスターノードで以下のコマンドを実行してください。

aescbcがすべての対象とするリソースの暗号化プロバイダーとして設定されていることを確認してください。

修正デフォルトでは、RKE2は引数`--encryption-provider-config`とパラメーターを設定します。設定ファイルの内容は、aescbcの使用を示しています。手動での修正は必要ありません。

1.2.32

APIサーバーが強力な暗号化シファーのみを使用することを確認してください（手動）。

理由

TLSシファーには、知られている脆弱性や弱点がいくつかあり、それにより提供される保護が低下する可能性があります。デフォルトでは、Kubernetesはセキュリティ上の懸念があるものを含む複数のTLS暗号スイートをサポートしており、これにより提供される保護が弱まっています。

結果:*手動 - オペレーター依存*

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

以下の修正手順に従って、`--tls-cipher-suites`引数が設定されていることを確認してください。

是正措置: デフォルトでは、RKE2はこのフラグを明示的に設定しません。手動での修正は必要ありません。

1.3 コントローラーマネージャー

1.3.1

`--terminated-pod-gc-threshold`引数が適切に設定されていることを確認してください（手動）。

理由

ガーベジコレクションは、十分なリソースの可用性を確保し、パフォーマンスと可用性の低下を避けるために重要です。最悪の場合、システムがクラッシュするか、長期間使用できなくなる可能性があります。ガーベジコレクションの現在の設定は、12,500の終了したポッドであり、これはシステムが維持するには高すぎる可能性があります。システムリソースとテストに基づいて、ガーベジコレクションを有効にするための適切な閾値を選択してください。

結果:*手動 - オペレーター依存*

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--terminated-pod-gc-threshold`引数が適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--terminated-pod-gc-threshold`引数を値1000で設定します。手動での修正は必要ありません。

1.3.2

`--profiling`引数がfalseに設定されていることを確認してください（自動化）。

理由

プロファイリングは、特定のパフォーマンスボトルネックを特定することを可能にします。それは、システムやプログラムの詳細を明らかにするために悪用される可能性のある大量のプログラムデータを生成します。ボトルネックが発生しておらず、トラブルシューティングの目的でプロファイラーが必要ない場合は、潜在的な攻撃対象領域を減らすためにオフにすることをお勧めします。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--profiling`引数がfalseに設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--profiling`フラグパラメータをfalseに設定します。手動での修正は必要ありません。

1.3.3

`--use-service-account-credentials`引数が`true`に設定されていることを確認してください（自動化）。

理由

コントローラーマネージャーは、kube-system`ネームスペース内の各コントローラーに対してサービスアカウントを作成し、それに対して資格情報を生成し、各コントローラーのループが使用するためにそのサービスアカウントの資格情報を持つ専用のAPIクライアントを構築します。--use-service-account-credentials`を`true`に設定すると、コントローラーマネージャー内の各制御ループが別のサービスアカウントの資格情報を使用して実行されます。RBACと組み合わせて使用することで、制御ループが意図されたタスクを実行するために必要な最小限の権限で実行されることが保証されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--use-service-account-credentials`引数がtrueに設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--use-service-account-credentials`引数をtrueに設定します。手動での修正は必要ありません。

1.3.4

`--service-account-private-key-file`引数が適切に設定されていることを確認してください（自動化）。

理由

サービスアカウントトークンのキーを必要に応じて回転できるようにするために、サービスアカウントトークンに署名するための別の公開/秘密鍵ペアを使用する必要があります。秘密鍵は、適切に`--service-account-private-key-file`を指定してコントローラーマネージャーに渡す必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--service-account-private-key-file`引数が適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2はサービスアカウントキーファイルを使用して`--service-account-private-key-file`引数を設定します。手動での修正は必要ありません。

1.3.5

`--root-ca-file`引数が適切に設定されていることを確認してください（自動化）。

理由

APIサーバーに連絡する必要があるポッド内で実行されているプロセスは、APIサーバーのサービング証明書を検証する必要があります。これを怠ると、中間者攻撃の対象となる可能性があります。

APIサーバーのサービング証明書のルート証明書を`--root-ca-file`引数でコントローラーマネージャーに提供することで、コントローラーマネージャーは信頼されたバンドルをポッドに注入し、ポッドがAPIサーバーへのTLS接続を検証できるようにします。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--root-ca-file`引数が存在し、APIサーバーのサービング証明書のルート証明書を含む証明書バンドルファイルに設定されていることを確認してください。

是正措置: デフォルトでは、RKE2はルートCAファイルを使用して`--root-ca-file`引数を設定します。手動での修正は必要ありません。

1.3.6

`RotateKubeletServerCertificate`引数が`true`に設定されていることを確認してください（自動化）。

理由

`RotateKubeletServerCertificate`は、kubeletがクライアント資格情報をブートストラップした後に提供証明書をリクエストし、既存の資格情報が期限切れになると証明書を回転させる原因となります。この自動的な定期回転により、期限切れの証明書によるダウンタイムが発生しないことが保証され、CIAセキュリティトライアドにおける可用性が確保されます。

この推奨事項は、kubeletがAPIサーバーから証明書を取得する場合にのみ適用されます。kubeletの証明書が外部の権限/ツール（例：Vault）から取得される場合は、自分で回転を管理する必要があります。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

RotateKubeletServerCertificate引数が存在し、trueに設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は証明書の生成と回転のための独自のロジックを実装しています。

1.3.7

`--bind-address`引数が`127.0.0.1`に設定されていることを確認してください（自動化）。

理由

デフォルトでポート10252/TCPで実行されるコントローラーマネージャーAPIサービスは、ヘルスとメトリクス情報に使用され、認証や暗号化なしで利用可能です。そのため、クラスターの攻撃面を最小限に抑えるために、localhostインターフェースにのみバインドする必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-controller-manager | grep -v grep

`--bind-address`引数が127.0.0.1に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --bind-address 引数を 127.0.0.1 に設定します。手動での修正は必要ありません。

1.4 スケジューラ

このセクションには、スケジューラの設定フラグに関する推奨事項が含まれています。

1.4.1

`--profiling`引数が`false`に設定されていることを確認してください（自動化）。

理由

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-scheduler | grep -v grep

`--profiling`引数がfalseに設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --profiling フラグパラメータを false に設定します。手動での修正は必要ありません。

1.4.2

`--bind-address`引数が`127.0.0.1`に設定されていることを確認してください（自動化）。

理由

デフォルトでポート 10251/TCP で実行されるスケジューラ API サービスは、ヘルスおよびメトリクス情報に使用され、認証や暗号化なしで利用可能です。そのため、クラスターの攻撃面を最小限に抑えるために、localhostインターフェースにのみバインドする必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-scheduler | grep -v grep

`--bind-address`引数が127.0.0.1に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は --bind-address 引数を 127.0.0.1 に設定します。手動での修正は必要ありません。

2 Etcdノードの設定

このセクションでは、etcd の設定に関する推奨事項を扱います。

2.1

cert-file および key-file フィールドが適切に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリューストアです。これらのオブジェクトは機密性が高いため、転送中に暗号化する必要があります。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep -E 'cert-file|key-file' /var/lib/rancher/rke2/server/db/etcd/config

cert-file および key-file フィールドが適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。サーバーおよびピアの証明書とキーのファイルが指定されています。手動での修正は必要ありません。

2.2

client-cert-auth フィールドが true に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリューストアです。これらのオブジェクトは機密性が高いため、認証されていないクライアントに対しては利用できないようにする必要があります。etcd サービスへのアクセスを保護するために、有効な証明書を介してクライアント認証を有効にする必要があります。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep 'client-cert-auth' /var/lib/rancher/rke2/server/db/etcd/config

client-cert-auth フィールドが true に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。client-cert-auth は true に設定されています。手動での修正は必要ありません。

2.3

auto-tls フィールドが true に設定されていないことを確認してください（自動化）。

理由

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep 'auto-tls' /var/lib/rancher/rke2/server/db/etcd/config

auto-tls フィールドが存在しない場合を確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。ファイル内には auto-tls 引数が含まれていません。手動での修正は必要ありません。

2.4

peer-cert-file および peer-key-file フィールドが適切に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。これらのオブジェクトは機密性が高いため、転送中および etcd クラスター内のピア間でも暗号化する必要があります。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep -E 'peer-server-client.crt|peer-server-client.key' /var/lib/rancher/rke2/server/db/etcd/config

peer-server-client.crt および peer-server-client.key フィールドが適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。ファイル内で、peer-server-client.crt および peer-server-client.key フィールドが設定されています。手動での修正は必要ありません。

2.5

peer-client-cert-auth 引数が true に設定されていることを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。これらのオブジェクトは機密性が高く、etcd クラスター内の認証された etcd ピアのみがアクセスできるべきです。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep 'peer-client-cert-auth' /var/lib/rancher/rke2/server/db/etcd/config

peer セクションの peer-client-cert-auth フィールドが true に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。ファイル内で、client-cert-auth フィールドが設定されています。手動での修正は必要ありません。

2.6

peer-auto-tls フィールドが true に設定されていないことを確認してください（自動化）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。これらのオブジェクトは機密性が高く、etcd クラスター内の認証された etcd ピアのみがアクセスできるべきです。したがって、認証には自己署名証明書を使用しないでください。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

grep 'peer-auto-tls' /var/lib/rancher/rke2/server/db/etcd/config

peer-auto-tls フィールドが存在しない場合を確認してください。

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/db/etcd/config にある etcd 用の設定ファイルを使用します。ファイル内に peer-auto-tls フィールドが含まれていません。手動での修正は必要ありません。

2.7

etcd に対して一意の認証局が使用されていることを確認してください（手動）。

理由

etcdは、KubernetesのデプロイメントによってすべてのREST APIオブジェクトの永続ストレージに使用される高可用性のキー・バリュー・ストアです。そのアクセスは、特に指定されたクライアントとピアのみに制限されるべきです。

etcd への認証は、提示された証明書が信頼された証明書機関によって発行されたかどうかに基づいています。一般名や代替名などの証明書属性のチェックは行われません。そのため、もし攻撃者が信頼された証明書機関によって発行された証明書にアクセスできた場合、etcd データベースに完全にアクセスできることになります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

# To find the ca file used by etcd:
grep 'trusted-ca-file' /var/lib/rancher/rke2/server/db/etcd/config
# To find the kube-apiserver process:
/bin/ps -ef | grep kube-apiserver | grep -v grep

apiserver プロセスの client-ca-file フラグによって参照されるファイルが、etcd 設定ファイルの trusted-ca-file パラメータによって参照されるファイルと異なることを確認してください。

是正措置: デフォルトでは、RKE2 は etcd 用の設定ファイルを使用し、それは /var/lib/rancher/rke2/server/db/etcd/config にあり、そこにある trusted-ca-file パラメータは etcd に特有の一意の値に設定されています。手動での修正は必要ありません。

3 コントロールプレーンの設定

3.1 認証と権限付与

3.1.1

クライアント証明書認証はユーザーには使用されるべきではありません（手動）。

理由

任意の認証メカニズムでは、資格情報が侵害された場合やもはや必要でない場合にそれを取り消す能力が重要な制御です。Kubernetes のクライアント証明書認証は、証明書の取り消しをサポートしていないため、この機能に対応していません。

*結果:*手動 - オペレーター依存

Audit（監査）: クラスターへのユーザーアクセスを確認し、ユーザーがKubernetesクライアント証明書認証を使用していないことを確認してください。

是正措置: クライアント証明書の代わりにOIDCの使用など、Kubernetesが提供する代替メカニズムを実装する必要があります。

3.2 ログ記録

3.2.1

最小限の監査ポリシーが作成されていることを確認してください（自動化）。

理由

ログ記録は、潜在的な不正アクセスを検出するためのすべてのシステムにとって重要な検出制御です。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kube-apiserver | grep -v grep

`--audit-policy-file`が設定されていることを確認してください。指定されたファイルの内容を確認し、有効な監査ポリシーが含まれていることを確認してください。

是正措置: クラスター用の監査ポリシーファイルを作成してください。

3.2.2

監査ポリシーが主要なセキュリティの懸念をカバーしていることを確認してください（手動）。

理由

セキュリティ監査ログは、クラスター内の主要なリソースへのアクセスと変更をカバーし、セキュリティ環境の効果的な一部を形成できるようにする必要があります。

*結果:*手動 - オペレーター依存

是正措置:

4 ワーカーノードのセキュリティ設定

4.1 ワーカーノードの設定ファイル

4.1.1

kubelet サービスファイルの権限が 644 以下に設定されていることを確認してください (自動化)。

理由

kubelet サービスファイルは、ワーカーノードにおける kubelet サービスの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*該当なし

是正措置: RKE2 は kubelet をサービスとして起動しません。それは RKE2 スーパーバイザープロセスによって起動および管理されます。すべての設定は、実行時にコマンドライン引数として渡されます。

4.1.2

kubelet サービスファイルの所有権が root:root に設定されていることを確認してください (自動化)。

理由

kubelet サービスファイルは、ワーカーノードにおける kubelet サービスの動作を設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。そのファイルは root:root に所有されるべきです。

*結果:*該当なし

4.1.3

プロキシ kubeconfig ファイルの権限が 644 以下に設定されていることを確認してください (手動)。

理由

kube-proxy kubeconfig ファイルは、ワーカーノードにおける kube-proxy サービスのさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

ファイルの代わりに Kubernetes ConfigMap として構成された kubeconfig パラメータで kube-proxy を実行することも可能です。この場合、プロキシ kubeconfig ファイルは存在しません。

*結果:*パス

Audit（監査）: ワーカーノードで以下のコマンドを実行してください。

stat -c %a /var/lib/rancher/rke2/server/manifests/rke2-kube-proxy.yaml
644

ファイルが指定されていて存在する場合、権限が 644 以下であることを確認してください。

是正措置: デフォルトでは、RKE2 は rke2-kube-proxy.yaml を 644 権限で作成します。手動での修正は必要ありません。

4.1.4

プロキシ kubeconfig ファイルの所有権が root:root に設定されていることを確認してください (手動)。

理由

kube-proxy 用の kubeconfig ファイルは、ワーカーノードにおける kube-proxy サービスのさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。ファイルの所有者は root:root である必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %U:%G /var/lib/rancher/rke2/server/manifests/rke2-kube-proxy.yaml
root:root

ファイルが指定されていて存在する場合、権限が 644 以下であることを確認してください。

是正措置: デフォルトでは、RKE2 は rke2-kube-proxy.yaml を root:root の所有権で作成します。手動での修正は必要ありません。

4.1.5

kubelet.conf ファイルの権限が 644 以下に設定されていることを確認してください (自動化)。

理由

kubelet.conf ファイルはノードの kubeconfig ファイルであり、ワーカーノードの動作とアイデンティティを設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*該当なし

Audit（監査）: ワーカーノードで以下のコマンドを実行してください。

stat -c %a /var/lib/rancher/rke2/agent/kubelet.kubeconfig
644

是正措置: デフォルトでは、RKE2 は kubelet.kubeconfig を 644 権限で作成します。手動での修正は必要ありません。

4.1.6

kubelet.conf ファイルの所有権が root:root に設定されていることを確認してください (手動)。

理由

kubelet.conf ファイルはノードの kubeconfig ファイルであり、ワーカーノードの動作とアイデンティティを設定するさまざまなパラメータを制御します。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。そのファイルは root:root に所有されるべきです。

*結果:*該当なし

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %U:%G /var/lib/rancher/rke2/agent/kubelet.kubeconfig
root:root

是正措置: デフォルトでは、RKE2 は kubelet.kubeconfig を作成し、所有権は root:root になります。手動での修正は必要ありません。

4.1.7

証明書機関ファイルの権限が 644 以下に設定されていることを確認してください (手動)。

理由

証明書機関ファイルは、API リクエストの検証に使用される認証局を制御します。ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*手動 - オペレーター依存

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %a /var/lib/rancher/rke2/server/tls/server-ca.crt
644

権限が 644 であることを確認してください。

是正措置: デフォルトでは、RKE2 は 644 の権限で /var/lib/rancher/rke2/server/tls/server-ca.crt を作成します。

4.1.8

クライアント証明書機関ファイルの所有権が root:root に設定されていることを確認してください (自動化)。

理由

証明書機関ファイルは、API リクエストの検証に使用される認証局を制御します。ファイルの整合性を維持するために、そのファイルの所有権を設定する必要があります。そのファイルは root:root に所有されるべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

stat -c %U:%G /var/lib/rancher/rke2/server/tls/client-ca.crt
root:root

是正措置: デフォルトでは、RKE2 は /var/lib/rancher/rke2/server/tls/client-ca.crt を作成し、所有権は root:root になります。

4.1.9

kubelet 設定ファイルの権限が 600 以下に設定されていることを確認してください (自動化)。

理由

kubelet は --config 引数で指定された設定ファイルから、セキュリティ設定を含むさまざまなパラメータを読み取ります。このファイルが指定されている場合は、ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは、システム上の管理者のみが書き込み可能であるべきです。

*結果:*該当なし

是正措置: RKE2 は kubelet 設定ファイルを必要とせず、維持もしません。すべての設定は、実行時にコマンドライン引数として渡されます。

4.1.10

kubelet 構成ファイルの所有権が root:root に設定されていることを確認してください (自動化)。

理由

kubelet は --config 引数で指定された設定ファイルから、セキュリティ設定を含むさまざまなパラメータを読み取ります。このファイルが指定されている場合は、ファイルの整合性を維持するために、そのファイルの権限を制限する必要があります。そのファイルは root:root に所有されるべきです。

*結果:*該当なし

是正措置: RKE2 は kubelet 設定ファイルを必要とせず、維持もしません。すべての設定は、実行時にコマンドライン引数として渡されます。

4.2 Kubelet

このセクションには、kubelet 構成に関する推奨事項が含まれています。

4.2.1

--anonymous-auth 引数が false に設定されていることを確認してください (自動化)。

理由

有効にすると、他の構成された認証方法によって拒否されないリクエストは匿名リクエストとして扱われます。これらのリクエストは Kubelet サーバーによって処理されます。アクセスを認可し、匿名リクエストを許可しないように認証に依存するべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

--anonymous-auth の値が false であることを確認してください。

是正措置: デフォルトでは、RKE2 は kubelet を、--anonymous-auth が false に設定された状態で起動します。手動での修正は必要ありません。

4.2.2

--authorization-mode 引数が AlwaysAllow に設定されていないことを確認してください (自動化)。

理由

Kubeletはデフォルトで、明示的な認可チェックをapiserverから必要とせず、すべての認証されたリクエスト（匿名リクエストを含む）を許可します。この動作を制限し、明示的に認可されたリクエストのみを許可するべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

AlwaysAllow が存在しないことを確認してください。

是正措置: RKE2 は --authorization-mode 引数の値として Webhook を使用して kubelet を起動します。手動での修正は必要ありません。

4.2.3

--client-ca-file 引数が適切に設定されていることを確認してください (自動化)。

理由

apiserverからkubeletへの接続は、ポッドのログを取得したり、実行中のポッドに（kubectl を通じて）接続したり、kubeletのポートフォワーディング機能を使用したりするために使用されます。これらの接続は kubelet の HTTPS エンドポイントで終了します。デフォルトでは、apiserver は kubelet のサービング証明書を検証せず、これにより接続が中間者攻撃の対象となり、信頼できないまたは公共のネットワーク上で実行するには安全ではありません。Kubelet証明書認証を有効にすると、apiserver はリクエストを送信する前に Kubelet を認証できるようになります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

`--client-ca-file`引数に関連付けられたCAファイルがあることを確認してください。

是正措置: デフォルトでは、RKE2は`--client-ca-file`を使用してkubeletプロセスを起動します。手動での修正は必要ありません。

4.2.4

`--read-only-port`引数が`0`に設定されていることを確認してください（自動）。

理由

Kubeletプロセスは、メインのKubelet APIに加えて、読み取り専用APIを提供します。この読み取り専用APIには認証されていないアクセスが提供され、クラスターに関する潜在的に機密情報を取得する可能性があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

`--read-only-port`引数が0に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2は`--read-only-port`引数を0に設定してkubeletプロセスを開始します。

4.2.5

`--streaming-connection-idle-timeout`引数が`0`に設定されていないことを確認してください（自動）。

理由

アイドルタイムアウトを設定することで、サービス拒否攻撃、非アクティブな接続、およびエフェメラルポートの枯渇から保護されます。

デフォルトでは、--streaming-connection-idle-timeout は 4 時間に設定されており、これはお使いの環境には長すぎる可能性があります。適切に設定することで、そのようなストリーミング接続は、正当な利用が終了した後にタイムアウトすることが保証されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

何も返されていないことを確認してください。

是正措置: デフォルトでは、RKE2 は kubelet を起動する際に --streaming-connection-idle-timeout を設定しません。

4.2.6

`--protect-kernel-defaults`引数が`true`に設定されていることを確認してください（自動）。

理由

カーネルパラメータは、システム管理者によって、システムを本番環境に投入する前に調整され、強化されることが一般的です。これらのパラメータは、カーネルとシステムを保護します。そのようなパラメータに依存する kubelet カーネルのデフォルトは、望ましいセキュアなシステム状態に一致するように適切に設定されるべきです。これを無視すると、望ましくないカーネル動作を持つポッドが実行される可能性があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

是正措置: profile フラグが cis-1.23 に設定されている場合、RKE2 は --protect-kernel-defaults 引数を true に設定して kubelet プロセスを開始します。

4.2.7

`--make-iptables-util-chains`引数が`true`に設定されていることを確認してください（自動）。

理由

Kubelet は、ポッドのネットワーキングオプションを選択する方法に基づいて、iptables に必要な変更を自動的に管理できます。Kubelet に iptables の変更を管理させることをお勧めします。これにより、iptables の設定がポッドのネットワーキング設定と同期した状態を保つことができます。動的なポッドネットワーク設定変更で iptables を手動で設定すると、ポッド/コンテナ間および外部との通信が妨げられる可能性があります。iptables ルールが制限が厳しすぎるか、または緩すぎる可能性があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

結果が返されていないことを確認してください。

是正措置: デフォルトでは、RKE2 は --make-iptables-util-chains 引数を設定しません。手動での修正は必要ありません。

4.2.8

--hostname-override 引数が設定されていないことを確認してください（手動）。

理由

ホスト名のオーバーライドは、kubeletとapiserver間のTLS設定を壊す可能性があります。さらに、オーバーライドされたホスト名では、特定のノードにログを関連付けてセキュリティ分析のために処理することがますます難しくなります。したがって、kubeletノードを解決可能なFQDNで設定し、ホスト名をIPでオーバーライドすることは避けるべきです。

*結果:*該当なし

是正措置: RKE2は各ホストに対してこのパラメータを設定しますが、RKE2はクラスター内のすべての証明書も管理します。それは、ホスト名のオーバーライドがkubeletの証明書の主題代替名（SAN）として含まれることを保証します。

4.2.9

--event-qps 引数が0または適切なイベントキャプチャを保証するレベルに設定されていることを確認してください（手動）。

理由

すべてのイベントをキャプチャし、イベントの作成を制限しないことが重要です。イベントは、環境がイベントデータを使用して一貫して監視されることを保証する重要なセキュリティ情報と分析のソースです。

*結果:*手動 - オペレーター依存

是正措置: これに関する詳細はCISベンチマークガイドを参照してください。

4.2.10

--tls-cert-file および --tls-private-key-file 引数が適切に設定されていることを確認してください（自動）。

理由

Kubeletの通信には、転送中に暗号化されるべき機密パラメータが含まれています。KubeletをHTTPSトラフィックのみを提供するように構成してください。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

--tls-cert-file および --tls-private-key-file 引数が存在し、適切に設定されていることを確認してください。

是正措置: デフォルトでは、RKE2はkubeletプロセスを実行する際に`--tls-cert-file`および`--tls-private-key-file`引数を設定します。

4.2.11

--rotate-certificates 引数が`false`に設定されていないことを確認してください（手動）。

理由

--rotate-certificates 設定は、kubeletが既存の資格情報が期限切れになると新しいCSRを作成することによってクライアント証明書をローテーションさせる原因となります。この自動的な定期ローテーションにより、期限切れの証明書によるダウンタイムが発生せず、CIAセキュリティトライアドにおける可用性が確保されます。

この推奨事項は、kubeletがAPIサーバーから証明書を取得する場合にのみ適用されます。kubeletの証明書が外部の権威/ツール（例：Vault）から来る場合は、ローテーションを自分で管理する必要があります。

この機能は、RotateKubeletClientCertificate 機能ゲートが有効である必要があります（Kubernetes v1.7以降はデフォルトで有効です）。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

是正措置: デフォルトでは、RKE2は証明書の生成とローテーションのための独自のロジックを実装しています。

4.2.12

RotateKubeletServerCertificate 引数が true に設定されていることを確認してください（手動）。

理由

RotateKubeletServerCertificate は、kubeletがクライアント資格情報をブートストラップした後にサービング証明書を要求し、既存の資格情報が期限切れになると証明書をローテーションする原因となります。この自動的な定期ローテーションにより、期限切れの証明書によるダウンタイムが発生せず、CIAセキュリティトライアドにおける可用性が確保されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/bin/ps -ef | grep kubelet | grep -v grep

是正措置: デフォルトでは、RKE2は証明書の生成とローテーションのための独自のロジックを実装しています。

4.2.13

Kubelet が強力な暗号スイートのみを利用していることを確認してください（手動）。

理由

TLS暗号には多くの既知の脆弱性や弱点があり、それにより提供される保護が低下する可能性があります。デフォルトでは、Kubernetesはセキュリティ上の懸念があるいくつかのTLS暗号スイートを含む多数のTLS暗号スイートをサポートしており、その結果、提供される保護が弱まる可能性があります。

*結果:*手動 - オペレーター依存

是正措置: パラメータの設定は、使用ケースに依存します。使用ケースに応じた設定の提案については、CIS Kubernetesベンチマークを参照してください。

5つのKubernetesポリシー

5.1 RBACとサービスアカウント

5.1.1

クラスター管理者ロールは必要な場合にのみ使用されることを確認してください（手動）。

理由

Kubernetesは、RBACが使用される一連のデフォルトロールを提供します。これらのロールの中には、cluster-admin のように、絶対に必要な場合にのみ適用すべき広範な特権を提供するものがあります。cluster-admin のようなロールは、任意のリソースに対して任意のアクションを実行するためのスーパーユーザーアクセスを許可します。ClusterRoleBinding で使用されると、クラスター内のすべてのリソースとすべてのネームスペースに対する完全な制御が与えられます。RoleBinding で使用されると、ロールバインディングのネームスペース内のすべてのリソース、ネームスペース自体を含む完全な制御が与えられます。

*結果:*パス

是正措置: RKE2はクラスター管理者ロールを不適切に使用しません。オペレーターは、ワークロードにおける追加の使用状況を監査する必要があります。詳細については、CISベンチマークガイドを参照してください。

5.1.2

シークレットへのアクセスを最小限に抑える（手動）。

理由

Kubernetesクラスター内に保存されたシークレットへの不適切なアクセスは、攻撃者がKubernetesクラスターやシークレットとして保存された資格情報を持つ外部リソースへの追加のアクセスを得ることを可能にします。

*結果:*手動 - オペレーター依存

是正措置: RKE2 はシステムコンポーネントのためにシークレットの使用を適切に制限していますが、オペレーターはワークロードによるシークレットの使用を監査する必要があります。詳細については、CISベンチマークガイドを参照してください。

5.1.3

ロールとクラスターロールでのワイルドカードの使用を最小限に抑える（手動）。

理由

最小権限の原則は、ユーザーにその役割に必要なアクセスのみを提供し、それ以上は与えないことを推奨します。ワイルドカード権限の使用は、Kubernetes API に過剰な権限を付与する可能性があります。

*結果:*手動 - オペレーター依存

Audit（監査）: マスターノードで以下のコマンドを実行してください。

# Retrieve the roles defined across each namespaces in the cluster and review for wildcards
/var/lib/rancher/rke2/bin/kubectl get roles --all-namespaces -o yaml

# Retrieve the cluster roles defined in the    cluster    and    review for wildcards
/var/lib/rancher/rke2/bin/kubectl get clusterroles -o yaml

使用中のワイルドカードがないことを確認してください。

是正措置: オペレーターは、ワークロードによる適切なロールの使用を確認する必要があります。詳細については、CISベンチマークガイドを参照してください。

5.1.4

ポッドの作成へのアクセスを最小限に抑える（手動）。

理由

クラスター内でポッドを作成する能力は、特権の昇格の可能性を開くため、可能な限り制限すべきです。

*結果:*手動 - オペレーター依存

是正措置: オペレーターは、クラスター内でポッドを作成するアクセス権を持つ者を確認する必要があります。詳細については、CISベンチマークガイドを参照してください。

5.1.5

デフォルトのサービスアカウントが積極的に使用されていないことを確認してください。（自動化）。

理由

Kubernetes は、ポッドに特定のサービスアカウントが割り当てられていないクラスターのワークロードによって使用されるデフォルトのサービスアカウントを提供します。

ポッドから Kubernetes API へのアクセスが必要な場合、そのポッドのために特定のサービスアカウントを作成し、そのサービスアカウントに権限を付与する必要があります。

デフォルトのサービスアカウントは、サービスアカウントトークンを提供せず、明示的な権限の割り当てを持たないように構成されるべきです。

*結果:*パス。

Audit（監査）: クラスター内の各ネームスペースについて、デフォルトのサービスアカウントに割り当てられた権限を確認し、デフォルト以外のロールやクラスターロールがバインドされていないことを確認してください。さらに、各デフォルトのサービスアカウントに対して automountServiceAccountToken: false 設定が適用されていることを確認してください。

是正措置: Kubernetes ワークロードが Kubernetes API サーバーへの特定のアクセスを必要とする場合は、明示的なサービスアカウントを作成してください。各デフォルトのサービスアカウントの構成を変更して、この値を含める必要があります。

automountServiceAccountToken: false

5.1.6

サービスアカウントトークンが必要な場所にのみマウントされることを確認してください（手動）。

理由

ポッド内にサービスアカウントトークンをマウントすることは、攻撃者がクラスター内の単一のポッドを侵害できる場合に特権昇格攻撃の手段を提供する可能性があります。

これらのトークンをマウントしないことで、この攻撃経路を排除できます。

*結果:*手動 - オペレーター依存

是正措置: RKE2によって起動されたポッドは制御プレーンの一部であり、一般的にAPIサーバーと通信するためのアクセスが必要です。したがって、この制御はそれらには適用されません。オペレーターは自分のワークロードを確認し、サービスアカウントトークンをマウントする必要のないポッドとサービスアカウントの定義を変更するための手続きを講じるべきです。

5.1.7

system:mastersグループの使用を避けてください（手動）。

理由

system:mastersグループは、APIサーバーのソースコードにハードコーディングされたKubernetes APIへの無制限のアクセスを持っています。このグループのメンバーである認証済みユーザーは、すべてのバインディングおよびクラスター役割バインディングが削除されても、そのアクセスを減少させることはできません。

クライアント証明書認証と組み合わせることで、このグループの使用はクラスターに対して取り消し不可能なクラスター管理者レベルの資格情報を存在させることができます。

*結果:*手動 - オペレーター依存

是正措置: クラスター内のすべてのユーザーから system:masters グループを削除してください。

5.1.7

Kubernetesクラスター内でのBind、Impersonate、Escalate権限の使用を制限してください（手動）。

理由

Impersonate権限により、主体が他のユーザーになりすまして、そのユーザーのクラスターに対する権限を獲得できるようになります。Bind権限は、主体がロールまたはクラスター・ロールにバインディングを追加することで、クラスター内での実効権限を高めることを可能にします。Escalate権限は、主体がバインドされているクラスター・ロールを変更することで、その権限を引き上げることを可能にします。

*結果:*手動 - オペレーター依存

是正措置: 可能な限り、対象から impersonate、bind、escalate 権限を削除してください。

5.2 ポッドセキュリティ標準

5.2.1

クラスターに少なくとも1つのアクティブなポリシー制御メカニズムが存在することを確認してください（手動）。

理由

アクティブなポリシー制御メカニズムがない場合、特権コンテナやhostPathボリュームマウントの使用を通じて、基盤となるクラスターのノードへのアクセスを制限することはできません。

*結果:*手動 - オペレーター依存

是正措置: PSAはRKE2のv1.23以降、デフォルトで有効になっており、修正は必要ありません。

5.2.2

特権コンテナの受け入れを最小限に抑えてください（手動）。

理由

ホストのPIDネームスペースで実行されているコンテナは、コンテナの外で実行されているプロセスを検査することができます。コンテナがptrace機能にもアクセスできる場合、これを使用してコンテナの外で権限を昇格させることができます。

ホストのPIDネームスペースを共有することを許可しない少なくとも1つのPodSecurityPolicy（PSP）が定義されている必要があります。

hostPIDを必要とするコンテナを実行する必要がある場合、これは別のPSPで定義されるべきであり、RBAC制御を慎重に確認して、限られたサービスアカウントとユーザーのみがそのPSPにアクセスする権限を与えられるようにするべきです。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行して、設定ファイルで制限レベルが有効になっていることを確認してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加し、特権コンテナの受け入れを制限します。

5.2.3

ホストのプロセスIDネームスペースを共有したいコンテナの受け入れを最小限に抑える（自動化）

理由

コンテナがホストのPIDネームスペースを共有することを許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。

ホストPIDを必要とするコンテナを実行する必要がある場合は、これを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加し、特権コンテナの受け入れを制限します。

5.2.4

ホストIPCネームスペースを共有したいコンテナの受け入れを最小限に抑える（自動化）

理由

ホストのIPCネームスペースで実行されているコンテナは、コンテナの外部のプロセスとIPCを使用して相互作用することができます。

コンテナがホストのIPCネームスペースを共有することを許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。

ホストIPCを必要とするコンテナを実行する必要がある場合は、これを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加し、特権コンテナの受け入れを制限します。

5.2.5

ホストのネットワークネームスペースを共有したいコンテナの受け入れを最小限に抑える（自動化）

理由

ホストのネットワークネームスペースで実行されているコンテナは、ローカルループバックデバイスにアクセスでき、他のポッドとの間のネットワークトラフィックにアクセスできる可能性があります。

コンテナがホストのネットワークネームスペースを共有することを許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。

ホストのネットワークネームスペースにアクセスする必要があるコンテナを実行する場合は、これを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加して、ホストネットワークコンテナの受け入れを制限してください。

5.2.6

`allowPrivilegeEscalation`を持つコンテナの受け入れを最小限に抑える（自動化）

理由

allowPrivilegeEscalationフラグがtrueに設定されたコンテナは、親プロセスよりも多くの権限を得るプロセスを持つ可能性があります。

特権昇格を許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。setuidバイナリの実行を許可するオプションが存在し、デフォルトはtrueに設定されています。

setuidバイナリを使用するコンテナや特権昇格を必要とするコンテナを実行する必要がある場合は、これを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加して、.spec.allowPrivilegeEscalationがtrueに設定されたコンテナの受け入れを制限してください。

5.2.7

ルートコンテナの受け入れを最小限に抑える（自動化）

理由

コンテナは任意のLinuxユーザーとして実行できます。ルートユーザとして実行されるコンテナは、コンテナランタイムのセキュリティ機能によって制約されていても、コンテナのブレイクアウトの可能性が高まります。

理想的には、すべてのコンテナは定義された非UID 0ユーザーとして実行されるべきです。

ルートコンテナを許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。

ルートコンテナを実行する必要がある場合は、それを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: クラスター内の各ネームスペースにポリシーを作成し、MustRunAsNonRoot または MustRunAs がUIDの範囲に0を含まないように設定されていることを確認します。

5.2.8

NET_RAWケイパビリティを持つコンテナの受け入れを最小限に抑える（自動化）。

理由

コンテナは、コンテナランタイムによって割り当てられたデフォルトの機能セットで実行されます。デフォルトでは、これは潜在的に危険なケイパビリティを含む可能性があります。Dockerをコンテナランタイムとして使用する場合、NET_RAWケイパビリティが有効になっており、悪意のあるコンテナによって悪用される可能性があります。

理想的には、すべてのコンテナはこのケイパビリティを削除するべきです。

NET_RAWケイパビリティを持つコンテナを許可しない少なくとも1つの受け入れ制御ポリシーを定義する必要があります。

このケイパビリティを持つコンテナを実行する必要がある場合は、それを別のポリシーで定義し、限られたサービスアカウントとユーザーのみがそのポリシーを使用する権限を与えられるように注意深く確認する必要があります。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

config_file=$(ps aux | grep kube-apiserver |  grep -- --admission-control-config-file | sed 's%.*admission-control-config-file[= ]\([^ ]*\).*%\1%')

grep "enforce:" ${config_file}

返された値が`enforce: restricted`であることを確認してください。

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加し、NET_RAW 機能を持つコンテナの受け入れを制限します。

5.2.9

追加されたケイパビリティを持つコンテナの受け入れを最小限に抑える（自動化）。

理由

コンテナは、コンテナランタイムによって割り当てられたデフォルトの機能セットで実行されます。このセット外のケイパビリティはコンテナに追加される可能性があり、コンテナのブレイクアウト攻撃のリスクにさらされる可能性があります。

デフォルトのセットを超えるケイパビリティを持つコンテナの起動を防ぐために、少なくとも1つのポリシーを定義する必要があります。

追加の機能を持つコンテナを実行する必要がある場合、これは別のポリシーで定義されるべきであり、そのポリシーを使用する権限が与えられるのは限られたサービスアカウントとユーザのみであることを慎重に確認する必要があります。

*結果:*手動

是正措置: allowedCapabilities が空の配列に設定されていない限り、クラスターのポリシーに存在しないことを確認します。

5.2.10

割り当てられた機能を持つコンテナの受け入れを最小限に抑える（手動）。

理由

コンテナは、コンテナランタイムによって割り当てられたデフォルトの機能セットで実行されます。機能は、Linuxシステムで一般的にルートユーザに付与される権利の一部です。

多くの場合、コンテナ内で実行されるアプリケーションは動作するために機能を必要としないため、最小権限の原則の観点から機能の使用は最小限に抑えるべきです。

*結果:*手動

是正措置: クラスターで実行されているアプリケーションの機能の使用を確認します。Linuxの機能を必要としないアプリケーションを含むネームスペースでは、すべての機能を削除しないコンテナの受け入れを禁止するPSPを追加することを検討してください。

5.2.11

Windows HostProcessコンテナの受け入れを最小限に抑える（手動）。

理由

*結果:*手動

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加し、.securityContext.windowsOptions.hostProcess が true に設定されているコンテナの受け入れを制限します。

5.2.12

HostPathボリュームの受け入れを最小限に抑える（手動）。

理由

ホストパスボリュームを仕様の一部としてマウントするコンテナは、基盤となるクラスターのノードのファイルシステムにアクセスできます。hostPathボリュームの使用により、コンテナがノードのファイルシステムの特権エリアにアクセスできる可能性があります。

hostPathボリュームをマウントすることを許可しない少なくとも1つの受け入れ制御ポリシーが定義されているべきです。

hostPathボリュームを必要とするコンテナを実行する必要がある場合、これは別のポリシーで定義されるべきであり、そのポリシーを使用する権限が与えられるのは限られたサービスアカウントとユーザのみであることを慎重に確認する必要があります。

*結果:*手動

是正措置: ユーザーのワークロードを持つクラスター内の各ネームスペースにポリシーを追加して、hostPath ボリュームを持つコンテナの受け入れを制限します。

5.2.13

HostPortsを使用するコンテナの受け入れを最小限に抑える（手動）。

理由

ホストポートは、コンテナをホストのネットワークに直接接続します。これにより、ネットワークポリシーなどの制御をバイパスすることができます。

HostPortsの使用を必要とするコンテナを許可しない少なくとも1つの受け入れ制御ポリシーが定義されているべきです。

HostPortsを必要とするコンテナを実行する必要がある場合、これは別のポリシーで定義されるべきであり、そのポリシーを使用する権限が与えられるのは限られたサービスアカウントとユーザのみであることを慎重に確認する必要があります。

*結果:*手動

是正措置: ユーザーのワークロードがあるクラスター内の各ネームスペースにポリシーを追加し、`hostPort`セクションを使用するコンテナの受け入れを制限します。

5.3 ネットワークポリシーとCNI

5.3.1

使用中のCNIがネットワークポリシーをサポートしていることを確認してください（自動）。

理由

Kubernetesのネットワークポリシーは、使用中のCNIプラグインによって適用されます。そのため、CNIプラグインがIngressおよびEgressネットワークポリシーの両方をサポートしていることを確認することが重要です。

*結果:*パス

Audit（監査）: クラスターで使用されているCNIプラグインのドキュメントを確認し、IngressおよびEgressネットワークポリシーをサポートしているかどうかを確かめてください。

是正措置: デフォルトでは、RKE2はCanal（CalicoとFlannel）を使用し、ネットワークポリシーを完全にサポートしています。

5.3.2

すべてのネームスペースにネットワークポリシーが定義されていることを確認してください（自動）。

理由

同じKubernetesクラスターで異なるアプリケーションを実行すると、侵害されたアプリケーションの1つが隣接するアプリケーションを攻撃するリスクが生じます。ネットワークセグメンテーションは、コンテナが本来通信すべき相手とだけ通信できるようにすることが重要です。ネットワークポリシーは、ポッドの選択が互いに、また他のネットワークエンドポイントとどのように通信できるかを規定する仕様です。

ネットワークポリシーはネームスペース単位で適用されます。特定のネームスペースにネットワークポリシーが導入されると、そのポリシーによって許可されていないすべてのトラフィックは拒否されます。ただし、ネームスペースにネットワークポリシーがない場合、そのネームスペース内のポッドへのおよびポッドからのすべてのトラフィックが許可されます。

*結果:*パス

Audit（監査）: マスターノードで以下のコマンドを実行してください。

for i in kube-system kube-public default; do
    /var/lib/rancher/rke2/bin/kubectl get networkpolicies -n $i;
done

各ネームスペースに適用されているネットワークポリシーを確認してください。

是正措置: RKE2は、`--profile=cis-1.23`引数を使用して実行されると、ネームスペース内トラフィックとkube-systemへのDNSのみを許可する安全なネットワークポリシーを適用します。手動での修正は必要ありません。

5.4 シークレット管理

5.4.1

シークレットを環境変数としてではなく、ファイルとして使用することを優先してください（手動）。

理由

アプリケーションコードがその環境をログに出力することは、特にエラーが発生した場合に比較的一般的です。これには、環境変数として渡されたシークレット値が含まれるため、シークレットはログにアクセスできるユーザーやエンティティに簡単に露出する可能性があります。

*結果:*手動

Audit（監査）: 以下のコマンドを実行して、シークレットから定義された環境変数を使用するオブジェクトへの参照を見つけてください。

/var/lib/rancher/rke2/bin/kubectl get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.name} {"\n"}{end}' -A

是正措置: 可能であれば、アプリケーションコードを書き直して、環境変数ではなくマウントされたシークレットファイルからシークレットを読み取るようにしてください。

5.4.2

外部シークレットストレージを検討してください（手動）。

理由

Kubernetesはシークレットをファーストクラスのオブジェクトとしてサポートしていますが、シークレットへのアクセスが慎重に制限されるように注意が必要です。外部シークレットプロバイダーを使用することで、Kubernetesと非Kubernetes環境の両方でシークレットが使用される場合のアクセス管理が容易になります。

*結果:*手動

Audit（監査）: シークレット管理の実装を確認してください。

是正措置: クラウドプロバイダーまたはサードパーティのシークレット管理ソリューションが提供するシークレット管理オプションを参照してください。

5.5 拡張可能な受け入れ制御

5.5.1

ImagePolicyWebhookアドミッションコントローラーを使用してイメージの来歴を構成してください（手動）。

理由

Kubernetesは、デプロイメント内のイメージを受け入れるか拒否するための来歴ルールをプラグインすることをサポートしています。承認されたイメージのみがクラスターにデプロイされるように、そのようなルールを構成することができます。

*結果:*手動

Audit（監査）: クラスター内のPod定義を確認し、イメージの来歴が適切に構成されていることを確認してください。

是正措置: Kubernetesのドキュメントに従って、イメージの来歴をセットアップしてください。

5.6 省略

v1.23 ガイドは5.6をスキップし、5.5から5.7に進みます。ここに説明のために含めています。

5.7 一般ポリシー

これらのポリシーは、ネームスペースのベストプラクティスやクラスター内のPodオブジェクトに適用されるポリシーなど、一般的なクラスター管理のトピックに関連しています。

5.7.1

ネームスペースを使用してリソース間に管理境界を作成してください（手動）。

理由

ユーザー権限の範囲を制限することで、ミスや悪意のある活動の影響を軽減できます。Kubernetesのネームスペースを使用すると、作成されたリソースを論理的に名前付けされたグループに分割できます。1つのネームスペースで作成されたリソースは、他のネームスペースから隠すことができます。デフォルトでは、Kubernetesクラスター内でユーザーによって作成された各リソースは、defaultと呼ばれるデフォルトのネームスペースで実行されます。追加のネームスペースを作成し、それにリソースやユーザーを割り当てることができます。Kubernetesの認可プラグインを使用して、異なるユーザー間でネームスペースリソースへのアクセスを分離するポリシーを作成できます。

*結果:*手動

Audit（監査）: 以下のコマンドを実行し、クラスター内に作成されたネームスペースを確認してください。

/var/lib/rancher/rke2/bin/kubectl get namespaces

これらのネームスペースが必要なものであり、要件に応じて適切に管理されていることを確認してください。

是正措置: ドキュメントに従って、必要に応じてデプロイメント内のオブジェクトのためにネームスペースを作成してください。

5.7.2

Pod定義でseccompプロファイルが`docker/default`に設定されていることを確認してください（手動）。

理由

Seccomp（セキュアコンピューティングモード）は、アプリケーションが行えるシステムコールのセットを制限するために使用され、クラスター管理者にクラスター内で実行されるワークロードのセキュリティに対するより大きな制御を提供します。Kubernetesは、歴史的な理由からデフォルトでseccompプロファイルを無効にしています。ワークロードがコンテナ内で制限されたアクションを持つことを確実にするために、それを有効にするべきです。

*結果:*手動

Audit（監査）: クラスター内のポッド定義を確認してください。以下のような行を作成する必要があります。

annotations:
  seccomp.security.alpha.kubernetes.io/pod: docker/default

是正措置: Kubernetesのドキュメントを確認し、必要に応じて関連するPodSecurityPolicyを適用してください。

5.7.3

ポッドとコンテナにセキュリティコンテキストを適用する（マニュアル）。

理由

セキュリティコンテキストは、コンテナに適用されるオペレーティングシステムのセキュリティ設定（uid、gid、capabilities、SELinuxロールなど）を定義します。コンテナとポッドを設計する際には、ポッド、コンテナ、およびボリュームのセキュリティコンテキストを構成することを確認してください。セキュリティコンテキストは、デプロイメントのyamlで定義されるプロパティです。それは、ポッド/コンテナ/ボリュームに割り当てられるセキュリティパラメータを制御します。セキュリティコンテキストには、ポッドレベルのセキュリティコンテキストとコンテナレベルのセキュリティコンテキストの2つのレベルがあります。

*結果:*手動

Audit（監査）: クラスター内のポッド定義を確認し、適切にセキュリティコンテキストが定義されていることを確認してください。

是正措置: Kubernetesのドキュメントに従い、ポッドにセキュリティコンテキストを適用してください。推奨されるセキュリティコンテキストのリストについては、CISセキュリティベンチマークを参照してください。

5.7.4

デフォルトのネームスペースは使用しないべきです（マニュアル）。

理由

Kubernetesクラスター内のリソースは、ネームスペースによって分離されるべきであり、そのレベルでセキュリティコントロールを適用できるようにし、リソースの管理を容易にします。

*結果:*手動

Audit（監査）: マスターノードで以下のコマンドを実行してください。

/var/lib/rancher/rke2/bin/kubectl get all -n default

デフォルトのネームスペースに適用されているリソースがないことを確認してください。

是正措置: デフォルトでは、RKE2はデフォルトのネームスペースを利用しません。