セキュリティ

• 1: クラウドネイティブセキュリティの概要
• 2: Podセキュリティの標準
• 3: クラウドネイティブセキュリティとKubernetes
• 4: Podのセキュリティアドミッション
• 5: サービスアカウント
• 6: Kubernetes APIへのアクセスコントロール
• 7: ロールベースアクセスコントロールのグッドプラクティス
• 8: Kubernetes Secretの適切な使用方法

1 - クラウドネイティブセキュリティの概要

この概要では、クラウドネイティブセキュリティにおけるKubernetesのセキュリティを考えるためのモデルを定義します。

クラウドネイティブセキュリティの４C

セキュリティは階層で考えることができます。クラウドネイティブの4Cは、クラウド、クラスター、コンテナ、そしてコードです。

クラウドネイティブセキュリティモデルの各レイヤーは次の最も外側のレイヤー上に構築します。コードレイヤーは、強固な基盤(クラウド、クラスター、コンテナ)セキュリティレイヤーから恩恵を受けます。コードレベルのセキュリティに対応しても基盤レイヤーが低い水準のセキュリティでは守ることができません。

クラウド

いろいろな意味でも、クラウド(または同じ場所に設置されたサーバー、企業のデータセンター)はKubernetesクラスターのトラステッド・コンピューティング・ベースです。クラウドレイヤーが脆弱な(または脆弱な方法で構成されている)場合、この基盤の上に構築されたコンポーネントが安全であるという保証はありません。各クラウドプロバイダーは、それぞれの環境でワークロードを安全に実行させるためのセキュリティの推奨事項を作成しています。

クラウドプロバイダーのセキュリティ

Kubernetesクラスターを所有しているハードウェアや様々なクラウドプロバイダー上で実行している場合、セキュリティのベストプラクティスに関するドキュメントを参考にしてください。ここでは人気のあるクラウドプロバイダーのセキュリティドキュメントの一部のリンクを紹介します。

インフラのセキュリティ

Kubernetesクラスターのインフラを保護するための提案です。

クラスター

Kubernetesを保護する為には２つの懸念事項があります。

• 設定可能なクラスターコンポーネントの保護
• クラスターで実行されるアプリケーションの保護

クラスターのコンポーネント

想定外または悪意のあるアクセスからクラスターを保護して適切なプラクティスを採用したい場合、クラスターの保護に関するアドバイスを読み従ってください。

クラスター内のコンポーネント(アプリケーション)

アプリケーションを対象にした攻撃に応じて、セキュリティの特定側面に焦点をあてたい場合があります。例:他のリソースとの連携で重要なサービス(サービスA)と、リソース枯渇攻撃に対して脆弱な別のワークロード(サービスB)が実行されている場合、サービスBのリソースを制限していないとサービスAが危険にさらされるリスクが高くなります。次の表はセキュリティの懸念事項とKubernetesで実行されるワークロードを保護するための推奨事項を示しています。

コンテナ

コンテナセキュリティは本ガイドの範囲外になります。このトピックを検索するために一般的な推奨事項とリンクを以下に示します。

コード

アプリケーションコードは、あなたが最も制御できる主要な攻撃対象のひとつです。アプリケーションコードを保護することはKubernetesのセキュリティトピックの範囲外ですが、アプリケーションコードを保護するための推奨事項を以下に示します。

コードセキュリティ

次の項目

関連するKubernetesセキュリティについて学びます。

• Podセキュリティの標準
• Podのネットワークポリシー
• Kubernetes APIへのアクセスを制御する
• クラスターの保護
• コントロールプレーンとの通信時のデータ暗号化
• 保存時のデータ暗号化
• Kubernetes Secret

2 - Podセキュリティの標準

Podに対するセキュリティの設定は通常Security Contextを使用して適用されます。Security ContextはPod単位での特権やアクセスコントロールの定義を実現します。

クラスターにおけるSecurity Contextの強制やポリシーベースの定義はPod Security Policyによって実現されてきました。 Pod Security Policy はクラスターレベルのリソースで、Pod定義のセキュリティに関する設定を制御します。

しかし、PodSecurityPolicyを拡張したり代替する、ポリシーを強制するための多くの方法が生まれてきました。 このページの意図は、推奨されるPodのセキュリティプロファイルを特定の実装から切り離して詳しく説明することです。

ポリシーの種別

まず、幅広いセキュリティの範囲をカバーできる、基礎となるポリシーの定義が必要です。 それらは強く制限をかけるものから自由度の高いものまでをカバーすべきです。

• 特権 - 制限のかかっていないポリシーで、可能な限り幅広い権限を提供します。このポリシーは既知の特権昇格を認めます。
• ベースライン、デフォルト - 制限は最小限にされたポリシーですが、既知の特権昇格を防止します。デフォルト（最小の指定）のPod設定を許容します。
• 制限 - 厳しく制限されたポリシーで、Podを強化するための現在のベストプラクティスに沿っています。

ポリシー

特権

特権ポリシーは意図的に開放されていて、完全に制限がかけられていません。この種のポリシーは通常、特権ユーザーまたは信頼されたユーザーが管理する、システムまたはインフラレベルのワークロードに対して適用されることを意図しています。

特権ポリシーは制限がないことと定義されます。gatekeeperのようにデフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定せず、何も制限を適用しないことにあたります。 一方で、Pod Security Policyのようにデフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化してコントロールできるようにする必要があります。

ベースライン、デフォルト

ベースライン、デフォルトのプロファイルは一般的なコンテナ化されたランタイムに適用しやすく、かつ既知の特権昇格を防ぐことを意図しています。 このポリシーはクリティカルではないアプリケーションの運用者または開発者を対象にしています。 次の項目は強制、または無効化すべきです。

制限

制限ポリシーはいくらかの互換性を犠牲にして、Podを強化するためのベストプラクティスを強制することを意図しています。 セキュリティ上クリティカルなアプリケーションの運用者や開発者、また信頼度の低いユーザーも対象にしています。 下記の項目を強制、無効化すべきです。

ポリシーの実例

ポリシーの定義とポリシーの実装を切り離すことによって、ポリシーを強制する機構とは独立して、汎用的な理解や複数のクラスターにわたる共通言語とすることができます。

機構が成熟してきたら、ポリシーごとに下記に定義されます。それぞれのポリシーを強制する方法についてはここでは定義しません。

PodSecurityPolicy

• 特権
• ベースライン
• 制限

FAQ

特権とデフォルトの間のプロファイルがないのはどうしてですか?

ここで定義されている3つのプロファイルは最も安全(制限)から最も安全ではない(特権)まで、直線的に段階が設定されており、幅広いワークロードをカバーしています。 ベースラインを超える特権が必要な場合、その多くはアプリケーションに特化しているため、その限られた要求に対して標準的なプロファイルを提供することはできません。 これは、このような場合に必ず特権プロファイルを使用すべきだという意味ではなく、場合に応じてポリシーを定義する必要があります。

将来、他のプロファイルの必要性が明らかになった場合、SIG Authはこの方針について再考する可能性があります。

セキュリティポリシーとセキュリティコンテキストの違いは何ですか?

Security Contextは実行時のコンテナやPodを設定するものです。 Security ContextはPodのマニフェストの中でPodやコンテナの仕様の一部として定義され、コンテナランタイムへ渡されるパラメーターを示します。

セキュリティポリシーはコントロールプレーンの機構で、Security Contextとそれ以外も含め、特定の設定を強制するものです。 2020年2月時点では、ネイティブにサポートされているポリシー強制の機構はPod Security Policyです。これはクラスター全体にわたってセキュリティポリシーを中央集権的に強制するものです。 セキュリティポリシーを強制する他の手段もKubernetesのエコシステムでは開発が進められています。例えばOPA Gatekeeperがあります。

