翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ポッドのセキュリティコンテキスト
Pod Security Policies (PSP) と Pod Security Standards (PSS) は、Kubernetes でセキュリティを適用する主な 2 つの方法です。PodSecurityPolicy は Kubernetes v1.21 で廃止され、v1.25 で削除され、Pod Security Standard (PSS) は今後セキュリティを適用するために Kubernetes が推奨するアプローチであることに注意してください。
ポッドセキュリティポリシー (PSP) は、セキュリティポリシーを実装するための Kubernetes のネイティブソリューションです。PSP は、Pod 仕様のセキュリティに敏感な側面を制御するクラスターレベルのリソースです。ポッドセキュリティポリシーを使用すると、クラスターがポッドを受け入れるために満たす必要がある一連の条件を定義できます。PSP 機能は Kubernetes の初期から利用可能であり、誤って設定されたポッドが特定のクラスターに作成されないように設計されています。
Pod セキュリティポリシーの詳細については、Kubernetes ドキュメント
一方、推奨されるセキュリティアプローチであり、通常はセキュリティコンテキストを使用して実装されるポッドセキュリティ標準 (PSS) は、ポッドマニフェストのポッドとコンテナの仕様の一部として定義されます。PSS は、Kubernetes プロジェクトチームがポッドのセキュリティ関連のベストプラクティスに対処するために定義した公式標準です。ベースライン (最小制限、デフォルト)、特権 (無制限)、制限 (最も制限的) などのポリシーを定義します。
ベースラインプロファイルから開始することをお勧めします。PSS ベースラインプロファイルは、セキュリティと潜在的な摩擦の強固なバランスを提供し、例外のリストを最小限に抑え、ワークロードセキュリティの良い出発点として機能します。現在 PSPs、PSS に切り替えることをお勧めします。PSS ポリシーの詳細については、Kubernetes ドキュメント
セキュリティコンテキスト設定を使用すると、プロセスを選択する権限を付与したり、プログラムプロファイルを使用して個々のプログラムに機能を制限したり、権限のエスカレーションを許可したり、システムコールをフィルタリングしたりできます。
Kubernetes の Windows ポッドには、セキュリティコンテキストに関して、標準の Linux ベースのワークロードといくつかの制限と差別化要因があります。
Windows は、システム名前空間フィルターを使用してコンテナごとにジョブオブジェクトを使用し、コンテナ内のすべてのプロセスを含み、ホストから論理的に分離します。名前空間フィルタリングが設定されていない Windows コンテナを実行する方法はありません。つまり、ホストのコンテキストでシステム権限をアサートできないため、特権コンテナは Windows では使用できません。
以下にwindowsOptions
示しているのは、文書化された Windows セキュリティコンテキストオプション
Windows と Linux でサポートされているセキュリティコンテキスト属性のリストについては、こちらの
Pod 固有の設定は、すべてのコンテナに適用されます。指定しない場合、PodSecurityContext のオプションが使用されます。SecurityContext と PodSecurityContext の両方で設定されている場合、SecurityContext で指定された値が優先されます。
例えば、Windows オプションであるポッドとコンテナの runAsUserName 設定は、Linux 固有の runAsUser 設定とほぼ同等であり、次のマニフェストでは、ポッド固有のセキュリティコンテキストがすべてのコンテナに適用されます。
apiVersion: v1 kind: Pod metadata: name: run-as-username-pod-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo nodeSelector: kubernetes.io/os: windows
一方、以下では、コンテナレベルのセキュリティコンテキストはポッドレベルのセキュリティコンテキストを上書きします。
apiVersion: v1 kind: Pod metadata: name: run-as-username-container-demo spec: securityContext: windowsOptions: runAsUserName: "ContainerUser" containers: - name: run-as-username-demo .. securityContext: windowsOptions: runAsUserName: "ContainerAdministrator" nodeSelector: kubernetes.io/os: windows
runAsUserName フィールドの許容値の例: ContainerAdministrator、ContainerUser、NT AUTHORITY\NETWORK SERVICE、NT AUTHORITY\LOCAL SERVICE
ContainerUser for Windows ポッドを使用してコンテナを実行することをお勧めします。ユーザーはコンテナとホスト間で共有されませんが、ContainerAdministrator にはコンテナ内の に対する追加の権限があります。注意すべきユーザー名の制限
ContainerAdministrator を使用するときの良い例は、PATH を設定することです。USER ディレクティブを使用すると、次のようなことができます。
USER ContainerAdministrator RUN setx /M PATH "%PATH%;C:/your/path" USER ContainerUser
また、シークレットはノードのボリュームにクリアテキストで書き込まれます (linux の tmpfs/in-memory と比較して)。つまり、2 つのことを行う必要があります。
-
ファイル ACLs を使用してシークレットファイルの場所を保護する
-
BitLocker
を使用したボリュームレベルの暗号化の使用