CISハードニングガイド

この文書は、SUSE® Rancher Prime: RKE2 の本番インストールをハードニングするための具体的なガイダンスを提供します。これは、インターネットセキュリティセンター（CIS）からのKubernetesベンチマークコントロールに対処するために必要な構成と制御を概説しています。

ハードニングされたクラスターを公式のCISベンチマークに対して評価する詳細については、適切なCIS自己評価ガイドを参照してください：

RKE2はデフォルトでハードニングされており、ほとんどのKubernetes CIS制御を変更せずにクリアできます。しかし、この中にはCISベンチマークに完全に合格するために、手動での介入が必要な例外がいくつか存在します：

  1. RKE2はホストオペレーティングシステムを変更しません。したがって、オペレーターであるあなたは、いくつかのホストレベルの変更を行う必要があります。

  2. ネットワークポリシーおよびポッドセキュリティ基準（RKE2 v1.25以前ではポッドセキュリティポリシー）に関する一部のCIS制御は、クラスターの機能を制限します。これらの設定をRKE2に自動で行わせるには、オプトインする必要があります。これらの要件が満たされることを保証するために、RKE2はそのバージョンに応じて`profile`フラグを`cis`または`cis-1.23`に設定して起動することができます。

本ガイドは、RKE2がインストール済みであるが、まだ起動していないことを前提としています。すでにRKE2を起動している場合は、RKE2サービスを停止する必要があります。

ホストレベルの要件

ホストレベルの要件は、カーネルパラメータ、kubeletのprotect-kernel-defaults、及びetcdプロセス／ディレクトリの設定という3つの領域に分かれます。これらはこのセクションで概説されています。

カーネルパラメータ

CISベンチマークでは、一部の特定のカーネルパラメータ設定が求められます。RKE2のインストール時に、必要なパラメータを適切に設定するためのsysctl設定ファイルが作成されます。しかし、この構成をホストに自動的に適用することはありません。これを手動で行う必要があります。設定ファイルの場所は、使用されるインストール方法によって異なります。

RKE2がRPM、YUM、またはDNFを介してインストールされた場合（CentOSなどのRPMを使用するOSのデフォルト）、次のコマンドを実行してください：

sudo cp -f /usr/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

RKE2がtarballを介してインストールされた場合（RPMを使用しないOSのデフォルトであるUbuntuなど）、次のコマンドを実行してください：

sudo cp -f /usr/local/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

システムに`systemd-sysctl.service`および/または`/etc/sysctl.d`ディレクトリがない場合、起動時にsysctlが適用されることを確認するために、起動中に次のコマンドを実行する必要があります：

sudo sysctl -p /usr/local/share/rke2/rke2-cis-sysctl.conf

このステップは、RKE2を使用してKubernetesをデプロイする前の新しいインストールにのみ実行してください。CNIプラグインを含む多くのKubernetesコンポーネントは、自分自身のsysctlを設定します。実行中のKubernetesクラスターで`systemd-sysctl`サービスを再起動すると、予期しない副作用が発生する可能性があります。

Kubeletパラメータ`protect-kernel-defaults`は`true`に設定されています。

これは、必要なカーネルパラメータが未設定またはkubeletのデフォルトと異なる値に設定されている場合、kubeletが終了する原因となるkubeletフラグです。

RKE2は、`profile`フラグが設定されているときにフラグを`true`に自動的に設定します。

`protect-kernel-defaults`はRKE2のトップレベルフラグとして公開されています。`profile`を`cis-1.XX`に、`protect-kernel-defaults`を`false`に明示的に設定した場合、RKE2はエラーで終了します。

RKE2は、kubeletが行うのと同じカーネルパラメータもチェックし、kubeletと同じルールに従ってエラーで終了します。これは、オペレーターがkubeletのデフォルトを違反しているカーネルパラメータをより迅速かつ簡単に特定できるようにするための便宜として行われます。

etcdは適切に構成されています。

CISベンチマークでは、etcdデータディレクトリが`etcd`ユーザーおよびグループに所有されることが要求されます。これは、etcdプロセスがホストレベルの`etcd`ユーザーとして実行されることを暗黙的に要求します。これを達成するために、RKE2は有効な`cis`または`cis-1.XX`プロファイルで起動されたときにいくつかのステップを踏みます：

  1. ホストに`etcd`ユーザーおよびグループが存在することを確認してください。存在しない場合は、エラーで終了します。

  2. `etcd`をユーザーおよびグループの所有者としてetcdのデータディレクトリを作成します。

  3. etcd静的ポッドの`SecurityContext`を適切に設定することで、etcdプロセスが`etcd`ユーザーおよびグループとして実行されることを確認します。

一部のLinux配布パッケージでは、useradd`コマンドはグループを作成しません。それに対応するために、-U`フラグが以下に含まれています。このフラグは、`useradd`にユーザーと同じ名前のグループを作成するよう指示します。

sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U

`etcd`ユーザーおよびグループは、/etc/passwdおよび/etc/groupの伝統的なデータベースファイルに定義されている必要があります。Golangのstdlib `os/user`パッケージは、NSSやsystemdユーザーデータベース（varlink）などの外部ユーザーデータベースをサポートしていません。

