翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ポッドのセキュリティ **ヒント** Amazon EKS [https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el)ワークショップを通じてベストプラクティスをご覧ください。 ポッド仕様には、全体的なセキュリティ体制を強化または弱める可能性のあるさまざまな属性が含まれています。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` **Example** EC2 ポッドと Fargate ポッドには、デフォルトで前述の機能が割り当てられます。さらに、Linux 機能は Fargate ポッドからのみ削除できます。 特権として実行されるポッドは、ホスト上のルートに関連付けられた*すべての* Linux 機能を継承します。これは可能であれば避けてください。 ### ノード認可 すべての Kubernetes ワーカーノードは、[ノード](https://kubernetes.io/docs/reference/access-authn-authz/node/)認可と呼ばれる認可モードを使用します。Node Authorization は、kubelet から送信されるすべての API リクエストを承認し、ノードが次のアクションを実行できるようにします。 読み取りオペレーション: + サービス + エンドポイント + ノード + ポッド + kubelet のノードにバインドされたポッドに関連するシークレット、設定マップ、永続ボリュームクレーム、永続ボリューム 書き込みオペレーション: + ノードとノードステータス (アド`NodeRestriction`ミッションプラグインを有効にして kubelet を制限し、独自のノードを変更) + ポッドとポッドステータス (アド`NodeRestriction`ミッションプラグインを有効にして kubelet を制限し、それ自体にバインドされたポッドを変更) + イベント 認証関連のオペレーション: + TLS ブートストラップ用の CertificateSigningRequest (CSR) API への読み取り/書き込みアクセス + 委任認証/認可チェック用の TokenReview と SubjectAccessReview を作成する機能 EKS は[ノード制限アドミッションコントローラー](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction)を使用します。これにより、ノードはノードにバインドされているノード属性とポッドオブジェクトの限定されたセットのみ変更できます。ただし、ホストへのアクセスを管理する攻撃者は、Kubernetes API から環境に関する機密情報を収集できるため、クラスター内で横方向に移動できます。 ## ポッドセキュリティソリューション ### ポッドセキュリティポリシー (PSP) 以前は、[ポッドセキュリティポリシー (PSP)](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) リソースを使用して、ポッドを作成する前に満たす必要がある一連の要件を指定していました。Kubernetes バージョン 1.21 以降、PSP は廃止されました。これらは Kubernetes バージョン 1.25 で削除される予定です。 **重要** [PSPs は Kubernetes バージョン 1.21 では廃止されました](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。バージョン 1.25 まで、または別の に移行するには約 2 年かかります。この[ドキュメント](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/2579-psp-replacement/README.md#motivation)では、この廃止の動機について説明します。 ### 新しいポッドセキュリティソリューションへの移行 Kubernetes v1.25 の時点で PSPs が削除されているため、クラスター管理者とオペレーターはこれらのセキュリティコントロールを置き換える必要があります。このニーズを満たすには、次の 2 つのソリューションがあります。 + Kubernetes エコシステムからの Policy-as-code (PAC) ソリューション + Kubernetes [Pod セキュリティ標準 (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) PAC ソリューションと PSS ソリューションの両方が PSP と共存できます。PSP を削除する前にクラスターで使用できます。これにより、PSP から移行する際の導入が容易になります。PSP から PSS への移行を検討する際は、この[ドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/)を参照してください。 以下に概説する PAC ソリューションの 1 つである Kyverno には、類似ポリシー、機能比較、移行手順など、PSPsからソリューションに移行する際の特定のガイダンスが[ブログ記事](https://kyverno.io/blog/2023/05/24/podsecuritypolicy-migration-with-kyverno/)で説明されています。Pod Security Admission (PSA) に関する Kyverno への移行に関する追加情報とガイダンスは、[AWS](https://aws.amazon.com/blogs/containers/managing-pod-security-on-amazon-eks-with-kyverno/) ブログで公開されています。 ### Policy-as-code (PAC) Policy-as-code (PAC) ソリューションは、クラスターユーザーをガイドし、規定の自動化されたコントロールを通じて望ましくない動作を防ぐためのガードレールを提供します。PAC は [Kubernetes Dynamic Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) を使用して、ウェブフック呼び出しを介して Kubernetes API サーバーリクエストフローを傍受し、コードとして記述および保存されたポリシーに基づいてリクエストペイロードを変更および検証します。ミューテーションと検証は、API サーバーリクエストによってクラスターが変更される前に行われます。PAC ソリューションは、ポリシーを使用して、分類と値に基づいて API サーバーリクエストペイロードを照合して処理します。 Kubernetes で使用できるオープンソースの PAC ソリューションがいくつかあります。これらのソリューションは Kubernetes プロジェクトの一部ではなく、Kubernetes エコシステムから調達されています。PAC ソリューションの一部を以下に示します。 + [OPA/ゲートキーパー](https://open-policy-agent.github.io/gatekeeper/website/docs/) + [オープンポリシーエージェント (OPA)](https://www.openpolicyagent.org/) + [キバーノ](https://kyverno.io/) + [クベワーデン](https://www.kubewarden.io/) + [jsPolicy](https://www.jspolicy.com/) PAC ソリューションの詳細と、ニーズに合わせて適切なソリューションを選択する方法については、以下のリンクを参照してください。 + [Kubernetes のポリシーベースの対策 – パート 1](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-1/) + [Kubernetes のポリシーベースの対策 – パート 2](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-2/) ### Pod Security Standards (PSS) と Pod Security Admission (PSA) PSP の非推奨とポッドセキュリティout-of-the-box制御する継続的な必要性に応じて、Kubernetes [Auth Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-auth) は [Pod Security Standards (PSS)](https://kubernetes.io/docs/concepts/security/pod-security-standards/) と [Pod Security Admission (PSA)](https://kubernetes.io/docs/concepts/security/pod-security-admission/) を作成しました。PSA エフォートには、PSS で定義されたコントロールを実装するアド[ミッションコントローラーウェブフックプロジェクト](https://github.com/kubernetes/pod-security-admission#pod-security-admission)が含まれます。このアドミッションコントローラーアプローチは、PAC ソリューションで使用された に似ています。 Kubernetes のドキュメントによると、PSS は*「セキュリティスペクトルを広くカバーするために 3 つの異なるポリシーを定義します。これらのポリシーは累積的であり、高許可から高制限まで多岐にわたります。*」 これらのポリシーは次のように定義されます。 + **特権:** 無制限 (安全でない) ポリシー。可能な限り幅広いレベルのアクセス許可を提供します。このポリシーは、既知の特権のエスカレーションを許可します。これはポリシーがないことです。これは、ログ記録エージェント、CNIs、ストレージドライバー、および特権アクセスを必要とするその他のシステム全体のアプリケーションに適しています。 + **ベースライン:** 既知の特権のエスカレーションを防止する最小限の制限ポリシー。デフォルトの (最小限に指定された) Pod 設定を許可します。ベースラインポリシーでは、hostNetwork、hostPID、hostIPC、hostPath、hostPort、Linux 機能を追加できないこと、および他のいくつかの制限の使用を禁止しています。 + **制限付き:** 現在の Pod 強化のベストプラクティスに従って、厳しく制限されたポリシー。このポリシーはベースラインから継承され、ルートまたはルートグループとして実行できないなどの制限を追加します。制限されたポリシーは、アプリケーションの機能に影響を与える可能性があります。主にセキュリティクリティカルなアプリケーションの実行を対象としています。 これらのポリシーは、[ポッド実行のプロファイル](https://kubernetes.io/docs/concepts/security/pod-security-standards/#profile-details)を定義し、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 はポッドを作成しません。でデプロイリソースを検査すると、以下に示すように、失敗したポッド (複数可) `.status.conditions`要素からのメッセージが公開`kubectl get deploy -oyaml`されます。 ``` ... 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 アドミッションコントローラー](https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)設定で静的に適用されます。 *検証ウェブフック*の実装では、[pod-security-webhook](https://github.com/kubernetes/pod-security-admission/blob/master/webhook/manifests/50-deployment.yaml)コンテナにボリュームとしてマウントされる Kubernetes [ConfigMap](https://github.com/kubernetes/pod-security-admission/blob/master/webhook/manifests/20-configmap.yaml) リソース内で免除を設定できます。 ``` 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 機能をデフォルトで有効にする前に使用する場合は、動的アドミッションコントローラー (変更ウェブフック) をインストールする必要があります。ウェブフックのインストールと設定の手順については、[こちら](https://github.com/kubernetes/pod-security-admission/tree/master/webhook)を参照してください。 ### policy-as-code と Pod セキュリティ標準の選択 Pod Security Standards (PSS) は、Kubernetes に組み込み、Kubernetes エコシステムからのソリューションを必要としないソリューションを提供することで、Pod Security Policy (PSP) を置き換えるために開発されました。つまり、コードpolicy-as-code (PAC) ソリューションははるかに柔軟です。 以下の Pros and Cons のリストは、ポッドセキュリティソリューションについてより情報に基づいた意思決定を行うのに役立ちます。 #### Policy-as-code (Pod セキュリティ標準と比較) メリット: + より柔軟で詳細 (必要に応じてリソースの属性まで) + ポッドだけでなく、さまざまなリソースやアクションに対して使用できます。 + 名前空間レベルで適用されるだけでなく + Pod セキュリティ標準よりも成熟している + 決定は、API サーバーリクエストペイロード内の任意のもの、および既存のクラスターリソースと外部データ (ソリューション依存) に基づいて行うことができます。 + 検証前の API サーバーリクエストの変更をサポート (ソリューション依存) + 補完的なポリシーと Kubernetes リソースを生成できます (ソリューション依存 - ポッドポリシーから、Kyverno はデプロイなどの上位レベルのコントローラーのポリシー[を自動生成](https://kyverno.io/docs/writing-policies/autogen/)できます。 Kyverno は、[ルール](https://kyverno.io/docs/writing-policies/generate/)の生成を使用して、*「新しいリソースの作成時またはソースの更新時」に追加の 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](https://github.com/GoogleContainerTools/kaniko)、[buildah](https://github.com/containers/buildah)、または [CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) などのビルドサービスを使用します。 **注記** コンテナイメージの構築など、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](https://labs.bishopfox.com/tech-blog/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 | 優先度 | Condition | 強制終了条件 | | --- | --- | --- | --- | | 保証付き | highest | 制限 = リクエスト \$1= 0 | メモリ制限のみ超過する | | バースト可能 | medium | limit \$1= リクエスト \$1= 0 | リクエストメモリを超えた場合、強制終了可能 | | ベストエフォート | lowest | 制限とリクエストが設定されていません | メモリ不足時に最初に強制終了する | リソース QoS の詳細については、[Kubernetes ドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)を参照してください。 リクエストと制限の使用を強制するには、名前空間に[リソースクォータ](https://kubernetes.io/docs/concepts/policy/resource-quotas/)を設定するか、[制限範囲](https://kubernetes.io/docs/concepts/policy/limit-range/)を作成します。リソースクォータを使用すると、名前空間に割り当てられた CPU や RAM などのリソースの合計量を指定できます。名前空間に適用すると、その名前空間にデプロイされたすべてのコンテナのリクエストと制限を強制的に指定します。対照的に、制限範囲を使用すると、リソースの割り当てをより詳細に制御できます。制限範囲を使用すると、ポッドごと、または名前空間内のコンテナごとに CPU リソースとメモリリソースの最小値/最大値を指定できます。何も指定されていない場合は、これらを使用してデフォルトのリクエスト/制限値を設定することもできます。 Policy-as-codeソリューションを使用すると、リクエストと制限を適用できます。 または を使用して、名前空間の作成時にリソースクォータと制限範囲を作成することもできます。 ### 特権エスカレーションを許可しない 特権エスカレーションにより、プロセスは実行元のセキュリティコンテキストを変更できます。Sudo は、SUID または SGID ビットを持つバイナリであるため、この良い例です。特権エスカレーションは基本的に、ユーザーが別のユーザーまたはグループのアクセス許可を持つファイルを実行する方法です。を に設定する policy-as-code 変更ポリシーを実装するか、 `securityContext.allowPrivilegeEscalation`で を設定`allowPrivilegeEscalation``false`することで、コンテナが特権エスカレーションを使用することを防ぐことができます`podSpec`。Policy-as-code ポリシーを使用して、誤った設定が検出された場合に API サーバーリクエストが成功しないようにすることもできます。ポッドセキュリティ標準を使用して、ポッドが特権エスカレーションを使用できないようにすることもできます。 ### ServiceAccount トークンマウントを無効にする Kubernetes API にアクセスする必要がないポッドの場合、ポッド仕様、または特定の ServiceAccount を使用するすべてのポッドで ServiceAccount トークンの自動マウントを無効にすることができます。 **Example** ``` 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 ドキュメント](https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables)を参照してください。ポッドの DNS ポリシーのデフォルト値はクラスター内 DNS を使用するClusterFirst」で、デフォルト値以外の「Default」は基盤となるノードの DNS 解決を使用します。詳細については、[ポッド DNS ポリシーの Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)を参照してください。 **Example** ``` 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 セキュリティ標準を使用して、この動作を適用できます。 **Example** [Kubernetes の Windows コンテナ](https://kubernetes.io/docs/concepts/windows/intro/)は、Windows で実行されているコンテナ`true`に対して に設定`securityContext.readOnlyRootFilesystem`することはできません。これは、レジストリとシステムプロセスがコンテナ内で実行するために書き込みアクセスが必要なためです。 ## ツールとリソース + [Amazon EKS セキュリティイマージョンワークショップ - ポッドセキュリティ](https://catalog.workshops.aws/eks-security-immersionday/en-US/3-pod-security) + [open-policy-agent/gatekeeper-library: OPA Gatekeeper ポリシーライブラリ](https://github.com/open-policy-agent/gatekeeper-library)は、PSPs。 + [Kyverno ポリシーライブラリ](https://kyverno.io/policies/) + EKS の一般的な OPA および Kyverno [ポリシー](https://github.com/aws/aws-eks-best-practices/tree/master/policies)のコレクション。 + [ポリシーベースの対策: パート 1](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-1/) + [ポリシーベースの対策: パート 2](https://aws.amazon.com/blogs/containers/policy-based-countermeasures-for-kubernetes-part-2/) + [Pod Security Policy Migrator](https://appvia.github.io/psp-migration/) PSPs を OPA/Gatekeeper、KubeWarden、または Kyverno ポリシーに変換するツール + [SUSE オープンソースのゼロトラストコンテナセキュリティプラットフォームによる NeuVector ](https://www.suse.com/neuvector/) は、プロセスポリシーとファイルシステムポリシー、アドミッションコントロールルールを提供します。