"導入"

Kubernetesは、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。サービスディスカバリ、ロードバランシング、オートスケーリングなど、豊富な機能を備えています。クラウドネイティブ分野でKubernetesが広く採用されるにつれ、 「Kubernetesクラスター上で誰がどのような操作を実行できるかを効果的に管理する」ことが非常に重要になっています。この記事では、Kubernetesの認証・認可システムとRBAC認可の原則について簡単に説明します。また、実例を通して、不適切なRBAC管理がもたらすセキュリティリスクを明らかにし、RBACセキュリティの開発と運用に関するベストプラクティス、そしてByteDanceにおける社内セキュリティ保護とガバナンスの経験を共有します。

背景情報

❝

関連する背景知識に精通している場合は、「RBAC セキュリティ リスク分析」および「RBAC セキュリティの研究開発と運用のベスト プラクティス」のセクションに直接進むことができます。

❞

この章では、Kubernetesの認証・認可システムの概要を説明します。これらのメカニズムの背後にある原理を理解することで、様々なシナリオにおけるクラスター権限に関連するセキュリティリスクを理解するのに役立ちます。特に、簡単に悪用される不正アクセスの脆弱性や、権限昇格やラテラルムーブメント攻撃に関連する見落とされがちなリスクについて解説します。

Kubernetes 認証および認可システム

Kubernetesの認証・認可システムは、主に重要なサービスAPI（APIサーバー、Kubeletサーバー）へのアクセス制御に使用されます。長年の開発を経て、Kubernetesはほとんどのユーザーシナリオのニーズを満たす、比較的包括的な認証・認可メカニズムを実装しました。

APIサーバー

Kubernetesは、コンテナ技術をベースとし、宣言型APIサーバーを中心とする分散コンテナオーケストレーションシステムです。Kubernetesのほぼすべての機能はAPIサーバーを通じて公開されます。APIサーバーは複数の認証メカニズムをサポートし、組み込みの認可モードとアドミッションコントローラーを備えているため、ユーザーは必要に応じて柔軟に設定・使用できます。

簡単に言うと、ユーザーがKubernetes APIサーバーにアクセスすると、APIサーバーは有効な認証子を用いてリクエストを順番に認証し、最初に認証に成功したIDに基づいてリクエスト元を識別します。次に、有効な認可子を用いてリクエストの認可ポリシーを確認します。いずれかの認可子がリクエストを明示的に許可または拒否した場合、現在の認可結果が直ちに返されます（いずれの認可子も明示的に承認していない場合、リクエストは拒否されます）。さらに、APIサーバーはリクエストを実際に処理する前に、有効なアドミッションコントローラを用いてリクエストをさらに検証および確認します。すべてのアドミッションコントローラがリクエストを検証した後でのみ、リクエストは処理されます。

❝

注意: API サーバーは、認証子とアドミッション コントローラの実行順序を保証しませんが、認可モードの設定順序に従って認証を実行します。

❞

Kubelet サーバー

Kubernetesのもう一つの重要なコンポーネントはKubeletです。Kubeletは分散システムにおけるエージェントとして機能し、ノード固有のユーザー証明書を使用してAPIサーバーにアクセスし、ノード上のリソースを管理します。また、Kubelet自体もサーバーとして機能し、外部にサービスを提供します。これにより、コンテナ内でのコマンド実行、メトリクス、コンテナログ、ホストマシンログの取得などの機能が可能になります。

Kubernetesは、Kubeletサーバー向けに様々な認証および認可モードを提供しています。特に注目すべきはWebhook認証とWebhook認可です。これらは基本的に、TokenReviewリクエストとSubjectAccessReviewリクエストをAPIサーバーに送信し、クライアントのIDを認証および認可します。

"まとめ"

Kubernetesは、様々な認証メカニズム、認可メカニズム、アドミッションコントローラ、そしてAPIサーバーとKubeletサーバー向けの柔軟なカスタムインターフェースをサポートしています。これらのメカニズムは多様なユーザーニーズに対応できる一方で、課題も生じます。これらのメカニズムの原理と悪影響を理解しなければ、クラスターにセキュリティリスクや侵入検知の盲点を容易に作り出す可能性があります。これは特に、容易に悪用される不正アクセスの脆弱性や、見落とされやすい権限昇格やラテラルムーブメント攻撃のリスクに当てはまります。