WindowsのPodにはどのプロファイルを適用すればよいですか?

Kubernetesでは、Linuxベースのワークロードと比べてWindowsの使用は制限や差異があります。 特に、PodのSecurityContextフィールドはWindows環境では効果がありません。 したがって、現段階では標準化されたセキュリティポリシーは存在しません。

Windows Podに制限付きプロファイルを適用すると、実行時にPodに影響が出る場合があります。 制限付きプロファイルでは、Linux固有の制限(seccompプロファイルや特権昇格の不許可など)を適用する必要があります。 kubeletおよび/またはそのコンテナランタイムがこれらのLinux固有の値を無視した場合、Windows Podは制限付きプロファイル内で正常に動作します。 ただし、強制力がないため、Windows コンテナを使用するPodについては、ベースラインプロファイルと比較して追加の制限はありません。

HostProcess Podを作成するためのHostProcessフラグの使用は、特権的なポリシーに沿ってのみ行われるべきです。 Windows HostProcess Podの作成は、ベースラインおよび制限されたポリシーの下でブロックされているため、いかなるHostProcess Podも特権的であるとみなされるべきです。

サンドボックス化されたPodはどのように扱えばよいでしょうか?

現在のところ、Podがサンドボックス化されていると見なされるかどうかを制御できるAPI標準はありません。 サンドボックス化されたPodはサンドボックス化されたランタイム（例えばgVisorやKata Containers）の使用により特定することは可能ですが、サンドボックス化されたランタイムの標準的な定義は存在しません。

サンドボックス化されたランタイムに対して必要な保護は、それ以外に対するものとは異なります。 例えば、ワークロードがその基になるカーネルと分離されている場合、特権を制限する必要性は小さくなります。 これにより、強い権限を必要とするワークロードが隔離された状態を維持できます。

加えて、サンドボックス化されたワークロードの保護はサンドボックス化の実装に強く依存します。 したがって、全てのサンドボックス化されたワークロードに推奨される単一のポリシーは存在しません。

3 - クラウドネイティブセキュリティとKubernetes

Kubernetesはクラウドネイティブアーキテクチャに基づいており、クラウドネイティブ情報セキュリティのグッドプラクティスに関するアドバイスをCNCFから受けています。

このページを読み進めることで、安全なクラウドネイティブプラットフォームをデプロイするためにKubernetesがどのように設計されているかについての概要を知ることができます。

クラウドネイティブ情報セキュリティ

クラウドネイティブセキュリティに関するCNCFホワイトペーパーでは、さまざまな ライフサイクルフェーズ に適したセキュリティコントロールとプラクティスが定義されています。

Develop ライフサイクルフェーズ

• 開発環境の整合性を確保します。
• 状況に応じて、情報セキュリティのグッドプラクティスに沿ったアプリケーションを設計します。
• エンドユーザーのセキュリティをソリューション設計の一部として考慮します。

これを実現するためには、次のようなことができます:

1. 内部の脅威であっても、攻撃対象となる範囲を最小限に抑えるゼロトラストのようなアーキテクチャを採用します。
2. セキュリティの懸念を考慮したコードレビュープロセスを定義します。
3. システムまたはアプリケーションの 脅威モデル を作成し、信頼境界を特定します。 そのモデルを使用してリスクを特定し、それらのリスクに対処する方法を見つけるのに役立てます。
4. ファジング やセキュリティカオスエンジニアリングのような高度なセキュリティ自動化を組み込みます。

Distribute ライフサイクルフェーズ

• 実行するコンテナイメージのサプライチェーンのセキュリティを確保します。
• クラスターとその他のコンポーネントがアプリケーションを実行するためのサプライチェーンのセキュリティを確保します。 他のコンポーネントの例としては、クラウドネイティブアプリケーションが永続性のために使用する外部データベースがあります。

これを実現するためには、次のようなことができます:

1. 既知の脆弱性を持つコンテナイメージやその他のアーティファクトをスキャンします。
2. ソフトウェアのディストリビューションが、ソフトウェアのソースに対するトラストチェーンを使用して、転送中の暗号化を行うようにします。
3. 利用可能になった更新に対応するための依存関係の更新プロセスを採用し、それに従います。
4. サプライチェーンを保証するために、デジタル証明書などの検証メカニズムを使用します。
5. セキュリティリスクを通知するためのフィードや他のメカニズムにサブスクライブします。
6. アーティファクトへのアクセスを制限します。 コンテナイメージをプライベートレジストリに配置し、認証されたクライアントのみがイメージを取得できるようにします。

Deploy ライフサイクルフェーズ

何をデプロイできるか、誰がデプロイできるか、どこにデプロイできるかに関する適切な制限を確保します。 コンテナイメージアーティファクトの暗号化されたアイデンティティを検証するなど、Distribute フェーズからの対策を適用できます。

Kubernetesをデプロイすると、アプリケーションのランタイム環境の基盤、つまりKubernetesクラスター(または複数のクラスター)も設定されます。 ITインフラストラクチャは、より高いレイヤーが期待するセキュリティ保証を提供する必要があります。

Runtime ライフサイクルフェーズ

Runtimeフェーズは、コンピューティング、アクセス、およびストレージの3つの重要な領域から構成されます。

Runtime保護: アクセス

Kubernetes APIはクラスターを機能させるためのものです。 このAPIを保護することは、効果的なクラスターセキュリティを提供するための鍵となります。

Kubernetesドキュメント内の他のページでは、アクセスコントロールの特定の側面を設定する方法について詳しく説明しています。 セキュリティチェックリストには、クラスターの基本的なチェックを行うための提案が記載されています。

さらに、APIアクセスのための効果的な認証と認可を実装することがクラスターのセキュリティを確保することにつながります。 サービスアカウントを使用して、ワークロードとクラスターコンポーネントのセキュリティアイデンティティを提供および管理します。

KubernetesはTLSを使用してAPIトラフィックを保護します。 (ノードとコントロールプレーン間のトラフィックを含めて)TLSを使用してクラスターをデプロイし、暗号化キーを保護してください。 CertificateSigningRequestsにKubernetes独自のAPIを使用する場合は、その悪用を制限するために特に注意を払ってください。

Runtime保護: コンピューティング

コンテナは、異なるアプリケーション間の分離と、それらの分離されたアプリケーションを同じホストコンピューターで実行するメカニズムの2つを提供します。 これらの2つの側面、分離と集約は、ランタイムセキュリティとのトレードオフがあり、適切なバランスを見つける必要があることを意味します。

Kubernetesは実際にコンテナを設定して実行するためにコンテナランタイムに依存しています。 Kubernetesプロジェクトは特定のコンテナランタイムを推奨しておらず、選択したランタイムが情報セキュリティの要件を満たしていることを確認する必要があります。

ランタイムでコンピューティングを保護するために、次のことができます:

1. アプリケーションのPodのセキュリティ標準を強制することで、アプリケーションが必要な権限のみで実行されるようにします。

2. コンテナ化されたワークロードを実行するために、特別に設計されたオペレーティングシステムをノード上で実行します。 これは通常、コンテナの実行に不可欠なサービスのみを提供する読み取り専用オペレーティングシステム(イミュータブルイメージ)に基づいています。

   コンテナ固有のオペレーティングシステムは、システムコンポーネントを分離し、コンテナエスケープが発生した際の攻撃対象領域を減らすのに役立ちます。

3. ResourceQuotasを定義して、共有リソースを公平に割り当て、Podがリソース要件を指定できるようにするためにLimitRangesなどのメカニズムを使用します。

