ポッドのセキュリティ

ポッド仕様には、全体的なセキュリティ体制を強化または弱める可能性のあるさまざまな属性が含まれています。Kubernetes の実務者として、コンテナで実行されているプロセスがコンテナランタイムの分離境界からエスケープし、基盤となるホストにアクセスできないようにすることが主な懸念事項です。

Linux の機能

コンテナ内で実行されるプロセスは、デフォルトで [Linux] ルートユーザーのコンテキストで実行されます。コンテナ内のルートのアクションは、コンテナランタイムがコンテナに割り当てる一連の Linux 機能によって部分的に制約されますが、これらのデフォルトの権限により、攻撃者は権限をエスカレートしたり、Secrets や ConfigMaps などのホストにバインドされた機密情報にアクセスしたりすることができます。以下は、コンテナに割り当てられたデフォルトの機能のリストです。各機能の詳細については、http://man7.org/linux/man-pages/man7/capabilities.7.html を参照してください。

CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETUID, CAP_SETFCAP, CAP_SETPCAP, CAP_SYS_CHROOT

EC2 ポッドと Fargate ポッドには、デフォルトで前述の機能が割り当てられます。さらに、Linux 機能は Fargate ポッドからのみ削除できます。

特権として実行されるポッドは、ホスト上のルートに関連付けられたすべての Linux 機能を継承します。これは、可能であれば避けてください。

ノード認可

すべての Kubernetes ワーカーノードは、ノード認可と呼ばれる認可モードを使用します。Node Authorization は、kubelet から送信されるすべての API リクエストを承認し、ノードが次のアクションを実行できるようにします。

読み取りオペレーション：

• サービス

• エンドポイント

• ノード

• ポッド

• kubelet のノードにバインドされたポッドに関連するシークレット、設定マップ、永続ボリュームクレーム、永続ボリューム

書き込みオペレーション：

