ポッドのセキュリティコンテキスト

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 ドキュメントを参照してください。Kubernetes 非推奨ポリシーによると、古いバージョンでは、この機能が非推奨になってから 9 か月後にサポートされなくなります。

一方、推奨されるセキュリティアプローチであり、通常はセキュリティコンテキストを使用して実装されるポッドセキュリティ標準 (PSS) は、ポッドマニフェストのポッドとコンテナの仕様の一部として定義されます。PSS は、Kubernetes プロジェクトチームがポッドのセキュリティ関連のベストプラクティスに対処するために定義した公式標準です。ベースライン (最小制限、デフォルト）、特権 (無制限）、制限 (最も制限的) などのポリシーを定義します。

ベースラインプロファイルから開始することをお勧めします。PSS ベースラインプロファイルは、セキュリティと潜在的な摩擦の強固なバランスを提供し、例外のリストを最小限に抑え、ワークロードセキュリティの良い出発点として機能します。現在 PSPs、PSS に切り替えることをお勧めします。PSS ポリシーの詳細については、Kubernetes ドキュメントを参照してください。これらのポリシーは、OPA や Kyverno のものを含む複数のツールで適用できます。たとえば、Kyverno はここで PSS ポリシーの完全なコレクションを提供します。

セキュリティコンテキスト設定を使用すると、プロセスを選択する権限を付与したり、プログラムプロファイルを使用して個々のプログラムに機能を制限したり、権限のエスカレーションを許可したり、システムコールをフィルタリングしたりできます。

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 つのことを行う必要があります。