API サーバーおよび Kubelet サーバーの認証、承認、アクセス制御に関する技術的な詳細については、付録と参考資料を参照してください。

Kubernetes RBAC 認可の原則

RBAC は Kubernetes でデフォルトで有効化されている認可メカニズムであり、Kubernetes のコアコンポーネントでも使用されています。ユーザーは、ワークロードのデプロイと保守、そして必要なリソースへのアクセスのために、クラスターの使用時にユーザーアカウントを認可するために RBAC を使用することがよくあります。また、様々なクラウドネイティブアプリケーションのオペレーターやコントローラーも、サービスアカウントを認可するために RBAC を使用することが多く、機能の実行に必要なリソースへのアクセスを確保する必要があります。

次の図は、ユーザー アカウントとサービス アカウントが API サーバーにアクセスする際の認証、承認、およびアクセス制御のプロセスを示しています。

Kubernetes の RBAC 認証システムでは、次の概念が導入されています。

"主題"

• Kubernetes 環境では、RBAC ロール権限を付与できるサブジェクトが 3 種類あります。

"ルール"

• 使用場所  Role   ClusterRole  内部的には、特定の権限が定義されています。各ルールは、apiGroups、resources、resourcesName、verbs、nonResourceURLs によって定義され、どのリソース（API グループ、リソースタイプ、リソース名）がどの操作（verb）を実行できるかを指定できます。
• 注: ワイルドカードは、ルール内の apiGroups、resources、resourcesNames、verbs、および nonResourceURLs でサポートされます。

「ロールとクラスターロール」

• Role 、現在の名前空間スコープ内のリソースの役割を定義するために使用されます。これは、… によって実現されます。   Rules  権限を明示的に定義します。
• ClusterRoleは、クラスター内のリソースの役割を定義するために使用されます。   Rules  権限を明示的に定義します。

「ロールと ClusterRoleBinding」

• RoleBinding  ある意味で  ClusterRole  または現在の名前空間内の特定のもの  Role  サブジェクトにバインドすると、サブジェクトは現在の名前空間にアクセスできるようになります。   ClusterRoleとRoleロールの権限を定義します。例えば、名前空間AにRoleBindingを作成し、名前空間AのRoleを名前空間BのServiceAccountにバインドすることができます。すると、名前空間BのServiceAccountは、名前空間AのRoleによって定義された権限を取得します。
• ClusterRoleBinding  ある意味で  ClusterRole  サブジェクトにバインドして、サブジェクトが取得できるようにします...   ClusterRole  定義されたロール権限。

上記から、 Role  そして  ClusterRole  内で  rules  これは、デフォルトで拒否するセキュリティモデルに従って、明示的に付与された権限のセットを表します。「拒否」ルールはサポートされていないため、特定の権限を明示的に除外することはできません。

この特性により、特定のアプリケーションシナリオではRBAC認可メカニズムを使用できません。例えば、すべての既知および未知のCRDリソースへの操作権限を付与しながら、特定の機密性の高い権限を明示的に除外するといったシナリオです。しかし、ABACとWebhook認可パターンをアクセスコントローラーと組み合わせて使用​​することで、このようなシナリオにおけるサービスアカウントの権限管理が可能になり、これらの問題を軽減できます。