RKE2設定

  • v1.29以降

  • v1.25 - v1.28

  • v1.24以前

profile: "cis"
# For cis-1.11 only, not needed on cis-1.9/cis-1.10
kube-apiserver-arg:
  - 'service-account-extend-token-expiration=false'

一般的なCIS設定

profile: "cis"

一般的な`cis`プロファイルを使用することで、クラスターがRKE2が実行しているKubernetesバージョンに関連するCISベンチマーク（rke2-cis-1.XX-profile-hardened）を通過することが保証されます。例えば、RKE2 v1.26.XXは`profile: cis`を使用すると、Rancherで`rke2-cis-1.8-profile-hardened`を通過します。

一般的な`cis`プロファイルの使用により、RKE2へのアップグレードに既存の設定の変更が必要ないことが保証されます。適用可能なCISベンチマークを通過するために必要な変更は自動的に適用されます。

RKE2バージョンとCISベンチマークバージョンの大まかなマッピングは以下の通りです：

RKE2マイナー

適用可能なCISベンチマーク

プロファイルフラグ

1.27-1.28

1.9

cis

1.26

1.8

cis-1.23、cis

1.25

1.7

cis-1.23、cis

1.24

1.24

cis-1.23

1.23

1.23

cis-1.23

1.19-1.22

1.6

cis-1.6

 
profile: "cis-1.23"

設定ファイルは`config.yaml`という名前にして、`/etc/rancher/rke2`に配置する必要があります。ディレクトリはRKE2をインストールする前に作成する必要があります。

`profile`フラグが設定されている場合、次のことを行います：

  • v1.25以降

  • v1.24以前

  1. ホストレベルの要件が満たされていることを確認します。満たされていない場合、RKE2は満たされていない要件を説明する致命的なエラーで終了します。

  2. etcdハードニングガイドで説明されているように、etcdユーザーおよびグループとして実行するようにetcd静的ポッドを構成します。

  3. 関連する制御を通過させるためのネットワークポリシーを適用します。

  4. エージェントマニフェストおよびその他の設定ファイルに対して、より制限されたファイル権限（600対644）を適用します。

  5. kube-system、cis-operator-system、および`tigera-operator`の名前空間を除いて、すべての名前空間で制限モードを強制するようにPod Security Admission Controllerを構成します。これらの名前空間は、システムポッドが制限なしで実行できるように免除されており、クラスターの適切な動作に必要です。PSA構成に関する詳細については、デフォルトのPod Security Admission構成を参照してください。Pod Security Standardsに関する詳細については、 公式ドキュメントを参照してください。

  1. ホストレベルの要件が満たされていることを確認します。満たされていない場合、RKE2は満たされていない要件を説明する致命的なエラーで終了します。

  2. 関連する制御を通過させるためのネットワークポリシーを適用します。

  3. クラスターが関連する制御を通過できるようにするランタイムのポッドセキュリティポリシーを構成します。

Kubernetesランタイム要件

CISベンチマークを通過するためのランタイム要件は、ポッドセキュリティとネットワークポリシーに中心を置いています。これらのほとんどは、有効な`cis-1.XX`プロファイルを使用する際にRKE2によって自動的に処理されますが、追加のオペレーターの介入が必要です。

ポッドセキュリティ

RKE2は常にある程度のポッドセキュリティで実行されます。

  • v1.25以降

  • v1.24以前

v1.25以降では、 Pod Security Admission (PSA)がポッドセキュリティに使用されます。デフォルトのPod Security Admission設定ファイルは、次のようにクラスターの起動時に追加されます：

cis/`cis-1.23`プロファイルを使用すると：

  • RKE2は、クラスター全体で`restricted`モードを強制する設定ファイルを介して制限されたポッドセキュリティ基準を適用し、システムポッドの正常な動作を確保するために`kube-system`、cis-operator-system、および`tigera-operator`のネームスペースに例外を設けます。

cis/cis-1.23 プロファイルなしで：

  • RKE2 は、クラスター全体で privileged モードを強制する設定ファイルを介して、制限のないポッドセキュリティ標準を適用します。これにより、クラスター内のすべてのポッドに対して完全に制限のないモードが許可されます。詳細については、ポッドセキュリティポリシー ページをご覧ください。

v1.24 およびそれ以前のバージョンでは、PodSecurityPolicy アドミッションコントローラーは常に有効です。ポリシーは、RKE2 に渡されたプロファイルに基づいて適用されます。

`cis-1.6`プロファイルを使用すると：

  • RKE2 は、はるかに制限の厳しいポリシーセットを適用します。これらのポリシーは、CIS ベンチマークのセクション 5.2 に記載された要件を満たしています。

cis-1.6 プロファイルなしで：

  • RKE2 は、PodSecurityPolicy アドミッションコントローラーが有効でないかのように Kubernetes を実行できる制限のないポリシーを適用します。詳細については、ポッドセキュリティポリシー ページをご覧ください。