• ノードとノードステータス (アドNodeRestrictionミッションプラグインを有効にして kubelet を制限し、独自のノードを変更）

• ポッドとポッドステータス (アドNodeRestrictionミッションプラグインを有効にして kubelet を制限し、それ自体にバインドされたポッドを変更）

• events

認証関連のオペレーション：

• TLS ブートストラップ用の CertificateSigningRequest (CSR) API への読み取り/書き込みアクセス

• 委任認証/認可チェック用の TokenReview と SubjectAccessReview を作成する機能

EKS はノード制限アドミッションコントローラーを使用します。これにより、ノードはノードにバインドされているノード属性とポッドオブジェクトの限定されたセットのみ変更できます。それでも、ホストへのアクセスを管理する攻撃者は、Kubernetes API から環境に関する機密情報を収集できるため、クラスター内で横方向に移動できます。

ポッドセキュリティソリューション

ポッドセキュリティポリシー (PSP)

以前は、ポッドセキュリティポリシー (PSP) リソースを使用して、ポッドを作成する前に満たす必要がある一連の要件を指定していました。Kubernetes バージョン 1.21 以降、PSP は廃止されました。これらは Kubernetes バージョン 1.25 で削除される予定です。

重要

PSPs は Kubernetes バージョン 1.21 では廃止されました。バージョン 1.25 まで、または別の に移行するには約 2 年かかります。このドキュメントでは、この廃止の動機について説明します。

新しいポッドセキュリティソリューションへの移行

PSPs は Kubernetes v1.25 の時点で削除されているため、クラスター管理者とオペレーターはこれらのセキュリティコントロールを置き換える必要があります。このニーズを満たすには、次の 2 つのソリューションがあります。

• Kubernetes エコシステムからの Policy-as-code (PAC) ソリューション

• Kubernetes Pod セキュリティ標準 (PSS)

PAC ソリューションと PSS ソリューションの両方が PSP と共存できます。PSP を削除する前にクラスターで使用できます。これにより、PSP から移行する際の導入が容易になります。PSP から PSS への移行を検討する際は、このドキュメントを参照してください。

以下に概説する PAC ソリューションの 1 つである Kyverno PSPs には、PSP からソリューションに移行する際のブログ記事で概説されている、類似ポリシー、機能比較、移行手順などの具体的なガイダンスがあります。Pod Security Admission (PSA) に関する Kyverno への移行に関する追加情報とガイダンスは、AWS ブログで公開されています。

Policy-as-code (PAC)

Policy-as-code (PAC) ソリューションは、規定および自動化されたコントロールを通じて、クラスターユーザーをガイドし、望ましくない動作を防ぐガードレールを提供します。PAC は Kubernetes Dynamic Admission Controllers を使用して、ウェブフック呼び出しを介して Kubernetes API サーバーリクエストフローを傍受し、コードとして記述および保存されたポリシーに基づいてリクエストペイロードを変更および検証します。ミューテーションと検証は、API サーバーリクエストによってクラスターが変更される前に行われます。PAC ソリューションは、ポリシーを使用して、分類と値に基づいて API サーバーリクエストペイロードを照合して処理します。

Kubernetes で使用できるオープンソースの PAC ソリューションがいくつかあります。これらのソリューションは Kubernetes プロジェクトの一部ではなく、Kubernetes エコシステムから調達されています。PAC ソリューションの一部を以下に示します。

• OPA/ゲートキーパー

• オープンポリシーエージェント (OPA)

• キバーノ

• クベワーデン

• jsPolicy

PAC ソリューションの詳細と、ニーズに合わせて適切なソリューションを選択する方法については、以下のリンクを参照してください。

• Kubernetes のポリシーベースの対策 – パート 1

• Kubernetes のポリシーベースの対策 – パート 2

Pod Security Standards (PSS) と Pod Security Admission (PSA)

PSP の非推奨とポッドセキュリティout-of-the-box制御する継続的な必要性に応じて、Kubernetes Auth Special Interest Group は Pod Security Standards (PSS) と Pod Security Admission (PSA) を作成しました。PSA エフォートには、PSS で定義されたコントロールを実装するアドミッションコントローラーウェブフックプロジェクトが含まれます。このアドミッションコントローラーアプローチは、PAC ソリューションで使用された に似ています。

Kubernetes ドキュメントによると、PSS は「セキュリティスペクトルを広くカバーするために 3 つの異なるポリシーを定義します。これらのポリシーは累積的であり、高許可から高制限まで多岐にわたります。」

これらのポリシーは次のように定義されます。

• 特権： 無制限 (安全でない) ポリシー。可能な限り幅広いレベルのアクセス許可を提供します。このポリシーは、既知の特権のエスカレーションを許可します。これはポリシーがないことです。これは、ログ記録エージェント、CNIs、ストレージドライバー、および特権アクセスを必要とするその他のシステム全体のアプリケーションに適しています。

• ベースライン： 既知の特権のエスカレーションを防ぐ最小限の制限ポリシー。デフォルトの (最小限に指定された) Pod 設定を許可します。ベースラインポリシーでは、hostNetwork、hostPID、hostIPC、hostPath、hostPort、Linux 機能を追加できないこと、および他のいくつかの制限の使用を禁止しています。

• 制限付き： 現在の Pod 強化のベストプラクティスに従って、ポリシーを厳しく制限します。このポリシーはベースラインから継承され、ルートまたはルートグループとして実行できないなどの制限を追加します。制限付きポリシーは、アプリケーションの機能に影響を与える可能性があります。主にセキュリティクリティカルなアプリケーションの実行を対象としています。

これらのポリシーは、ポッド実行のプロファイルを定義し、3 つのレベルの特権アクセスと制限付きアクセスに分かれています。

PSS で定義されたコントロールを実装するために、PSA は 3 つのモードで動作します。

• enforce: ポリシー違反により、ポッドが拒否されます。

• 監査： ポリシー違反は、監査ログに記録されたイベントへの監査注釈の追加をトリガーしますが、それ以外の場合は許可されます。

• 警告： ポリシー違反はユーザー向けの警告をトリガーしますが、それ以外の場合は許可されます。

これらのモードとプロファイル (制限) レベルは、次の例に示すように、ラベルを使用して Kubernetes 名前空間レベルで設定されます。

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: restricted

これらのオペレーションモードを個別に使用すると、レスポンスが異なるため、ユーザーエクスペリエンスも異なります。適用モードでは、それぞれの podSpecs が設定された制限レベルに違反した場合、ポッドが作成されなくなります。ただし、このモードでは、デプロイなどのポッドを作成するポッド以外の Kubernetes オブジェクトは、そのpodSpecックが適用された PSS に違反していても、クラスターに適用されないようにします。この場合、デプロイが適用されますが、ポッド (複数可) は適用されません。

これは、正常に適用されたデプロイオブジェクトがポッドの作成に失敗したとすぐには判断されないため、難しいユーザーエクスペリエンスです。問題のある podSpecs はポッドを作成しません。を使用してデプロイリソースを検査kubectl get deploy <DEPLOYMENT_NAME> -oyamlすると、以下に示すように、失敗したポッド (複数可) .status.conditions要素からのメッセージが公開されます。

...
status:
  conditions:
    - lastTransitionTime: "2022-01-20T01:02:08Z"
      lastUpdateTime: "2022-01-20T01:02:08Z"
      message: 'pods "test-688f68dc87-tw587" is forbidden: violates PodSecurity "restricted:latest":
        allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false),
        unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]),
        runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true),
        seccompProfile (pod or container "test" must set securityContext.seccompProfile.type
        to "RuntimeDefault" or "Localhost")'
      reason: FailedCreate
      status: "True"
      type: ReplicaFailure