4. 異なるノード間でワークロードを分割します。 Kubernetes自体またはエコシステムのいずれかからノードの分離メカニズムを使用して、異なる信頼コンテキストのPodが別個のノードセットで実行されるようにします。

5. セキュリティ制約を提供するコンテナランタイムを使用します。

6. Linuxノードでは、AppArmorやseccompなどのLinuxセキュリティモジュールを使用します。

Runtime保護: ストレージ

クラスターのストレージとそこで実行されるアプリケーションの保護のために、次のことができます:

1. クラスターを、ボリューム保存時の暗号化を提供する外部ストレージプラグインと統合します。
2. APIオブジェクトの保存時の暗号化を有効にします。
3. バックアップを使用してデータの耐久性を保護します。 必要に応じていつでもこれらを復元できることを確認します。
4. クラスターノードとそれが依存するネットワークストレージ間の接続を認証します。
5. 自分自身のアプリケーション内でデータ暗号化を実装します。

暗号化キーについては、専用のハードウェア内で生成することで、漏洩リスクに対する最善の保護を提供します。 ハードウェアセキュリティモジュール を使用すると、セキュリティキーを他の場所にコピーすることなく暗号化操作を実施できます。

ネットワークとセキュリティ

ネットワークポリシーやサービスメッシュなどのネットワークセキュリティ対策の検討もまた重要です。 Kubernetesの一部のネットワークプラグインは、仮想プライベートネットワーク(VPN)オーバーレイなどの技術を使用して、クラスターネットワークの暗号化を提供します。 設計上、Kubernetesはクラスターに独自のネットワークプラグインを使用することを許可しています(マネージドKubernetesを使用している場合、クラスターを管理している個人または組織がネットワークプラグインを選択している可能性があります)。

選択したネットワークプラグインとその統合方法は、転送中の情報のセキュリティに大きな影響を与える可能性があります。

オブザーバビリティとランタイムセキュリティ

Kubernetesを使用すると、追加のツールを使用してクラスターを拡張できます。 サードパーティのソリューションをセットアップすることで、アプリケーションと実行中のクラスターを監視またはトラブルシューティングするのに役立ちます。 Kubernetes自体にもいくつかの基本的なオブザーバビリティ機能が組み込まれています。 コンテナ内で実行されるコードは、ログの生成、メトリクスの公開、その他の可観測性データの提供ができます。 デプロイ時に、クラスターが適切な保護レベルを提供していることを確認する必要があります。

メトリクスダッシュボードやそれに類似するものをセットアップする場合、そのダッシュボードにデータを投入する一連のコンポーネントと、ダッシュボード自体を確認してください。 クラスターの機能が低下するようなインシデントが発生している場合でも信頼できるように、全体のチェーンが十分な回復力と整合性保護を備えて設計されていることを確認してください。

必要に応じて、(ログや監査レコードの忠実性を確保するのに役立つ)暗号化されたメジャーブートや認証された時間配分など、Kubernetes自体よりも下位のセキュリティ対策をデプロイしてください。

高い信頼性の環境のために、ログの改ざん防止と機密性を確保するために暗号化保護をデプロイしてください。

次の項目

クラウドネイティブセキュリティ

• クラウドネイティブセキュリティに関するCNCFホワイトペーパー
• ソフトウェアサプライチェーンを保護するためのグッドプラクティスに関するCNCFホワイトペーパー
• Fixing the Kubernetes clusterf**k: Understanding security from the kernel up (FOSDEM 2020)
• Kubernetes Security Best Practices (Kubernetes Forum Seoul 2019)
• Towards Measured Boot Out of the Box (Linux Security Summit 2016)

Kubernetesと情報セキュリティ

• Kubernetesセキュリティ
• クラスターの保護
• コントロールプレーンの転送中のデータ暗号化
• 保存時のデータ暗号化
• KubernetesのSecret
• Kubernetes APIへのアクセスコントロール
• Podのネットワークポリシー
• Podセキュリティの標準
• RuntimeClass

4 - Podのセキュリティアドミッション

KubernetesのPodセキュリティの標準はPodに対して異なる分離レベルを定義します。 これらの標準によって、Podの動作をどのように制限したいかを、明確かつ一貫した方法で定義することができます。

ベータ版機能として、KubernetesはPodSecurityPolicyの後継である組み込みの Pod Security アドミッションコントローラーを提供しています。 Podセキュリティの制限は、Pod作成時に名前空間レベルで適用されます。

PodSecurityアドミッションプラグインの有効化

v1.23において、PodSecurityのフィーチャーゲートはベータ版の機能で、デフォルトで有効化されています。 v1.22において、PodSecurityのフィーチャーゲートはアルファ版の機能で、組み込みのアドミッションプラグインを使用するには、kube-apiserverで有効にする必要があります。

--feature-gates="...,PodSecurity=true"

代替案:PodSecurityアドミッションwebhookのインストール

クラスターがv1.22より古い、あるいはPodSecurity機能を有効にできないなどの理由で、ビルトインのPodSecurityアドミッションプラグインが使えない環境では、PodSecurityはアドミッションロジックはベータ版のvalidating admission webhookとしても提供されています。

ビルド前のコンテナイメージ、証明書生成スクリプト、マニフェストの例は、https://git.k8s.io/pod-security-admission/webhookで入手可能です。

インストール方法:

git clone git@github.com:kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
make certs
kubectl apply -k .

Podのセキュリティレベル

Podのセキュリティアドミッションは、PodのSecurity Contextとその他の関連フィールドに、Podセキュリティの標準で定義された3つのレベル、privileged、baseline、restrictedに従って要件を設定するものです。 これらの要件の詳細については、Podセキュリティの標準のページを参照してください。

Podの名前空間に対するセキュリティアドミッションラベル

この機能を有効にするか、Webhookをインストールすると、名前空間を設定して、各名前空間でPodセキュリティに使用したいadmission controlモードを定義できます。 Kubernetesは、名前空間に使用したい定義済みのPodセキュリティの標準レベルのいずれかを適用するために設定できるラベルのセットを用意しています。 選択したラベルは、以下のように違反の可能性が検出された場合にコントロールプレーンが取るアクションを定義します。

名前空間は、任意のまたはすべてのモードを設定することができ、異なるモードに対して異なるレベルを設定することもできます。

各モードには、使用するポリシーを決定する2つのラベルがあります。

# モードごとのレベルラベルは、そのモードに適用するポリシーレベルを示す。
#
# MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。
# LEVELは`privileged`、`baseline`、`restricted`のいずれかでなければならない。
pod-security.kubernetes.io/<MODE>: <LEVEL>

# オプション: モードごとのバージョンラベルは、Kubernetesのマイナーバージョンに同梱される
# バージョンにポリシーを固定するために使用できる（例えばv1.32など）。
#
# MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。
# VERSIONは有効なKubernetesのマイナーバージョンか`latest`でなければならない。
pod-security.kubernetes.io/<MODE>-version: <VERSION>

名前空間ラベルでのPodセキュリティの標準の適用で使用例を確認できます。

WorkloadのリソースとPodテンプレート

Podは、DeploymentやJobのようなワークロードオブジェクトを作成することによって、しばしば間接的に生成されます。 ワークロードオブジェクトは_Pod template_を定義し、ワークロードリソースのコントローラーはそのテンプレートに基づきPodを作成します。 違反の早期発見を支援するために、auditモードとwarningモードは、ワークロードリソースに適用されます。 ただし、enforceモードはワークロードリソースには適用されず、結果としてのPodオブジェクトにのみ適用されます。

適用除外(Exemption)

Podセキュリティの施行から exemptions を定義することで、特定の名前空間に関連するポリシーのために禁止されていたPodの作成を許可することができます。 Exemptionはアドミッションコントローラーの設定で静的に設定することができます。