以下は、RBAC 承認メカニズムを使用して ServiceAccount に権限をバインドする例です。

 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: example-clusterrole namespace: example-ns rules: - apiGroups: - apps resources: - daemonsets - deployments - replicasets - statefulsets resourcesNames: - test verbs: - '*' - nonResourceURLs: - /healthz - /healthz/* verbs: - get --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: example-rolebinding namespace: example-ns roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: example-clusterrole subjects: - kind: ServiceAccount name: example-sa namespace: example-ns

RBAC セキュリティリスク分析

Kubernetesは分散コンテナオーケストレーションシステムです。CIS Kubernetesベンチマークの第1章から第4章の要件に対応するAPIサーバーやKubeletサーバーの基本的な認証・認可設定など、Kubernetesの基本コンポーネントの設定のセキュリティを確保するだけでなく、RBAC認証設定もきめ細かく管理する必要があります。

適切なエンティティに適切なRBAC権限を付与することで、クラスタへの不要な安定性とセキュリティリスクの導入を防止できます。一方、不適切な権限設定は、機密データの漏洩、リソースの不正利用、権限昇格、さらにはクラスタ全体のセキュリティを脅かす可能性があります。これらのセキュリティリスクについては、以下で文献とケーススタディを用いてさらに詳しく説明します。

概要

Kubernetesでは、リソース操作を通じて情報窃取、権限昇格、ラテラルムーブメントといった攻撃が可能になります。例えば、「pods/exec」リソースの「create」権限は、APIサーバー経由で特定のコンテナ内で任意のコマンドを実行するために利用されます。「nodes/proxy」リソースの「create」権限は、Kubeletサーバーに直接アクセスし、特定のコンテナ内で任意のコマンドを実行するために利用されます。「pods」の「create」権限は、セキュリティリスクのあるコンテナを作成するために利用されます。「pods」の「patch」権限は、特定のPodのコンテナ内でコードを実行するために利用されます。 「Kubernetesの普及に伴い、これらのリスクはクラウドベンダー、PaaSプラットフォーム、クラウドネイティブアプリケーション、SaaS製品においてますます蔓延しています。最良の場合、これらはエクスプロイト後の攻撃に利用されますが、最悪の場合、製品にセキュリティ上の脆弱性をもたらします。」

Palo Alto Networksのセキュリティ研究者は、Kubernetesにおけるすべての機密性の高い権限を詳細に分析し、その危害の種類に応じて分類・等級付けを行いました[2]（重大度については、オープンソースプロジェクトrbac-police [3]のリスク権限スキャン戦略セットを参照してください）。下図に示すように、これらの機密性の高い権限の多くは、攻撃者による情報漏洩、権限昇格、横方向の移動などの攻撃に利用され、最終的にはクラスター全体の乗っ取りにつながる可能性があります。

パロアルトネットワークスの調査結果によると、主要なパブリッククラウドおよびCNIベンダーの分析では、約50%のベンダーがコンテナエスケープ後に容易にクラスタの崩壊につながるセキュリティ問題を抱えていることが明らかになりました。さらに25%のベンダーは、コンテナエスケープ後に特定の条件下でクラスタの崩壊につながるセキュリティリスクを抱えています[2]。

公的事例

• RBACバスター：Aqua Secの研究者たちは、ハニーポットを用いてKubernetesのRBAC設定の脆弱性を悪用する攻撃を初めて捕捉しました。ハッカーはクラスタにアクセスするためのバックドアを作成し、不正アクセスとデータ侵害を引き起こしました。「Kubernetes RBACをバックドアクラスタに利用する史上初の攻撃」 [5]をご覧ください。
• Sys:All: Orca Research Podは25万個のGKEクラスタ（全体の約2%）をスキャンし、そのうち1,300個でロールバインディングの設定ミスがあり、そのうち108個では有効なGoogleアカウントを使って攻撃者がクラスタを乗っ取ることができる状態にあることを発見しました。参照：Google Kubernetes Engineの単純な抜け穴がクラスタを侵害の危険にさらす[6]   ＆GCP-2024-003セキュリティ速報[7]
• OWASP Kubernetes Top 10のセキュリティリスクでは、RBACの設定ミスによる「過剰な権限」問題が3位にランクされており、不正な操作や権限昇格につながる可能性があります。詳細はOWASP Kubernetes Top 10をご覧ください[8]

リスクの例

以下の例は、攻撃者が任意のシークレットの作成権限を悪用し、機密性の高い権限を含むServiceAccountのトークンを取得する方法を示しています（ここでは、prometheus-agentのSAトークンを盗むことを例に挙げています）。そのため、必要な権限は専用のネームスペースでロールを使用して定義し、kube-systemなどの機密性の高いネームスペースから分離することをお勧めします。

以下の例は、攻撃者が任意のシークレットに対するget権限を利用して、SAトークンを格納しているシークレットにブルートフォース攻撃を仕掛ける方法を示しています。SAトークンに対するブルートフォース攻撃にはかなりの時間がかかります（ランダムな5つの文字列でSAトークンをブルートフォース攻撃するには最大で27^5回の試行が必要です）。また、この権限は他の既知の名前を持つシークレットを盗むためにも使用される可能性があります。したがって、名前空間全体の任意のシークレットにget権限を付与するのではなく、Rolesを使用してロールを定義するか、resourceNamesを使用してシークレット権限のスコープを制限することをお勧めします。

上記のデータと事例は、Kubernetes RBAC アクセス制御が、真剣に受け止め、タイムリーに効果的に防御する必要があるセキュリティ問題になっていることを示しています。

RBAC セキュリティ開発と運用のベストプラクティス

ByteDance の社内セキュリティ プラクティスに基づいて、Kubernetes RBAC 権限の管理を全員がガイドし、クラスターにもたらされるセキュリティ リスクを軽減するための RBAC 認証構成の次の原則をまとめました。

最小権限の原則に従う

RBACロールに権限を割り当てる際は、最小権限の原則に従い、タスクの実行に必要な最小限の権限のみを付与してください。例：

• 1 つ以上の特定の名前空間で権限を付与する場合は、Role クラスと RoleBinding クラスが推奨されます。
• ルールを定義するときは、明示的な apiGroups、リソース、動詞、および resourceNames を使用して、権限の範囲を制限します。

❝

知らせ：

`resourceNames` フィールドが設定されている場合、リクエスト権限は `list`、`watch`、`create`、または `deletecollection` にすることはできません。それ以外の場合、リクエストは許可されません（ 「`resourceNames` を使用して `list` および `watch` 権限の範囲を制限する場合、クライアントは認可のためにリクエストパラメータに `fieldSelector=metadata.name%3D{RESOURCENAME}` を指定する必要があります」 ）。ただし、`resourceNames` フィールドに "" が含まれている場合、`list` リクエストは許可されます。

RBAC 認証モードでは、resourceNames による create および deletecollection 権限の制限はサポートされていませんが、resourceNames による update、patch、get などの権限を制限することをお勧めします。

❞

RBAC 権限の最小化は、「白か黒か」という単純なアプローチとして捉えるべきではありません。コンポーネントの一部の機密性の高い権限を最小化できない場合でも、権限の最小化はリスクを軽減し、侵入検知の可能性を高める上で重要な役割を果たします。

デフォルトのロール/ユーザー/ユーザーグループの使用を避ける

通常、KubernetesおよびKubernetesベースのPaaSプラットフォームは、システムが正しく機能することを保証するために、特定のデフォルトロールをデフォルトユーザーおよびユーザーグループに自動的にバインドします。Kubernetesによって作成されるデフォルトロールとバインディングの完全なリストについては、「デフォルトロールとロールバインディング」を参照してください。

• 一般的なデフォルト ロールには、cluster-admin、system:node、system:controller:daemon-set-controller などがあります。
• 一般的なシステムユーザーには、system:anonymous、system:kube-controller-manager、system:kube-scheduler、system:kube-proxy、system:serviceaccounts:NAMESPACE:default などがあります。
• 一般的なシステム ユーザー グループ: system:unauthenticated、system:authenticated、system:serviceaccounts、system:nodes、system:monitoring、system:masters ...

ほとんどのデフォルトロール（cluster-admin、edit、system:node など）には広範な権限が付与されています。そのため、セキュリティリスクを認識し、それを許容できる場合を除き、デフォルトロールをサービスアカウントにバインドすることは「推奨しません」 。ユーザーは必要に応じて、デフォルトロールをユーザーアカウントにバインドできます。

さらに、システム ユーザー (system:anonymous、system:serviceaccounts:NAMESPACE:default など) やシステム ユーザー グループ (system:authenticated、system:serviceaccounts など) に追加のロールをバインドすることは、 「避ける」必要があります。これは、意図しない権限の拡散につながり、重大なセキュリティ リスクをもたらす可能性があるためです。

デフォルトのサービス アカウントに権限を付与しないでください。

付録1の「アドミッション制御メカニズム」セクションで、ServiceAccountアドミッションコントローラについて説明しました。これはデフォルトで有効になっています。ポッドの作成時にServiceAccountが指定されていない場合、ServiceAccountアドミッションコントローラは名前空間から「default」という名前のServiceAccountをポッドに割り当てます。

したがって、意図しない権限リークが発生する可能性があるため、デフォルトのサービス アカウントに権限を付与することは「避ける」必要があります。

ワイルドカードの使用は避ける

*  この文字はすべてのコンテンツに適用されるワイルドカードであり、ルールでは使用しないでください。この動作によって生じる可能性のあるセキュリティリスクを明確に理解し、受け入れない限り、認可スコープが過度に広くなる可能性があります。RBACルールでは、APIグループ、リソース、動詞、さらにはリソース名を明示的に指定することをお勧めします。

例えば、   verbs  フィールドに指定  *  付与されます  get 、 list 、 watch 、 patch 、 update 、 deletecollection  そして  delete  権限など。以下の表は、ルール内でワイルドカードを使用しないようにする方法を示しています。

機密性の高い権限の使用は避けてください。

ロールを設計する前に、権限昇格、コマンド実行、情報漏洩といったセキュリティリスクをもたらす権限を慎重に評価する必要があります。例えば、シークレットの操作権限、証明書発行権限、Pod/Execアクセス権限などです。詳細については、「Kubernetes RBAC - 権限昇格リスク」 [9]および「リスク権限スキャン戦略セット」 [3]を参照してください。

アプリケーションサービスや制御コンポーネントに機密性の高い権限を付与すると、クラスタ全体にセキュリティリスクが生じます。システムの設計・開発段階では、これらの権限の使用は可能な限り避け、セキュリティオーケストレーション、セキュリティ強化、侵入検知のための他の手法と組み合わせて使用​​する必要があります。

特定のリソースに権限を付与するには、個別のルールを使用するようにしてください。

ルールを計画する際には、各ロールに対してより効率的で読みやすく保守しやすいルール設計を採用するために、次の簡単な手順を試すことをお勧めします[4]。

1. サブジェクトがアクセスする必要がある動詞ごとに個別の RBAC ルールを作成します。
2. ルールを作成したら、それらを分析して、複数のルールが同じ特性を持っているかどうかを確認します。   verbs  リスト。これらのルールを 1 つのルールに結合します。
3. 残りのルールはすべて各自で分配してください。

このアプローチにより、同じ動詞を複数のリソースに割り当てるルールを組み合わせ、異なる動詞をリソースに割り当てるルールをそれらの間で分散させることで、より構造化されたルール設計が可能になります[4]。

たとえば、ワークロードで  deployments  リソース権限が必要ですが、   daemonsets  リソース  list  そして  watch  権限については、ロールを作成する際に個別のルールを使用する必要があります。RBAC ロールをワークロードにバインドすると、そのロールは権限にアクセスできなくなります。   deployments  リソース  watch  操作[4]。

別の例として、ワークロードに必要な場合...   pods  リソースと  daemonsets  リソース  get  そして  watch  権限に関しては、ワークロードは両方のリソースに対して同じ動詞を使用する必要があるため、それらを1つのルールに組み合わせることができます[4]。

下の表では、どちらのルール設計も効果的ですが、分割ルールでは必要に応じてリソースのアクセス権限をより細かく制限しています[4]。

セキュリティオーケストレーションなど

場合によっては、ビジネスニーズとセキュリティ要件が衝突することがあります。例えば、一部のアプリケーションでは、正常に動作したり必要な機能を提供したりするために、特定の機密性の高い権限が必要になります。このような場合、リスクを最小限に抑えるために、以下のセキュリティオーケストレーションと多層防御戦略を検討することをお勧めします。

❝

注: コンポーネントがDaemonSet型で、特定の機密性の高い権限を必要とする場合は、リファクタリングまたは軽減策（例：Webhookアドミッションコントローラーによる検証の実装）を強くお勧めします。そうしないと、ノードが侵害された場合にクラスター全体が危険にさらされることになります。

❞

専用の名前空間を使用する

• アプリケーションに名前空間全体の権限のみが必要な場合は、不要な権限の伝播を避けるために、kube-system 名前空間、デフォルトの名前空間、またはワークロードが存在する名前空間ではなく、専用の名前空間にデプロイすることを「強く推奨」します。
• 例えば、制御コンポーネントのSA（Secrets）には、SSLキーペアを管理するために、Secrets名前空間でリスト権限とウォッチ権限が付与される場合があります。これを専用の名前空間（kube-system名前空間やビジネスワークロードが存在する名前空間ではなく）にデプロイすることで、SAトークンの漏洩によって生じる可能性のあるセキュリティリスクを軽減できます。
• アプリケーションがすべての機密権限をグローバルに必要とする場合、権限の伝播の可能性を回避するために、そのアプリケーションをデフォルトの名前空間またはビジネス ワークロードが存在する名前空間にデプロイすることは「推奨されません」。

「特別なスケジュール戦略を開発する」

• 特定のコンポーネントがグローバルに機密性の高い権限を必要とする場合、適切なスケジューリング戦略（ノードテイントやアドミッションコントロールポリシーなどによってスケジューリング戦略がバイパスされないことを保証）を策定し、これらのコンポーネントを専用のノードプールにスケジュールするか、エラスティックコンテナを使用してデプロイすることを「推奨」します。これにより、機密性の高い権限を含む制御コンポーネントがビジネスワークロードから分離され、ビジネスワークロードをホストするノードが侵害された場合に機密性の高い権限SAトークンが漏洩するセキュリティリスクを回避できます。

「機密コンポーネントを個別に展開する」

• 機密性の高い権限を必要とするコンポーネントを別のコントロール プレーンにデプロイすることで、このようなセキュリティ リスクを軽減することもできます。

「多層防御の構築」

• 現実のビジネスシナリオでは、機密性の高い権限をすべて削除することはできません。特に、リスクレベルは高いもののビジネスとの依存関係が強い権限はなおさらです。そのため、権限の最小化とセキュリティオーケストレーションに加えて、ホストレベルとKubernetesレベルで脅威管理と侵入検知機能を導入することを強くお勧めします。これにより、潜在的な侵入試行に対するリスク、アラート、対応をタイムリーに検知・管理できるようになります。

RBAC の安全保護とガバナンスの実践

多くの企業は、セキュリティ意識の不足、クラウドネイティブなセキュリティ対策の導入の遅れ、オープンソースのクラウドネイティブアプリケーションの使用などにより、システムに重大なRBAC（ロールベースアクセス制御）リスクをもたらしています。しかし、インフラストラクチャが関与し、関連する知識とツールが不足しているため、これらのリスクの保護と管理はしばしば困難です。次のセクションでは、ByteDanceにおける経験と実践の一部を共有し、さらなる議論を促し、皆様の参考となる知見を提供できれば幸いです。

全体的なアプローチ

公開ケーススタディやレッドブルーチーム演習を通じて、Kubernetes RBACの誤った設定が本番環境のセキュリティと安定性に及ぼす可能性のある損害をR&Dチームに示します。DevOpsチームとリスク認識について合意を形成し、ガバナンス目標をトップダウンで整合させます。ガバナンス作業を実施する前に、企業の実情に基づいた合理的な計画を策定する必要があります。同時に、セキュリティチームはガバナンスに必要なナレッジベース、ツール、システムを提供し、運用チームと協力して適切なガバナンスプロセスを構築し、ガバナンス作業の円滑な進行を確保する必要があります。さらに、セキュリティチームは侵入防止機能を継続的に強化し、Kubernetes RBACなどのセキュリティリスクに対するセーフティネットを提供する必要があります。

計画を立てる

実用的な計画を策定し、必要なツールとシステムを提供することは、K8s RBAC のセキュリティ リスクを軽減するための重要な前提条件と安全策です。

「データ駆動型」

• 保護とガバナンスには、データ主導のアプローチを推奨します。継続的なセキュリティスキャンは、リスクを特定し、その重大度を評価し、優先順位を付ける上で不可欠です。リスクの根本原因を特定することで、責任者と主要な課題を特定し、的を絞った解決策を講じることができます。

❝

「RBAC セキュリティリスク分析」の章では、Kubernetes の多数の権限がセキュリティリスクをもたらすことを指摘していますが、様々なシナリオや実際的な要因を考慮すると、企業にすべての機密性の高い権限の使用を避けるよう求めることは難しいかもしれません。そのため、セキュリティ保護とビジネスニーズのバランスを取る必要があります。

❞

「優先順位を明確に定義する」

• RBACリスク権限の可用性、重大度、影響範囲を組み合わせて5つの優先順位に分類し（リスク権限とそのセキュリティスキャン戦略については、リスク権限スキャン戦略セット[3]を参照してください）、K8s RBACの権限評価とガバナンスを推進します。リスク評価とガバナンスの完了前後には、侵入検知などのメカニズムを使用して継続的な監視とバックアップを行う必要があります。

「段階的な制御と既存の是正」

• 企業のPaaSプラットフォームとKubernetesクラスターにアクセス制御メカニズムを統合することで、段階的な管理を実現できます。必要なホワイトリストメカニズムを提供し、すぐに修正できないアプリケーションに対して一時的な例外を付与することをお勧めします。その後、定期的なスキャンの結果に基づいて、担当者に既存コンポーネントの修正、カナリアテストの実施、そして完全なアップデートの実行を促す必要があります。

保護とガバナンスのフレームワーク

ByteDanceでは、下図のようなセキュリティ保護とガバナンスのフレームワークを構築し、権限ガバナンスも推進しています。

開発および統合フェーズでは、セキュリティのベストプラクティスを活用し、R&D部門が安全なRBAC権限を設計・開発できるよう支援しました。また、一部のCI/CDパイプラインにセキュリティスキャンを統合し、危険なRBAC設定を含むチャートアーティファクトをインターセプト、アラート、ログに記録できるようにしました。

導入フェーズでは、PaaSプラットフォームとKubernetesアクセスコントローラに統合されたアクセス制御メカニズムを通じて、不正なアプリケーションとリソースを段階的に管理します。また、セキュリティオーケストレーションなどの手法を用いて、重要な業務オペレーションにおいて、機密性の高い権限を持つ制御コンポーネントに関連するセキュリティリスクを軽減します。ここでは、オープンソースプロジェクトKyvernoのポリシーエンジンをベースに、Policy as Codeを実装しました。これにより、パイプライン化されたセキュリティスキャンとアクセス制御におけるポリシーの互換性が確保され、セキュリティポリシーの保守コストが削減されます。

運用中は、オープンソースプロジェクトrbac-policeに基づく定期的なスキャンを通じて、継続的にリスクを特定しています。さらに、サービスアカウントとユーザーアカウントの行動モデリング機能を設計・実装しました。この機能は、アカウントの行動に基づいて最小権限のロール定義を生成し、コンポーネントの権限収束の参考資料として利用できます。すべての機密性の高い権限を修正できるわけではないため、実際にはKubernetes監査ログに基づく侵入検知を実施し、潜在的な攻撃行動を明らかにしています。

上記のメカニズムを通じて、K8s RBAC セキュリティリスクの保護およびガバナンスフレームワークを構築し、ByteDance の大規模本番クラスターの RBAC セキュリティガバナンスと保護に必要な機能を提供しました。

要約

RBACはKubernetesにおける重要な認可メカニズムであり、適切なRBAC設定はKubernetesベースのシステムのセキュリティ確保に不可欠です。設計においては、最小権限の原則を遵守し、機密性の高い権限のセキュリティリスクを理解し、必要な保護機能を導入する必要があります。開発においては、過剰な権限付与や権限の混乱を避ける必要があります。セキュリティ保護と運用においては、セキュリティ要件とビジネスニーズのバランスを取り、セキュリティリスクを継続的に軽減し、多層防御システムを確立する必要があります。

この記事の目的は、Kubernetes の権限システム、RBAC 認証モードのセキュリティ リスク、およびセキュリティのベスト プラクティスを読者が理解しやすくし、システムのセキュリティ設計、開発、保護をガイドし、最終的にはより安全で信頼性の高いシステムを構築できるようにすることです。

参考文献

1. https://kubernetes.io/docs/reference/access-authn-authz
2. https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms
3. https://github.com/PaloAltoNetworks/rbac-police/tree/main/lib
4. https://cloud.google.com/kubernetes-engine/docs/best-practices/rbac
5. https://www.aquasec.com/blog/leveraging-kubernetes-rbac-to-backdoor-clusters
6. https://orca.security/resources/blog/sys-all-google-kubernetes-engine-risk
7. https://cloud.google.com/kubernetes-engine/security-bulletins#gcp-2024-003
8. https://owasp.org/www-project-kubernetes-top-ten
9. https://kubernetes.io/docs/concepts/security/rbac-good-practices/#権限エスカレーションリスク