...

監査モードと警告モードの両方で、ポッドの制限により、違反しているポッドの作成と起動が妨げられることはありません。ただし、これらのモードでは、ポッドとポッドを作成するオブジェクトに違反のある podSpecsが含まれている場合に、kubectl などの API サーバー監査ログイベントと API サーバークライアントへの警告がそれぞれトリガーされます。kubectl 警告メッセージが以下に表示されます。

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
deployment.apps/test created

PSA 監査モードと警告モードは、クラスターオペレーションに悪影響を及ぼすことなく PSS を導入する場合に役立ちます。

PSA オペレーションモードは相互に排他的ではなく、累積的に使用できます。以下に示すように、複数のモードを 1 つの名前空間に設定できます。

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

上記の例では、デプロイを適用するときにユーザーフレンドリーな警告と監査注釈が提供され、違反の強制もポッドレベルで提供されます。実際、以下に示すように、複数の PSA ラベルで異なるプロファイルレベルを使用できます。

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

上記の例では、ベースラインプロファイルレベルを満たすすべてのポッドの作成を許可し、制限付きプロファイルレベルに違反するポッド (およびポッドを作成するオブジェクト) に警告するように PSA が設定されています。これは、ベースラインから制限付きプロファイルに変更した場合に考えられる影響を判断するのに役立つアプローチです。

既存のポッド

既存のポッドの名前空間が、より制限の厳しい PSS プロファイルを使用するように変更された場合、監査モードと警告モードは適切なメッセージを生成しますが、強制モードはポッドを削除しません。警告メッセージを以下に示します。

Warning: existing pods in namespace "policy-test" violate the new PodSecurity enforce level "restricted:latest"
Warning: test-688f68dc87-htm8x: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/policy-test configured

免除

PSA は免除を使用して、適用されていたポッドに対する違反の適用を除外します。これらの免除事項を以下に示します。

• ユーザー名： 認証された (または偽装された) ユーザー名が除外されたユーザーからのリクエストは無視されます。

• RuntimeClassNames: 除外ランタイムクラス名を指定するポッドとワークロードリソースは無視されます。

• 名前空間： 除外名前空間のポッドとワークロードリソースは無視されます。

これらの免除は、API サーバー設定の一部として PSA アドミッションコントローラー設定で静的に適用されます。

検証ウェブフックの実装では、pod-security-webhookコンテナにボリュームとしてマウントされる Kubernetes ConfigMap リソース内で免除を設定できます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-security-webhook
  namespace: pod-security-webhook
data:
  podsecurityconfiguration.yaml: |
    apiVersion: pod-security.admission.config.k8s.io/v1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "restricted"
      enforce-version: "latest"
      audit: "restricted"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: ["kube-system","policy-test1"]

上記の ConfigMap YAML に示すように、クラスター全体のデフォルト PSS レベルは、すべての PSA モード、監査、強制、および警告に対して制限されています。これは、除外されたものを除くすべての名前空間に影響します: namespaces: ["kube-system","policy-test1"]。さらに、以下に示す ValidatingWebhookConfiguration リソースでは、pod-security-webhook 名前空間も設定された PSS から除外されます。