Exemptionは明示的に列挙する必要があります。 Exemptionを満たしたリクエストは、アドミッションコントローラーによって 無視 されます(enforce、audit、warnのすべての動作がスキップされます)。Exemptionの次元は以下の通りです。

• Usernames: 認証されていない(あるいは偽装された)ユーザー名を持つユーザーからの要求は無視されます。
• RuntimeClassNames: Podとワークロードリソースで指定された除外ランタイムクラス名は、無視されます。
• Namespaces: 除外された名前空間のPodとワークロードリソースは、無視されます。

以下のPodフィールドに対する更新は、ポリシーチェックの対象外となります。つまり、Podの更新要求がこれらのフィールドを変更するだけであれば、Podが現在のポリシーレベルに違反していても拒否されることはありません。

• すべてのメタデータの更新(seccompまたはAppArmorアノテーションへの変更を除く)
  • seccomp.security.alpha.kubernetes.io/pod(非推奨)
  • container.seccomp.security.alpha.kubernetes.io/*(非推奨)
  • container.apparmor.security.beta.kubernetes.io/*
• .spec.activeDeadlineSecondsに対する有効な更新
• .spec.tolerationsに対する有効な更新

次の項目

• Podセキュリティの標準
• Podセキュリティの標準の適用
• ビルトインのアドミッションコントローラーの設定によるPodセキュリティの標準の適用
• 名前空間ラベルでのPodセキュリティの標準の適用
• PodSecurityPolicyからビルトインのPodSecurityアドミッションコントローラーへの移行

5 - サービスアカウント

このページではKubernetesのServiceAccountオブジェクトについて説明し、どのようにサービスアカウントが機能するか、使用例、制限、代替手段、追加のガイダンスとなるリソースへのリンクを紹介します。

サービスアカウントとは？

サービスアカウントは、Kubernetesにおいて、Kubernetesクラスター内で固有のアイデンティティを提供する人間以外のアカウントの一種です。 アプリケーションPod、システムコンポーネント、およびクラスター内外のエンティティは、特定のServiceAccountの認証情報を使用してそのServiceAccountとして識別できます。 このアイデンティティは、APIサーバーへの認証やアイデンティティベースのセキュリティポリシーの実装など、さまざまな状況で役立ちます。

サービスアカウントは、APIサーバー内のServiceAccountオブジェクトとして存在します。 サービスアカウントには次の特性があります:

• Namespaced: 各サービスアカウントはKubernetesのnamespaceにバインドされます。 各namespaceは作成時にdefault ServiceAccountを取得します。

• Lightweight: サービスアカウントはクラスター内に存在し、Kubernetes APIで定義されています。 特定のタスクを有効にするためにサービスアカウントを素早く作成できます。

• Portable: 複雑なコンテナ化されたワークロードの構成バンドルには、システムのコンポーネントのサービスアカウント定義が含まれる場合があります。 サービスアカウントの軽量性と名前空間内のアイデンティティは、構成をポータブルにします。

サービスアカウントは、クラスター内の認証された人間のユーザーであるユーザーアカウントとは異なります。 デフォルトでは、KubernetesのAPIサーバーにユーザーアカウントは存在しません。代わりに、APIサーバーはユーザーのアイデンティティを不透明なデータとして扱います。 複数の方法を使用して、ユーザーアカウントとして認証できます。 一部のKubernetesディストリビューションでは、APIサーバーでユーザーアカウントを表すカスタム拡張APIが追加されることがあります。

デフォルトのサービスアカウント

クラスターを作成すると、Kubernetesはクラスター内の各Namespaceに対してdefaultという名前のServiceAccountオブジェクトを自動的に作成します。 各Namespaceのdefaultサービスアカウントは、ロールベースのアクセス制御(RBAC)が有効になっている場合、Kubernetesがすべての認証されたプリンシパルに付与するデフォルトのAPI検出権限以外の権限をデフォルトで取得しません。 Namespace内のdefault ServiceAccountオブジェクトを削除すると、コントロールプレーンが新しいServiceAccountオブジェクトを作成します。

NamespaceにPodをデプロイし、Podに手動でServiceAccountを割り当てない場合、KubernetesはそのNamespaceのdefault ServiceAccountをPodに割り当てます。

Kubernetesサービスアカウントの使用例

一般的なガイドラインとして、次のシナリオでサービスアカウントを使用できます:

• PodがKubernetes APIサーバーと通信する必要がある場合、例えば次のような場合です:
  • Secretに保存されている機密情報への読み取り専用アクセスを提供します。
  • Namespaceをまたいだアクセスを許可します。例えば、example NamespaceのPodがkube-node-lease NamespaceのLeaseオブジェクトを読み取り、一覧、監視することを許可します。
• Podが外部のサービスと通信する必要がある場合。例えば、ワークロードのPodには商用クラウドAPIのアイデンティティが必要であり、商用プロバイダーは適切な信頼関係の構成を許可する場合です。
• imagePullSecretを使用してプライベートイメージレジストリに認証する場合。
• 外部サービスがKubernetes APIサーバーと通信する必要がある場合。例えば、CI/CDパイプラインの一部としてクラスターに認証する必要がある場合です。
• クラスター内でサードパーティのセキュリティソフトウェアを使用する場合。さまざまなPodのServiceAccountアイデンティティを使用してこれらのPodを異なるコンテキストにグループ化します。

サービスアカウントの使用方法

Kubernetesサービスアカウントを使用するには、次の手順を実行します:

1. kubectlなどのKubernetesクライアントを使用してServiceAccountオブジェクトを作成するか、オブジェクトを定義するマニフェストを使用します。

2. RBACなどの認可メカニズムを使用してServiceAccountオブジェクトに権限を付与します。

3. Podの作成時にServiceAccountオブジェクトをPodに割り当てます。

   外部サービスからのアイデンティティを使用している場合は、ServiceAccountトークンを取得し、そのサービスから使用します。

詳細な手順については、PodにServiceAccountを割り当てるを参照してください。

ServiceAccountに権限を付与する

各ServiceAccountに必要な最小限の権限を付与するために、Kubernetesビルトインのロールベースのアクセス制御(RBAC)メカニズムを使用できます。 ServiceAccountにアクセスを付与するロールを作成し、そのロールをServiceAccountにバインドします。 RBACを使用すると、ServiceAccountの権限が最小限になるように定義できます。 PodがそのServiceAccountを使用している場合、そのPodは正しく機能するために必要な権限以上の権限を取得しません。

詳細な手順については、ServiceAccount権限を参照してください。

ServiceAccountを使用したNamespace間のアクセス

RBACを使用して、クラスターの異なるNamespaceにあるリソースに対して別のNamespaceのServiceAccountがアクションを実行できるようにすることができます。 例えば、dev NamespaceにサービスアカウントとPodがあり、そのPodがmaintenance Namespaceで実行されているJobを見る必要がある場合を考えてみましょう。 Jobオブジェクトをリストする権限を付与するRoleオブジェクトを作成できます。 次に、そのRoleをmaintenance NamespaceのServiceAccountオブジェクトにバインドするRoleBindingオブジェクトを作成します。 そうすることで、dev NamespaceのPodは、そのServiceAccountを使用してmaintenance NamespaceのJobオブジェクトをリストできます。

PodにServiceAccountを割り当てる

ServiceAccountをPodに割り当てるには、Podの仕様にあるspec.serviceAccountNameフィールドを設定します。 Kubernetesは、そのServiceAccountの認証情報をPodに自動的に提供します。 v1.22以降では、KubernetesはTokenRequest APIを使用して有効期間が短く自動的にローテーションされるトークンを取得し、そのトークンを投影ボリュームとしてPodにマウントします。

デフォルトではKubernetesは、ServiceAccountがdefault ServiceAccountか指定したカスタムServiceAccountであるかに関わらず、PodにそのServiceAccountの認証情報を提供します。

Kubernetesが指定されたServiceAccountまたはdefault ServiceAccountの認証情報を自動的に注入しないようにするには、Podの使用にあるautomountServiceAccountTokenフィールドをfalseに設定します。

1.22より前のバージョンでは、Kubernetesは有効期間の長い静的なトークンをSecretとしてPodに提供します。

ServiceAccount認証情報の手動取得

ServiceAccountを標準以外の場所にマウントするための認証情報、またはAPIサーバー以外の対象向けの認証情報が必要な場合は、次のいずれかの方法を使用します:

• TokenRequest API (推奨): 独自のアプリケーションコードから短期間のサービスアカウントトークンをリクエストします。 トークンは自動的に期限切れになり、期限切れ時にローテーションできます。 Kubernetesに対応していないレガシーアプリケーションがある場場合、同じPod内のサイドカーコンテナを使用してこれらのトークンを取得し、アプリケーションワークロードで使用できるようにすることができます。
• トークン投影ボリューム (推奨): Kubernetes v1.20以降では、Podの仕様を使用して、kubeletにサービスアカウントトークンを投影ボリュームとしてPodに追加するように指示します。 投影トークンは自動的に期限切れになり、kubeletはトークンが期限切れになる前にトークンをローテーションします。
• サービスアカウントトークンシークレット（Kubernetes v1.24からv1.26ではデフォルトで有効） (非推奨): サービスアカウントトークンをKubernetes SecretとしてPodにマウントできます。 これらのトークンは期限切れになることも、ローテーションされることもありません。 v1.24以前のバージョンでは、サービスアカウントごとに永続的なトークンが自動的に作成されていました。 この方法は、静的で有効期間の長い認証情報に関するリスクがあるため、特に大規模な環境では推奨されなくなりました。 LegacyServiceAccountTokenNoAutoGenerationフィーチャーゲートにより、Kubernetesが指定されたServiceAccountに対してこれらのトークンを自動的に作成するのを防止できました。 このフィーチャーゲートはGAステータスに昇格したため、v1.27では削除されました。 無期限のサービスアカウントトークンを手動で作成することは引き続き可能ですが、セキュリティ上の影響を考慮する必要があります。

シークレットへのアクセスを制限する

Kubernetesは、ServiceAccountに追加できるkubernetes.io/enforce-mountable-secretsというアノテーションを提供しています。 このアノテーションを適用すると、ServiceAccountのシークレットは指定された種類のリソースにのみマウントできるため、クラスターのセキュリティ体制が強化されます。

マニフェストを使用してServiceAccountにアノテーションを追加できます:

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: my-serviceaccount
  namespace: my-namespace

このアノテーションが"true"に設定されている場合、Kubernetesコントロールプレーンは、このServiceAccountのSecretが特定のマウント制限の対象であることを確認します。

1. Pod内のボリュームとしてマウントされる各Secretのな雨は、PodのServiceAccountのsecretsフィールドに表示される必要があります。
2. Pod内のenvFromを使用して参照される各Secretの名前は、PodのServiceAccountのsecretsフィールドに表示される必要があります。
3. Pod内のimagePullSecretsを使用して参照される各Secretの名前は、PodのServiceAccountのsecretsフィールドに表示される必要があります。

これらの制限を理解して適用することで、クラスター管理者はより厳格なセキュリティプロファイルを維持し、適切なリソースのみがシークレットにアクセスできるようにします。

サービスアカウント認証情報の認証

ServiceAccountは、Kubernetes APIサーバーおよび信頼関係が存在する他のシステムに対して、署名されたJSON Web Tokens (JWTs) を使用して認証を行います。 トークンの発行方法(TokenRequestを使用して時間制限付きで発行されるか、Secretを使用して従来のメカニズムで発行されるか)に応じて、ServiceAccountトークンには有効期限、オーディエンス、トークンが有効になる時間などが含まれる場合があります。 ServiceAccountとして機能しているクライアントがKubernetes APIサーバーと通信しようとすると、クライアントはHTTPリクエストにAuthorization: Bearer <token>ヘッダーを含めます。 APIサーバーは、次のようにしてBearerトークンの有効性を確認します:

1. トークンの署名を確認します。
2. トークンが期限切れかどうかを確認します。
3. トークン要求内のオブジェクト参照が現在有効かどうかを確認します。
4. トークンが現在有効かどうかを確認します。
5. オーディエンス要求を確認します。

TokenRequest APIは、ServiceAccountに バインドされたトークン を生成します。 このバインディングは、そのServiceAccountとして機能しているクライアント(Podなど)のライフタイムにリンクされています バインドされたPodのサービスアカウントトークンのJWTスキーマとペイロードの例については、トークンボリューム投影を参照してください。

TokenRequest APIを使用して発行されたトークンの場合、APIサーバーは、そのオブジェクトの ユニークID と一致する、ServiceAccountを使用している特定のオブジェクト参照がまだ存在するかどうかも確認します。 PodにSecretとしてマウントされているレガシートークンの場合、APIサーバーはトークンをSecretと照合します。

認証プロセスの詳細については、認証を参照してください。

独自のコードでサービスアカウントの認証情報を認証する

Kubernetesサービスアカウントの認証情報の検証が必要なサービスがある場合、次の方法を使用できます:

• TokenReview API (推奨)
• OIDC検出

Kubernetesプロジェクトでは、TokenReview APIの使用を推奨しており、この方法ではSecret、ServiceAccount、Pod、NodeなどのAPIオブジェクトにバインドされたトークンが削除されると、そのトークンが無効になります。 例えば、投影されたServiceAccountトークンを含むPodを削除すると、クラスターはただちにそのトークンを無効にし、TokenReviewはただちに失敗します。 代わりにOIDC認証を使用する場合、トークンが有効期限のタイムスタンプに達するまで、クライアントはトークンを有効なものとして扱い続けます。

アプリケーションでは、受け入れるオーディエンスを常に定義し、トークンのオーディエンスがアプリケーションが期待するオーディエンスと一致するかどうかを確認する必要があります。 これにより、トークンのスコープが最小限に抑えられ、アプリケーション内でのみ使用でき、他の場所では使用できないようになります。

代替案

• 別のメカニズムを使用して独自のトークンを発行し、Webhookトークン認証を使用して、独自の検証サービスを使用してBearerトークンを検証します。
• Podに独自のアイデンティティを提供します。

  • SPIFFE CSIドライバープラグインを使用して、SPIFFE SVID をX.509証明書ペアとしてPodに提供します。

    🛇 This item links to a third party project or product that is not part of Kubernetes itself. More information

  • Istioなどのサービスメッシュを使用してPodに証明書を提供します。

• サービスアカウントトークンを使用せずに、クラスター外部からAPIサーバーに認証します:
  • IDプロバイダーからのOpenID Connect (OIDC)トークンを受け入れるようにAPIサーバーを構成します。
  • クラウドプロバイダーなどの外部のIdentity and Access Management (IAM)サービスを使用して作成されたサービスアカウントまたはユーザーアカウントを使用して、クラスターに認証します。
  • クライアント証明書でCertificateSigningRequest APIを使用します。
• イメージレジストリから認証情報を取得するようにkubeletを構成する.
• Device Pluginを使用して仮想Trusted Platform Module (TPM)にアクセスし、秘密鍵を使用した認証を許可します。

次の項目

• クラスターの管理者としてServiceAccountを管理する方法を学ぶ
• PodにServiceAccountを割り当てる方法を学ぶ
• ServiceAccount APIリファレンスを読む

6 - Kubernetes APIへのアクセスコントロール

このページではKubernetes APIへのアクセスコントロールの概要を説明します。

Kubernetes APIにはkubectlやクライアントライブラリ、あるいはRESTリクエストを用いてアクセスします。 APIアクセスには、人間のユーザーとKubernetesサービスアカウントの両方が認証可能です。 リクエストがAPIに到達すると、次の図のようにいくつかの段階を経ます。

トランスポート層のセキュリティ

一般的なKubernetesクラスターでは、APIはTLSで保護された443番ポートで提供されます。 APIサーバーは証明書を提示します。 この証明書は、プライベート認証局(CA)を用いて署名することも、一般に認知されているCAと連携した公開鍵基盤に基づき署名することも可能です。

クラスターがプライベート認証局を使用している場合、接続を信頼し、傍受されていないと確信できるように、クライアント上の~/.kube/configに設定されたそのCA証明書のコピーが必要です。

クライアントは、この段階でTLSクライアント証明書を提示することができます。

認証

TLSが確立されると、HTTPリクエストは認証のステップに移行します。 これは図中のステップ1に該当します。 クラスター作成スクリプトまたはクラスター管理者は、1つまたは複数のAuthenticatorモジュールを実行するようにAPIサーバーを設定します。 Authenticatorについては、認証で詳しく説明されています。

認証ステップへの入力はHTTPリクエスト全体ですが、通常はヘッダとクライアント証明書の両方、またはどちらかを調べます。

認証モジュールには、クライアント証明書、パスワード、プレーントークン、ブートストラップトークン、JSON Web Tokens(サービスアカウントに使用)などがあります。

複数の認証モジュールを指定することができ、その場合、1つの認証モジュールが成功するまで、それぞれを順番に試行します。

認証できない場合、HTTPステータスコード401で拒否されます。 そうでなければ、ユーザーは特定のusernameとして認証され、そのユーザー名は後続のステップでの判断に使用できるようになります。 また、ユーザーのグループメンバーシップを提供する認証機関と、提供しない認証機関があります。

Kubernetesはアクセスコントロールの決定やリクエストログにユーザー名を使用しますが、Userオブジェクトを持たず、ユーザー名やその他のユーザーに関する情報をAPIはに保存しません。

認可

リクエストが特定のユーザーからのものであると認証された後、そのリクエストは認可される必要があります。 これは図のステップ2に該当します。

リクエストには、リクエスト者のユーザー名、リクエストされたアクション、そのアクションによって影響を受けるオブジェクトを含める必要があります。 既存のポリシーで、ユーザーが要求されたアクションを完了するための権限を持っていると宣言されている場合、リクエストは承認されます。

例えば、Bobが以下のようなポリシーを持っている場合、彼は名前空間projectCaribou内のPodのみを読むことができます。

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "projectCaribou",
        "resource": "pods",
        "readonly": true
    }
}

Bobが次のようなリクエストをした場合、Bobは名前空間projectCaribouのオブジェクトを読むことが許可されているので、このリクエストは認可されます。

{
  "apiVersion": "authorization.k8s.io/v1beta1",
  "kind": "SubjectAccessReview",
  "spec": {
    "resourceAttributes": {
      "namespace": "projectCaribou",
      "verb": "get",
      "group": "unicorn.example.org",
      "resource": "pods"
    }
  }
}

Bobが名前空間projectCaribouのオブジェクトに書き込み(createまたはupdate)のリクエストをした場合、承認は拒否されます。 また、もしBobがprojectFishのような別の名前空間にあるオブジェクトを読み込む(get)リクエストをした場合も、承認は拒否されます。

Kubernetesの認可では、組織全体またはクラウドプロバイダー全体の既存のアクセスコントロールシステムと対話するために、共通のREST属性を使用する必要があります。 これらのコントロールシステムは、Kubernetes API以外のAPIとやり取りする可能性があるため、REST形式を使用することが重要です。

Kubernetesは、ABACモード、RBACモード、Webhookモードなど、複数の認可モジュールをサポートしています。 管理者はクラスターを作成する際に、APIサーバーで使用する認証モジュールを設定します。 複数の認可モジュールが設定されている場合、Kubernetesは各モジュールをチェックし、いずれかのモジュールがリクエストを認可した場合、リクエストを続行することができます。 すべてのモジュールがリクエストを拒否した場合、リクエストは拒否されます(HTTPステータスコード403)。

サポートされている認可モジュールを使用したポリシー作成の詳細を含む、Kubernetesの認可については、認可を参照してください。

アドミッションコントロール

アドミッションコントロールモジュールは、リクエストを変更したり拒否したりすることができるソフトウェアモジュールです。 認可モジュールが利用できる属性に加えて、アドミッションコントロールモジュールは、作成または修正されるオブジェクトのコンテンツにアクセスすることができます。

アドミッションコントローラーは、オブジェクトの作成、変更、削除、または接続(プロキシ)を行うリクエストに対して動作します。 アドミッションコントローラーは、単にオブジェクトを読み取るだけのリクエストには動作しません。 複数のアドミッションコントローラーが設定されている場合は、順番に呼び出されます。

これは図中のステップ3に該当します。

認証・認可モジュールとは異なり、いずれかのアドミッションコントローラーモジュールが拒否した場合、リクエストは即座に拒否されます。

オブジェクトを拒否するだけでなく、アドミッションコントローラーは、フィールドに複雑なデフォルトを設定することもできます。

利用可能なアドミッションコントロールモジュールは、アドミッションコントローラーに記載されています。

リクエストがすべてのアドミッションコントローラーを通過すると、対応するAPIオブジェクトの検証ルーチンを使って検証され、オブジェクトストアに書き込まれます(図のステップ4に該当します)。

監査

Kubernetesの監査は、クラスター内の一連のアクションを文書化した、セキュリティに関連する時系列の記録を提供します。 クラスターは、ユーザー、Kubernetes APIを使用するアプリケーション、およびコントロールプレーン自身によって生成されるアクティビティを監査します。

詳しくは監査をご覧ください。

APIサーバーのIPとポート

これまでの説明は、APIサーバーのセキュアポートに送信されるリクエストに適用されます(典型的なケース)。 APIサーバーは、実際には2つのポートでサービスを提供することができます。

デフォルトでは、Kubernetes APIサーバーは2つのポートでHTTPを提供します。

1. localhostポート:

   • テストとブートストラップ用で、マスターノードの他のコンポーネント(スケジューラー、コントローラーマネージャー)がAPIと通信するためのものです。
   • TLSは使用しません。
   • デフォルトポートは8080です。
   • デフォルトのIPはlocalhostですが、--insecure-bind-addressフラグで変更することができます。
   • リクエストは認証と認可のモジュールをバイパスします。
   • リクエストは、アドミッションコントロールモジュールによって処理されます。
   • ホストにアクセスする必要があるため、保護されています。

2. “セキュアポート”:

   • 可能な限りこちらを使用してください。
   • TLSを使用します。証明書は--tls-cert-fileフラグで、鍵は--tls-private-key-fileフラグで設定します。
   • デフォルトポートは6443です。--secure-portフラグで変更することができます。
   • デフォルトのIPは、最初の非localhostのネットワークインターフェースです。--bind-addressフラグで変更することができます。
   • リクエストは、認証・認可モジュールによって処理されます。
   • リクエストは、アドミッションコントロールモジュールによって処理されます。
   • 認証・認可モジュールが実行されます。

次の項目

認証、認可、APIアクセスコントロールに関する詳しいドキュメントはこちらをご覧ください。

• 認証
  • ブートストラップトークンでの認証
• アドミッションコントローラー
  • 動的アドミッションコントロール
• 認可
  • ロールに基づいたアクセスコントロール
  • 属性に基づいたアクセスコントロール
  • Nodeの認可
  • Webhookの認可
• 証明書の署名要求
  • CSRの承認と証明書の署名を含む
• サービスアカウント
  • Developer guide
  • Administration

以下についても知ることができます。

• PodがAPIクレデンシャルを取得するためにSecretsを使用する方法について。

7 - ロールベースアクセスコントロールのグッドプラクティス

Kubernetes RBACは、クラスターユーザーやワークロードがその役割を果たすために、必要なリソースへのアクセスしかできないようにするための重要なセキュリティコントロールです。 クラスターユーザーの権限を設計する際には、クラスター管理者が特権昇格が発生しうる領域を理解し、セキュリティインシデントを引き起こすリスクを減らすことが重要です。

ここで説明するグッドプラクティスは、一般的なRBACドキュメントと併せて読むことを推奨します。

一般的なグッドプラクティス

最小特権の原則

理想的には、ユーザーやサービスには最小限の権限のみ割り当てるべきです。 権限は、その操作に明示的に必要なものだけを使用するべきです。 クラスターによって異なりますが、一般的なルールは次のとおりです:

• 可能であれば、namespaceレベルで権限を割り当てます。 特定のnamespace内でのみユーザーに権限を与えるため、ClusterRoleBindingsではなくRoleBindingsを使用します。
• 可能であれば、ワイルドカード権限を提供しないでください。特に全てのリソースへの権限を提供しないでください。 Kubernetesは拡張可能なシステムであるため、ワイルドカードアクセスを提供すると、クラスター内に現存するすべてオブジェクトタイプだけでなく、将来作成されるすべてのオブジェクトタイプにも権限が与えられてしまいます。
• 管理者は特に必要でない限り、cluster-adminアカウントを使用すべきではありません。 権限の低いアカウントに偽装権限を提供することで、クラスターリソースの誤った変更を回避できます。
• system:mastersグループにユーザーを追加しないでください。 このグループのメンバーであるユーザーは、すべてのRBAC権限をバイパスし、常に制限のないスーパーユーザーアクセス権限を持ちます。この権限はRoleBindingsまたはClusterRoleBindingsを削除しても取り消すことができません。 余談ですが、クラスターが認可ウェブフックを使用している場合、このグループのメンバーシップもそのウェブフックをバイパスします(そのグループのメンバーであるユーザーからのリクエストがウェブフックに送信されることはありません)

特権トークンの配布を最小限に抑える

理想的には、Podには強力な権限が付与されたサービスアカウントを割り当てられるべきではありません。 (例えば、特権昇格リスクにリストされている権限)。 強力な権限が必要な場合は、次のプラクティスを検討してください:

• 強力なPodを実行するノードの数を制限します。 実行する任意のDaemonSetが必要であることを確認し、コンテナエスケープの影響範囲を制限するために最小限の権限で実行されるようにします。
• 信頼できない、または公開されたPodと強力なPodを一緒に実行しないようにする。 信頼できない、または信頼度の低いPodと一緒に実行されないようにするために、TaintsとToleration、NodeAffinity、またはPodAntiAffinityの使用を検討してください。 信頼性の低いPodが制限付きPodセキュリティ標準を満たしていない場合は、特に注意してください。

強化

Kubernetesは、すべてのクラスターに必要とは限らないアクセスをデフォルトで提供します。 デフォルトで提供されるRBAC権限を確認することで、セキュリティを強化する機会が得られます。 一般的に、system:アカウントに提供される権限を変更するべきではありませんが、クラスター権限を強化するためのオプションがいくつか存在します:

• system:unauthenticatedグループのバインディングを確認し、可能であれば削除します。 これにより、ネットワークレベルでAPIサーバーに接続できるすべてのユーザーにアクセスが許可されます。
• automountServiceAccountToken: falseを設定することで、サービスアカウントトークンのデフォルトの自動マウントを回避します。 詳細については、デフォルトのサービスアカウントトークンの使用を参照してください。 Podにこの値を設定すると、サービスアカウント設定が上書きされ、サービスアカウントトークンを必要とするワークロードは引き続きそれをマウントできます。

定期的なレビュー

冗長なエントリや特権昇格の可能性がないか、定期的にKubernetes RBAC設定を確認することが不可欠です。 攻撃者が削除されたユーザーと同じ名前のユーザーアカウントを作成できる場合、特にそのユーザーに割り当てられた権限を自動的に継承できます。

Kubernetes RBAC - 特権昇格リスク　

Kubernetes RBAC内には、ユーザーやサービスアカウントがクラスター内で特権昇格したり、クラスター外のシステムに影響を与えたりすることができる権限がいくつかあります。

このセクションは、クラスター運用者が意図した以上のクラスターへのアクセスを誤って許可しないようにするために注意を払うべき領域を示すことを目的としています。

Secretのリスト

一般に、Secretに対するgetアクセスを許可すると、ユーザーがその内容を読むことができることは明らかです。 また、listおよびwatchアクセスも、ユーザーがSecretの内容を読むことを事実上可能にします。

例えば、Listレスポンスが返却される(例: kubectl get secrets -A -o yaml)と、そのレスポンスにはすべてのSecretの内容が含まれます。

ワークロードの作成

Namespace内でワークロード(PodやPodを管理するワークロードリソース)を作成する権限により、そのnamespace内のSecret、ConfigMap、PersistentVolumeなどのPodにマウントできる他の多くのリソースへのアクセスが暗黙的に許可されます。 さらに、Podは任意のServiceAccountとして実行できるため、ワークロードを作成する権限もまた、そのnamespace内の任意のサービスアカウントのAPIアクセスレベルを暗黙的に許可します。

特権付きPodを実行できるユーザーは、そのアクセス権を使用してノードへのアクセスを取得し、さらに特権昇格させる可能性があります。 適切に安全で隔離されたPodを作成できるユーザーや他のプリンシパルを完全に信頼していない場合は、ベースラインまたは制限付きPodセキュリティ標準を強制する必要があります。 Podのセキュリティアドミッションや他の(サードパーティ)メカニズムを使用して、その強制を実装できます。

これらの理由から、namespaceは異なる信頼レベルやテナンシーを必要とするリソースを分離するために使用されるべきです。 最小特権の原則に従い、最小限の権限セットを割り当てることがベストプラクティスとされていますが、namespace内の境界は弱いと考えるべきです。

永続ボリュームの作成

誰か、または何らかのアプリケーションが、任意のPersistentVolumeを作成する権限を持っている場合、そのアクセスにはhostPathボリュームの作成も含まれており、これはPodが関連づけられたノードの基盤となるホストファイルシステムにアクセスできることを意味します。 その権限を与えることはセキュリティリスクとなります。

ホストファイルシステムに制限のないアクセス権を持つコンテナが特権昇格する方法は数多くあり、これには他のコンテナからのデータの読み取りや、Kubeletなどのシステムサービスの資格情報の悪用が含まれます。

PersistentVolumeオブジェクトを作成する権限を許可するのは、次の場合に限定するべきです:

• ユーザー(クラスター運用者)が、作業にこのアクセスを必要としており、かつ信頼できる場合。
• 自動プロビジョニングのために設定されたPersistentVolumeClaimに基づいてPersistentVolumeを作成するKubernetesコントロールコンポーネント。 これは通常、KubernetesプロバイダーまたはCSIドライバーのインストール時に設定されます。

永続ストレージへのアクセスが必要な場合、信頼できる管理者がPersistentVolumeを作成し、制約のあるユーザーはPersistentVolumeClaimを使用してそのストレージにアクセスするべきです。

ノードのproxyサブリソースへのアクセス

ノードオブジェクトのプロキシサブリソースへのアクセス権を持つユーザーは、Kubelet APIに対する権限を持ち、権限を持つノード上のすべてのPodでコマンドを実行できます。 このアクセスは監査ログやアドミッションコントロールをバイパスするため、このリソースに権限を付与する際には注意が必要です。

Escalate動詞

一般的に、RBACシステムはユーザーが所有する権限以上のクラスターロールを作成できないようにします。 この例外はescalate動詞です。 RBACのドキュメントに記載されているように、この権限を持つユーザーは事実上特権昇格させることができます。

Bind動詞

escalate動詞と同様に、ユーザーにこの権限を付与すると、特権昇格に対するKubernetesビルトインの保護をバイパスし、ユーザーがすでに持っていない権限を持つロールへのバインディングを作成できるようになります。

Impersonate動詞

この動詞は、ユーザーがクラスター内の他のユーザーになりすまし、そのユーザーの権限を取得することを可能にします。 権限を付与する場合は、なりすましアカウントを介して過剰な権限を取得できないように注意する必要があります。

CSRと証明書の発行

CSR APIは、CSRに対するcreate権限とkubernetes.io/kube-apiserver-clientを署名者とするcertificatesigningrequests/approvalに対するupdate権限を持つユーザーが、クラスターに対して認証するための新しいクライアント証明書を作成できるようにします。 これらのクライアント証明書は、Kubernetesシステムコンポーネントの重複を含む任意の名前を持つことができます。 これにより、特権昇格が可能になります。

トークンリクエスト

serviceaccounts/tokenに対するcreate権限を持つユーザーは、既存のサービスアカウント用のトークンを発行するためのTokenRequestsを作成できます。

アドミッションウェブフックの制御

validatingwebhookconfigurationsまたはmutatingwebhookconfigurationsを制御するユーザーは、クラスターに許可された任意のオブジェクトを読み取ることができるウェブフックを制御し、ウェブフックを変更する場合は許されたオブジェクトも変更できます。

Namespaceの変更

Namespaceオブジェクトにおいてpatch操作を実行できるユーザーは(そのアクセス権を持つロールへのnamespace付きのRoleBindingを通じて)namespaceのラベルを変更できます。 Podのセキュリティアドミッションが使用されているクラスターでは、ユーザーは管理者が意図したより緩いポリシーをnamespaceに設定できる場合があります。 NetworkPolicyが使用されているクラスターでは、ユーザーは管理者が意図していないサービスへのアクセスを間接的に許可するラベルを設定できる場合があります。

Kubernetes RBAC - サービス拒否リスク

オブジェクト作成によるサービス拒否

クラスター内のオブジェクトを作成する権限を持つユーザーは、etcd used by Kubernetes is vulnerable to OOM attackで議論されているように、オブジェクトのサイズや数に基づいてサービス拒否を引き起こすほど大きなオブジェクトを作成できる可能性があります。 これは、半信頼または信頼されていないユーザーにシステムへの限定的なアクセスが許可されている場合、特にマルチテナントクラスターに関係する可能性があります。

この問題を緩和するための1つのオプションとして、リソースクォータを使用して作成可能なオブジェクトの量を制限することが考えられます。

次の項目

• RBACについてさらに詳しく知るには、RBACのドキュメントを参照してください。

8 - Kubernetes Secretの適切な使用方法

Kubernetesでは、Secretは次のようなオブジェクトです。 パスワードやOAuthトークン、SSHキーのような機密の情報を保持します。

Secretは、機密情報の使用方法をより管理しやすくし、偶発的な漏洩のリスクを減らすことができます。Secretの値はbase64文字列としてエンコードされ、デフォルトでは暗号化されずに保存されますが、保存時に暗号化するように設定することもできます。

Podは、ボリュームマウントや環境変数など、さまざまな方法でSecretを参照できます。Secretは機密データ用に設計されており、ConfigMapは非機密データ用に設計されています。

以下の適切な使用方法は、クラスター管理者とアプリケーション開発者の両方を対象としています。 これらのガイドラインに従って、Secretオブジェクト内の機密情報のセキュリティを向上させ、Secretの効果的な管理を行ってください。

クラスター管理者

このセクションでは、クラスター管理者がクラスター内の機密情報のセキュリティを強化するために使用できる適切な方法を提供します。

データ保存時の暗号化を構成する

デフォルトでは、Secretオブジェクトはetcd内で暗号化されていない状態で保存されます。 etcd内のSecretデータを暗号化するように構成する必要があります。 手順については、機密データ保存時の暗号化を参照してください。

Secretへの最小特権アクセスを構成する

Kubernetesのロールベースアクセス制御 (RBAC)などのアクセス制御メカニズムを計画する際、Secretオブジェクトへのアクセスに関する以下のガイドラインを考慮してください。 また、RBACの適切な使用方法の他のガイドラインにも従ってください。

• コンポーネント: watchまたはlistアクセスを、最上位の特権を持つシステムレベルのコンポーネントのみに制限してください。コンポーネントの通常の動作が必要とする場合にのみ、Secretへのgetアクセスを許可してください。
• ユーザー: Secretへのget、watch、listアクセスを制限してください。etcdへのアクセスはクラスター管理者にのみ許可し、読み取り専用アクセスも許可してください。特定の注釈を持つSecretへのアクセスを制限するなど、より複雑なアクセス制御については、サードパーティの認証メカニズムを検討してください。

Secretを使用するPodを作成できるユーザーは、そのSecretの値も見ることができます。 クラスターのポリシーがユーザーにSecretを直接読むことを許可しない場合でも、同じユーザーがSecretを公開するPodを実行するアクセスを持つかもしれません。 このようなアクセスを持つユーザーによるSecretデータの意図的または偶発的な公開の影響を検出または制限することができます。 いくつかの推奨事項には以下があります:

• 短寿命のSecretを使用する
• 特定のイベントに対してアラートを出す監査ルールを実装する(例:単一ユーザーによる複数のSecretの同時読み取り)

etcdの管理ポリシーを改善する

使用しなくなった場合には、etcdが使用する永続ストレージを削除するかシュレッダーで処理してください。

複数のetcdインスタンスがある場合、インスタンス間の通信を暗号化されたSSL/TLS通信に設定して、転送中のSecretデータを保護してください。

外部Secretへのアクセスを構成する

外部のSecretストアプロバイダーを使用して機密データをクラスターの外部に保存し、その情報にアクセスするようにPodを構成できます。 Kubernetes Secrets Store CSI Driverは、kubeletが外部ストアからSecretを取得し、データにアクセスすることを許可された特定のPodにSecretをボリュームとしてマウントするDaemonSetです。

サポートされているプロバイダーの一覧については、Secret Store CSI Driverのプロバイダーを参照してください。

開発者

このセクションでは、Kubernetesリソースの作成と展開時に機密データのセキュリティを向上させるための開発者向けの適切な使用方法を提供します。

特定のコンテナへのSecretアクセスを制限する

Pod内で複数のコンテナを定義し、そのうち1つのコンテナだけがSecretへのアクセスを必要とする場合、他のコンテナがそのSecretにアクセスできないようにボリュームマウントや環境変数の設定を行ってください。

読み取り後にSecretデータを保護する

アプリケーションは、環境変数やボリュームから機密情報を読み取った後も、その値を保護する必要があります。 例えば、アプリケーションは機密情報を平文でログに記録したり、信頼できない第三者に送信したりしないようにする必要があります。

Secretマニフェストの共有を避ける

Secretをマニフェストを介して設定し、秘密データをBase64でエンコードしている場合、このファイルを共有したりソースリポジトリにチェックインしたりすると、その秘密はマニフェストを読むことのできる全員に公開されます。