Kubernetes コントロールプレーンコンポーネントおよび CNI、DNS、Ingress などの重要な追加機能は、kube-system ネームスペース内でポッドとして実行されます。したがって、この名前空間には、これらのコンポーネントが適切に実行できるように、制限の少ないポリシーがあります。

ネットワークポリシー

有効な "cis-1.XX" プロファイルで実行されると、RKE2 は Kubernetes のビルトインネームスペースに対して CIS ベンチマークを通過する NetworkPolicies を適用します。これらのネームスペースは、kube-system、kube-public、および default です。

使用される NetworkPolicy は、同じネームスペース内のポッド同士が通信することのみを許可します。ただし、いくつかの注目すべき例外があり、DNS リクエストが解決されることが許可されています。

  • DNS リクエストは、DNS サーバーに到達することが許可されています。

  • HTTP/s リクエストは、ingress-nginx サービスに到達することが許可されています。

  • HTTPs リクエストは、metrics-server に到達することが許可されています。

  • ingress-nginx ポッドによって指定されたポッドの ingress-nginx ウェブフックへのリクエスト（通常は 8443）

  • rke2-snapshot-validation-webhook への HTTPs リクエスト

オペレーターの介入が必要です。

オペレーターは、作成された追加の名前空間に対してネットワークポリシーを通常通り管理する必要があります。

default サービスアカウントを設定します。

automountServiceAccountToken サービスアカウントのために false を default に設定します。

Kubernetes は、ポッドに特定のサービスアカウントが割り当てられていないクラスターのワークロードによって使用される default サービスアカウントを提供します。ポッドから Kubernetes API へのアクセスが必要な場合、そのポッドのために特定のサービスアカウントを作成し、そのサービスアカウントに権限を付与する必要があります。default サービスアカウントは、サービスアカウントトークンを提供せず、明示的な権限の割り当てを持たないように構成する必要があります。

標準の RKE2 インストールにおいて、default と kube-system を含む各ネームスペースに対して、default サービスアカウントはこの値を含む必要があります：

automountServiceAccountToken: false

RKE2 は、kube-system、cis-operator-system、kube-node-lease、および tigera-operator ネームスペースの値を自動的に正しく設定します。

オペレーターの介入が必要です。

クラスターオペレーターによって作成されたネームスペースのために、default サービスアカウントを構成するために次のスクリプトと環境設定ファイルを使用できます。

以下の設定は、account_update.yaml という名前のファイルに保存する必要があります。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
automountServiceAccountToken: false

account_update.sh という名前の bash スクリプトファイルを作成します。スクリプトに実行権限を与えるために、必ず sudo chmod +x account_update.sh を実行してください。

#!/bin/bash -e

for namespace in $(kubectl get namespaces -A -o=jsonpath="{.items[*]['metadata.name']}"); do
  echo -n "Patching namespace $namespace - "
  kubectl patch serviceaccount default -n ${namespace} -p "$(cat account_update.yaml)"
done

このスクリプトを実行して、すべてのネームスペースの default サービスアカウントに account_update.yaml 設定を適用します。

APIサーバー監査構成

CIS要件1.2.22から1.2.25は、APIサーバーの監査ログを構成することに関連しています。RKE2 が profile フラグを設定して起動されると、CIS チェックを通過させるために API サーバー内の強化された --audit-log- パラメータが自動的に構成されます。

RKE2 のデフォルトの監査ポリシーは、API サーバーでのリクエストをログに記録しないように構成されています。これは、クラスターオペレーターが監査要件やニーズに合った監査ポリシーをカスタマイズする柔軟性を持つことを許可するために行われます。これらは各ユーザーの環境やポリシーに特有のものです。

デフォルトの監査ポリシーは、profile フラグを設定して起動されたときに RKE2 によって作成されます。ポリシーは /etc/rancher/rke2/audit-policy.yaml に定義されています。

apiVersion: audit.k8s.io/v1
kind: Policy
metadata:
  creationTimestamp: null
rules:
- level: None
オペレーターの介入が必要です。

API サーバーへのリクエストのログを開始するには、少なくとも level パラメータを変更する必要があります。例えば、Metadata に変更します。APIサーバーのポリシー設定に関する詳細情報は、Kubernetesの ドキュメントで確認できます。

監査ポリシーを適用した後、RKE2 を再起動して新しい設定を読み込む必要があります。

sudo systemctl restart rke2-server.service

API サーバーの監査ログは /var/lib/rancher/rke2/server/logs/audit.log に書き込まれます。

当バージョンの注意事項

以下は、デフォルトの RKE2 が現在合格していないコントロールです。各ギャップについて説明し、どのように対処されるかを示します。

コントロール 1.1.12

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

理由

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

補修

これは、上記に記載されているように、etcd ユーザーとグループを作成することで修正できます。

コントロール 5.1.5

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

理由

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

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

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

これは、各ネームスペースの default サービスアカウントの automountServiceAccountToken フィールドを false に更新することで修正できます。

結論

このガイドに従っていれば、あなたのRKE2クラスターはCIS Kubernetesベンチマークに合格するように構成されます。私たちのCIS自己評価ガイドを確認することで、各ベンチマークをどのように検証したか、そしてあなたのクラスターで同じことをどのように行うかを理解できます。