...
webhooks:
  # Audit annotations will be prefixed with this name
  - name: "pod-security-webhook.kubernetes.io"
    # Fail-closed admission webhooks can present operational challenges.
    # You may want to consider using a failure policy of Ignore, but should
    # consider the security tradeoffs.
    failurePolicy: Fail
    namespaceSelector:
      # Exempt the webhook itself to avoid a circular dependency.
      matchExpressions:
        - key: kubernetes.io/metadata.name
          operator: NotIn
          values: ["pod-security-webhook"]
...

重要

Pod Security Admissions は、Kubernetes v1.25 で安定するように卒業しました。Pod Security Admission 機能をデフォルトで有効にする前に使用する場合は、動的アドミッションコントローラー (ウェブフックの変更) をインストールする必要があります。ウェブフックのインストールと設定の手順については、こちらを参照してください。

policy-as-codeと Pod セキュリティ標準の選択

Pod Security Standards (PSS) は、Kubernetes に組み込み、Kubernetes エコシステムからのソリューションを必要としないソリューションを提供することで、Pod Security Policy (PSP) を置き換えるために開発されました。つまり、コードpolicy-as-code (PAC) ソリューションははるかに柔軟です。

以下の Pros と Cons のリストは、ポッドセキュリティソリューションについてより情報に基づいた意思決定を行うのに役立ちます。

Policy-as-code (Pod セキュリティ標準と比較）

メリット:

• より柔軟で詳細 (必要に応じてリソースの属性まで）

• ポッドだけでなく、さまざまなリソースやアクションに対して使用できます。

• 名前空間レベルで適用されるだけでなく

• Pod セキュリティ標準よりも成熟している

• 決定は、API サーバーリクエストペイロード内の任意のもの、および既存のクラスターリソースと外部データ (ソリューション依存) に基づいて行うことができます。

• 検証前の API サーバーリクエストのミューテーションをサポート (ソリューション依存）

• 補完的なポリシーと Kubernetes リソースを生成できます (ソリューション依存 - ポッドポリシーから、Kyverno はデプロイなどの上位レベルのコントローラーのポリシーを自動生成できます。 Kyverno は、ルールの生成を使用して、「`新しいリソースの作成時またはソースの更新時」に追加の Kubernetes リソースを生成することもできます。」）

• Kubernetes API サーバーを呼び出す前に、左から CICD パイプラインにシフトするために使用できます (ソリューション依存）

• ベストプラクティス、組織標準など、セキュリティに必ずしも関連しない動作を実装するために使用できます。

• Kubernetes 以外のユースケースで使用可能 (ソリューション依存）

• 柔軟性があるため、ユーザーエクスペリエンスはユーザーのニーズに合わせて調整できます。

デメリット:

• Kubernetes に組み込まれていない

• より複雑な学習、設定、サポート

• ポリシーの作成には、新しいskills/languages/capabilitiesが必要になる場合があります

Pod Security Admission (policy-as-code と比較）

メリット:

• Kubernetes に組み込まれている

• 設定が簡単

• または ポリシーを使用して作成する新しい言語がない

• クラスターのデフォルトのアドミッションレベルが特権レベルに設定されている場合、名前空間ラベルを使用して名前空間をポッドセキュリティプロファイルにオプトインできます。

デメリット:

• policy-as-codeほど柔軟でも詳細でもない

• 3 つのレベルの制限のみ

• 主にポッドに重点を置く

概要

現在、PSP 以外のポッドセキュリティソリューションがなく、必要なポッドセキュリティ体制が Pod Security Standards (PSS) で定義されているモデルに適合している場合、policy-as-codeソリューションの代わりに PSS を採用するのが簡単な方法かもしれません。ただし、ポッドのセキュリティ体制が PSS モデルに合わない場合、または PSS で定義されたコントロールを超えて追加のコントロールを追加することを想定している場合、policy-as-codeソリューションの方が適しているように見えます。

レコメンデーション

複数の Pod Security Admission (PSA) モードを使用してユーザーエクスペリエンスを向上させる

前述のように、PSA 強制モードでは、PSS 違反のあるポッドは適用されませんが、デプロイなどの上位レベルのコントローラーは停止されません。実際には、デプロイはポッドの適用に失敗したことを示すことなく正常に適用されます。kubectl を使用してデプロイオブジェクトを検査し、PSA から失敗したポッドメッセージを検出できますが、ユーザーエクスペリエンスは向上する可能性があります。ユーザーエクスペリエンスを向上させるには、複数の PSA モード (監査、強制、警告) を使用する必要があります。

apiVersion: v1
kind: Namespace
metadata:
  name: policy-test
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

上記の例では、強制モードが定義されているため、それぞれの podSpec で PSS 違反のあるデプロイマニフェストを Kubernetes API サーバーに適用しようとすると、デプロイは正常に適用されますが、ポッドは適用されません。また、監査モードと警告モードも有効になっているため、API サーバークライアントは警告メッセージを受信し、API サーバーの監査ログイベントにもメッセージで注釈が付けられます。

特権として実行できるコンテナを制限する

前述のように、特権として実行されるコンテナは、ホストのルートに割り当てられたすべての Linux 機能を継承します。コンテナが適切に機能するために、これらのタイプの権限が必要になることはほとんどありません。コンテナのアクセス許可と機能を制限するために使用できる方法は複数あります。

重要

Fargate は、ポッドのコンテナが AWS が管理するインフラストラクチャで実行される「サーバーレス」コンテナ (複数可) を実行できるようにする起動タイプです。Fargate では、特権コンテナを実行したり、hostNetwork または hostPort を使用するようにポッドを設定したりすることはできません。

コンテナ内のプロセスをルートとして実行しない

すべてのコンテナはデフォルトで root として実行されます。これは、攻撃者がアプリケーションの脆弱性を悪用し、実行中のコンテナへのシェルアクセスを取得できる場合に問題になる可能性があります。このリスクを軽減するには、さまざまな方法があります。まず、コンテナイメージからシェルを削除します。次に、USER ディレクティブを Dockerfile に追加するか、ポッド内のコンテナを非ルートユーザーとして実行します。Kubernetes podSpec には、アプリケーションを実行するユーザーやグループを指定できるspec.securityContext、 の一連のフィールドが含まれています。これらのフィールドrunAsGroupはそれぞれ runAsUserおよび です。

Kubernetes podSpec 内で spec.securityContextとその関連要素の使用を強制するために、policy-as-code または Pod Security Standards をクラスターに追加できます。これらのソリューションを使用すると、インバウンド Kubernetes API サーバーリクエストペイロードを etcd に保持する前に検証できるポリシーまたはプロファイルを記述および/または使用できます。さらに、policy-as-code ソリューションはインバウンドリクエストを変更し、場合によっては新しいリクエストを生成できます。

Docker で Docker を実行したり、コンテナにソケットをマウントしたりしないでください。

これにより、Docker コンテナでイメージを構築/実行できますが、基本的には、コンテナで実行されているプロセスにノードの完全な制御を放棄します。Kubernetes でコンテナイメージを構築する必要がある場合は、代わりに Kaniko、buildah、または CodeBuild などのビルドサービスを使用します。

注記

コンテナイメージの構築など、CICD 処理に使用される Kubernetes クラスターは、より一般的なワークロードを実行しているクラスターから分離する必要があります。

hostPath の使用を制限するか、hostPath が必要な場合は、使用できるプレフィックスを制限し、ボリュームを読み取り専用として設定します。

hostPath は、ホストからコンテナに直接ディレクトリをマウントするボリュームです。ポッドにこのタイプのアクセスが必要になることはまれですが、必要になった場合はリスクに注意する必要があります。デフォルトでは、root として実行されるポッドは hostPath によって公開されるファイルシステムへの書き込みアクセス権を持ちます。これにより、攻撃者は kubelet 設定を変更したり、/etc/shadow などの hostPath によって直接公開されていないディレクトリやファイルへのシンボリックリンクを作成したり、ssh キーをインストールしたり、ホストにマウントされたシークレットを読み取ったり、その他の悪意のあるものを行ったりすることができます。hostPath によるリスクを軽減するには、 readOnlyを spec.containers.volumeMountsとして設定します。次に例を示します。

volumeMounts:
- name: hostPath-volume
    readOnly: true
    mountPath: /host-path

また、policy-as-code ソリューションを使用して、hostPathボリュームで使用できるディレクトリを制限したり、hostPath使用を完全に防止したりする必要があります。Pod Security Standards Baseline または制限付きポリシーを使用して、 の使用を防ぐことができますhostPath。

特権エスカレーションの危険性の詳細については、Seth Art のブログ「Bad Pods: Kubernetes Pod Privilege Escalation」を参照してください。

リソースの競合や DoS 攻撃を避けるために、コンテナごとにリクエストと制限を設定する

リクエストや制限のないポッドは、理論的にはホストで使用できるすべてのリソースを消費できます。追加のポッドがノードにスケジュールされると、ノードに CPU またはメモリの負荷が発生し、Kubelet がノードからポッドを終了または削除する可能性があります。これらがすべて同時に発生するのを防ぐことはできませんが、リクエストと制限を設定すると、リソースの競合を最小限に抑え、大量のリソースを消費する記述が不十分なアプリケーションによるリスクを軽減できます。

podSpec では、CPU とメモリのリクエストと制限を指定できます。CPU はオーバーサブスクライブされる可能性があるため、圧縮可能なリソースと見なされます。メモリは非圧縮です。つまり、複数のコンテナ間で共有することはできません。

CPU またはメモリのリクエストを指定する場合、基本的にコンテナが取得するメモリの量を指定します。Kubernetes は、ポッド内のすべてのコンテナのリクエストを集約して、ポッドをスケジュールするノードを決定します。コンテナが要求されたメモリ量を超えると、ノードにメモリ負荷がある場合に終了する可能性があります。

制限は、コンテナが消費できる CPU およびメモリリソースの最大量であり、コンテナ用に作成された cgroup memory.limit_in_bytesの値に直接対応します。メモリ制限を超えるコンテナは OOM が強制終了します。コンテナが CPU 制限を超えると、スロットリングされます。

注記

コンテナを使用する場合はresources.limits、コンテナリソースの使用 (別名: リソースフットプリント) が負荷テストに基づいてデータ駆動型で正確であることを強くお勧めします。正確で信頼できるリソースフットプリントがなければ、コンテナをパディングresources.limitsできます。例えば、 は、潜在的なメモリリソース制限の不正確性を考慮して、観測可能な最大値よりも 20～30% 高くパディングresources.limits.memoryできます。

Kubernetes は 3 つの Quality of Service (QoS) クラスを使用して、ノードで実行されているワークロードに優先順位を付けます。具体的には次のとおりです。

• 保証

• バースト可能

• ベストエフォート

制限とリクエストが設定されていない場合、ポッドはベストエフォート (最低優先度) として設定されます。ベストエフォートポッドは、メモリ不足時に最初に強制終了されます。ポッド内のすべてのコンテナに制限が設定されている場合、またはリクエストと制限が同じ値に設定され、0 に等しくない場合、ポッドは保証 (最高優先度) として設定されます。保証されたポッドは、設定されたメモリ制限を超えない限り強制終了されません。制限とリクエストが異なる値で設定されていて 0 に等しくない場合、またはポッド内の 1 つのコンテナで制限が設定されておらず、他のコンテナで異なるリソースに対して制限が設定されていない場合、ポッドはバースト可能 (中優先度) として設定されます。これらのポッドにはいくつかのリソース保証がありますが、リクエストされたメモリを超えると強制終了できます。

重要

リクエストはコンテナの cgroup memory_limit_in_bytesの値には影響しません。cgroup の制限はホストで使用可能なメモリ量に設定されます。それでも、リクエスト値の設定が低すぎると、ノードがメモリ負荷を受けると、ポッドが kubelet による終了の対象となる可能性があります。

Class	優先度	条件	強制終了条件
保証付き	highest	制限 = リクエスト != 0	メモリ制限のみを超える
バースト可能	medium	limit != リクエスト != 0	リクエストメモリを超えると強制終了可能
ベストエフォート	lowest	制限とリクエストが設定されていません	メモリ不足時に最初に強制終了する

リソース QoS の詳細については、Kubernetes ドキュメントを参照してください。

リクエストと制限の使用を強制するには、名前空間にリソースクォータを設定するか、制限範囲を作成します。リソースクォータを使用すると、名前空間に割り当てられた CPU や RAM などのリソースの合計量を指定できます。名前空間に適用すると、その名前空間にデプロイされたすべてのコンテナのリクエストと制限を強制的に指定します。対照的に、制限範囲を使用すると、リソースの割り当てをより詳細に制御できます。制限範囲を使用すると、ポッドごと、または名前空間内のコンテナごとに CPU リソースとメモリリソースの最小値/最大値を指定できます。何も指定されていない場合は、これらを使用してデフォルトのリクエスト/制限値を設定することもできます。

Policy-as-codeソリューションを使用すると、リクエストと制限を適用できます。 または を使用して、名前空間の作成時にリソースクォータと制限範囲を作成することもできます。

特権エスカレーションを許可しない

特権エスカレーションにより、プロセスは実行元のセキュリティコンテキストを変更できます。Sudo は、SUID または SGID ビットを持つバイナリであるため、この良い例です。特権エスカレーションは基本的に、ユーザーが別のユーザーまたはグループのアクセス許可を持つファイルを実行する方法です。を に設定する policy-as-code 変更ポリシーを実装するか、 securityContext.allowPrivilegeEscalationで を設定allowPrivilegeEscalationfalseすることで、コンテナが特権エスカレーションを使用することを防ぐことができますpodSpec。Policy-as-code ポリシーを使用して、誤った設定が検出された場合に API サーバーリクエストが成功しないようにすることもできます。ポッドセキュリティ標準を使用して、ポッドが特権エスカレーションを使用できないようにすることもできます。

ServiceAccount トークンマウントを無効にする

Kubernetes API にアクセスする必要がないポッドの場合、ポッド仕様、または特定の ServiceAccount を使用するすべてのポッドで ServiceAccount トークンの自動マウントを無効にすることができます。

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-automount
spec:
  automountServiceAccountToken: false

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-no-automount
automountServiceAccountToken: false

サービス検出を無効にする

クラスター内サービスを検索または呼び出す必要がないポッドの場合、ポッドに提供される情報の量を減らすことができます。CoreDNS を使用しないCoreDNSポリシーを設定し、ポッドの名前空間内のサービスを環境変数として公開しないように設定できます。サービスリンクの詳細については、環境変数に関する Kubernetes ドキュメントを参照してください。ポッドの DNS ポリシーのデフォルト値はクラスター内 DNS を使用するClusterFirst」で、デフォルト値以外の「Default」は基盤となるノードの DNS 解決を使用します。詳細については、ポッド DNS ポリシーの Kubernetes ドキュメントを参照してください。

apiVersion: v1
kind: Pod
metadata:
  name: pod-no-service-info
spec:
    dnsPolicy: Default # "Default" is not the true default value
    enableServiceLinks: false

読み取り専用のルートファイルシステムでイメージを設定する

読み取り専用ルートファイルシステムでイメージを設定すると、攻撃者はアプリケーションが使用するファイルシステムでバイナリを上書きできなくなります。アプリケーションがファイルシステムに書き込む必要がある場合は、一時ディレクトリに書き込むか、ボリュームをアタッチしてマウントすることを検討してください。これを強制するには、次のようにポッドの SecurityContext を設定します。

...
securityContext:
  readOnlyRootFilesystem: true
...

Policy-as-code および Pod セキュリティ標準を使用して、この動作を適用できます。

Kubernetes の Windows コンテナは、Windows で実行されているコンテナtrueに対して に設定securityContext.readOnlyRootFilesystemすることはできません。これは、レジストリとシステムプロセスがコンテナ内で実行するために書き込みアクセスが必要なためです。

ツールとリソース

• Amazon EKS セキュリティイマージョンワークショップ - ポッドセキュリティ

• open-policy-agent/gatekeeper-library: OPA Gatekeeper ポリシーライブラリは、PSPs。

• Kyverno ポリシーライブラリ

• EKS の一般的な OPA および Kyverno ポリシーのコレクション。

• ポリシーベースの対策: パート 1

• ポリシーベースの対策: パート 2

• Pod Security Policy Migrator PSPs を OPA/Gatekeeper、KubeWarden、または Kyverno ポリシーに変換するツール

• SUSE オープンソースのゼロトラストコンテナセキュリティプラットフォームによる NeuVector は、プロセスポリシーとファイルシステムポリシー、アドミッションコントロールルールを提供します。