DevOpsナレッジハブ
DevOpsナレッジハブ

Kubernetesクラスターを保護するためのRBACのベストプラクティス

この必須ガイドでKubernetes RBACをマスターし、クラスターを安全に保護しましょう。ロール、クラスターロール、およびそれらのバインディングを細心の注意を払って作成および管理することにより、最小権限の原則を強制することを学びます。この記事では、名前空間スコープの権限とクラスター全体の権限の両方に対する実践的な例を提供し、ワイルドカードの回避、定期的な監査、サービスアカウントの活用といったベストプラクティスを強調します。脆弱性を最小限に抑え、不正アクセスや潜在的なセキュリティ侵害から本番のKubernetes環境を強化します。

34 ビュー

Kubernetesクラスターを保護するための必須RBACベストプラクティス

Kubernetesはコンテナオーケストレーションのデファクトスタンダードとなり、組織が前例のない効率でアプリケーションをデプロイし、スケールできるようにしました。しかし、大きな力には大きな責任が伴い、特にセキュリティに関してはその通りです。Kubernetesにおける最も重要なセキュリティメカニズムの1つが、ロールベースのアクセス制御（RBAC）であり、管理者がクラスター内で「誰が何ができるか」を正確に定義することを可能にします。

本記事では、Kubernetes RBACの基本概念を探り、本番環境を保護するための必須のベストプラクティスを概説します。最小特権の原則をどのように強制するかを探り、潜在的なセキュリティ脆弱性を最小限に抑えるために、ロール（Role）とクラスターロール（ClusterRole）の作成、バインディング、および綿密な管理について手順を追って説明します。これらの戦略を理解し適用することで、Kubernetesクラスターのセキュリティ体制を大幅に強化し、貴重なアプリケーションとデータを保護することができます。

Kubernetes RBACの基礎を理解する

KubernetesのRBACは、個々のユーザーやサービスアカウントの役割に基づいてKubernetesリソースへのアクセスを規制する認可メカニズムです。これは防御の重要な層であり、認可されたエンティティのみが特定のリソースに対して特定のアクションを実行できるようにします。

その核となるのは、RBACが依存する4つの主要なKubernetesオブジェクトタイプです。

  • Role: Roleは、特定の名前空間内に適用される一連の権限です。どのリソース（例：pods、deployments、services、secrets）に対してどの操作（例：get、list、create、update、delete）を実行できるかを定義します。例えば、Roleはdevelopment名前空間内のpodsとdeploymentsの読み取り権限を付与する場合があります。
  • ClusterRole: Roleと似ていますが、ClusterRoleはクラスター全体または名前空間を持たないリソース（例：nodes、persistentvolumes）に適用される権限を定義します。また、ClusterRoleはすべての名前空間にわたる名前空間付きリソースに対する権限を定義することもできます。例えば、ClusterRoleはクラスター内のすべてのnodesの一覧表示を許可する場合があります。
  • RoleBinding: RoleBindingは、Role（または名前空間内に適用されるClusterRole）で定義された権限をユーザー、グループ、またはサービスアカウントに付与します。これは常に特定の名前空間内で機能します。
  • ClusterRoleBinding: ClusterRoleBindingは、ClusterRoleで定義された権限をユーザー、グループ、またはサービスアカウントに付与し、それらの権限をクラスター全体に適用します。

これらオブジェクトを組み合わせることで、管理者は堅牢で粒度の高いアクセス制御システムを構築できます。ユーザーまたはアプリケーション（サービスアカウントによって表される）がアクションを実行しようとすると、Kubernetesは既存のRoleBindingsとClusterRoleBindingsを評価して、要求されたアクションが許可されているかどうかを判断します。

RBACによる最小特権の原則の実装

情報セキュリティの中心的な教義は最小特権の原則（PoLP）です。この原則は、ユーザー、プログラム、またはプロセスには、そのジョブを実行するために必要な最小限の権限セットのみが与えられるべきであることを示します。Kubernetesでは、PoLPを遵守することがセキュリティにとって最も重要です。過剰な権限を持つロールは一般的な攻撃ベクトルとなり、あるアカウントが侵害された攻撃者が意図されたよりもはるかに広範なアクセス権を獲得することを許してしまいます。

粒度の高い権限の定義

RBACポリシーを作成する際は、必要な正確な操作とリソースについて考えます。

  • 動詞（Verbs）: *（すべての動詞）を付与する代わりに、必要な操作（get、list、watch、create、update、delete、patch）を正確に指定します。
  • リソース（Resources）: リソース（pods、deployments、secrets、configmaps）について具体的に指定します。絶対に必要であり、正当な管理者ロールの場合を除き、リソースに対する*へのアクセス付与は避けてください。
  • リソース名（Resource Names）: secretsのような非常に機密性の高いリソースについては、リソースタイプ内の特定のresourceNamesにアクセスを制限することもできます。
  • APIグループ（API Groups）: ほとんどのKubernetesリソースはAPIグループに属します（例：apps、rbac.authorization.k8s.io、コアリソースの場合は""）。スコープをさらに絞り込むために、正しいAPIグループを指定します。

名前空間のスコープ設定

ほとんどのアプリケーションと開発チームにとって、権限は特定の名前空間内に限定されるべきです。この分離により、あるアプリケーションまたはチームの環境での侵害が、自動的にクラスター全体へのアクセスにつながることはありません。可能な限り、ClusterRoleとClusterRoleBindingよりもRoleとRoleBindingを優先してください。

実用的なRBAC実装：例

RBACポリシーの作成とバインディングに関する実用的な例をいくつか見ていきましょう。

例1：特定の名前空間への開発者アクセス

開発者が専用の名前空間dev-team-aでデプロイメントを管理し、ログを表示する必要があるとします。彼らは他の名前空間やクラスター全体の情報源にアクセスすべきではありません。

まず、dev-team-a名前空間内で開発者用のRoleを定義します。

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Deployments用
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: ["core"] # PodsとPodログ用
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

このロールを適用します。

kubectl apply -f dev-role.yaml

次に、このRoleを特定のユーザー（例：外部IDプロバイダー経由の[email protected]）またはdev-team-a名前空間内のサービスアカウントにバインドします。

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # 名前は大文字と小文字が区別されます
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

このバインディングを適用します。

kubectl apply -f dev-role-binding.yaml

これで、[email protected]はdev-team-a名前空間内でデプロイメントを管理し、ログを表示することしかできません。例えば、kube-systemでシークレットを作成したり、すべてのノードを一覧表示したりすることはできません。

例2：シークレットにアクセスするアプリケーションサービスアカウント

ServiceAccountとして実行されているアプリケーションが、自身の名前空間内の特定のシークレットを読み取る必要があるとします。

まず、サービスアカウントが存在することを確認するか、作成します。

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

このサービスアカウントを適用します。

kubectl apply -f app-sa.yaml

次に、特定のシークレットの読み取りを許可するRoleを定義します。

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: ["core"]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

このロールを適用します。

kubectl apply -f secret-reader-role.yaml

最後に、このRoleをmy-app-service-accountにバインドします。

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

このバインディングを適用します。

kubectl apply -f app-secret-reader-binding.yaml

これにより、アプリケーションは指定されたシークレットのみを読み取ることができ、それ以外は何もできなくなります。

例3：クラスター管理者ロール（注意が必要）

クラスター全体の管理者ロールは、極めて慎重に付与する必要があります。以下は、モニタリングツールで必要となる可能性のある、すべてのノードを一覧表示するClusterRoleの例です。

# node-viewer-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: ["core"]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

このClusterRoleを適用します。

kubectl apply -f node-viewer-clusterrole.yaml

次に、ClusterRoleBindingを使用してモニタリングサービスアカウントにバインドします。

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

このバインディングを適用します。

kubectl apply -f monitoring-node-viewer-binding.yaml

警告: 人間のユーザーに対してClusterRoleとClusterRoleBindingを使用する場合は、細心の注意を払ってください。その使用を真のクラスター管理者および特定のインフラストラクチャサービスアカウントに限定してください。

必須RBACベストプラクティス

これらのベストプラクティスに従うことで、クラスターのセキュリティ体制を大幅に向上させることができます。

  1. 最小特権の原則（PoLP）の実施:

    • 必要最小限の権限のみを付与します。すべての権限を慎重に確認してください。
    • 可能な限り、resourcesやverbsでワイルドカード（*）の使用を避けてください。使用する場合は正当な理由を示し、可能な限り狭くスコープを設定するように努めてください。
    • resourceNamesを使用して、機密性の高いリソース（例：secrets）へのアクセスを制限します。

  2. 分離のための名前空間の使用:

    • アプリケーションとチームを個別の名前空間に整理します。
    • これらの名前空間内での権限付与には、常にRoleとRoleBindingの使用をデフォルトとします。

  3. ClusterRoleよりもRoleを優先する:

    • 権限が真にクラスター全体で必要とされる場合（例：ノード管理、カスタムリソース定義、特定のモニタリングエージェント）にのみClusterRoleとClusterRoleBindingを使用します。
    • ほとんどのアプリケーション固有の権限は名前空間化されるべきです。

  4. RBACポリシーの定期的な監査とレビュー:

    • RBACポリシーは時間の経過とともに緩むことがあります。誰がどのようなアクセス権を持っているかを定期的に確認してください。
    • 特定のユーザー/サービスアカウントの権限をテストするには、kubectl auth can-iのようなツールを使用します。
      ```bash

    '[email protected]'が'dev-team-a'でPodを取得できるか確認

    kubectl auth can-i get pods --namespace=dev-team-a [email protected]

    'monitoring-sa'がノード一覧表示（クラスター全体）できるか確認

    kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
    ```
    * 包括的なRBAC監査のためには、サードパーティ製ツールやカスタムスクリプトを検討してください。

  5. 管理者ロールの分離:

    • 開発者やアプリケーションサービスアカウントにcluster-admin権限を絶対に付与しないでください。
    • 必要な昇格された権限（例：cluster-reader、node-reader）のみを持つ、特定の管理者用ClusterRoleを作成します。

  6. アプリケーションのためのサービスアカウントの活用:

    • クラスター内で実行されているアプリケーションは、Kubernetes APIと対話するためにServiceAccountsを使用する必要があります。
    • 各アプリケーションまたはマイクロサービスは、理想的には最小限の権限を持つ専用のServiceAccountを持つべきです。
    • APIアクセスを必要としないPodについては、Pod仕様またはサービスアカウント定義でautomountServiceAccountTokenをfalseに設定し、必要な場合にのみtrueに設定して、攻撃対象領域を減らします。

  7. 外部ID管理との統合:

    • 人間が使用するユーザーについては、認証とグループ管理のためにKubernetesを外部IDプロバイダー（例：OIDC、LDAP、Active Directory）と統合します。
    • 管理を容易にするために、外部グループをKubernetesのRoleBindingsまたはClusterRoleBindingsにマッピングします。

  8. GitOpsによるRBAC管理の自動化:

    • RBACポリシーをコードとして扱います。バージョン管理されたリポジトリ（Git）に保存します。
    • GitOpsの原則を使用してRBAC構成を管理およびデプロイし、一貫性、トレーサビリティ、および容易なロールバックを保証します。

  9. 監査ログを介したRBACイベントの監視:

    • Kubernetes監査ロギングを有効にし、誰がいつどのようなアクションを実行したかを含むAPIリクエストを追跡するように設定します。
    • 不正なアクセス試行やRBACに関連する疑わしいアクティビティを検出するために、監査ログを定期的にレビューします。

  10. Kubernetesの定期的な更新:

    • セキュリティパッチや改善（RBACの強化を含む）の恩恵を受けるために、Kubernetesのバージョンを最新に保ちます。

一般的な落とし穴とその回避方法

  • 過剰に寛容なワイルドカード: apiGroups: ["*"]、resources: ["*"]、またはverbs: ["*"]を付与することは重大なセキュリティリスクです。常に明示的に指定してください。
  • デフォルトのcluster-adminの使用: 日常的な操作のためにsystem:mastersグループやcluster-admin``ClusterRoleを絶対に使用したり、管理者以外のユーザーに割り当てたりしないでください。これはクラスター全体へのバックドアです。
  • automountServiceAccountTokenの無視: デフォルトでは、すべてのPodにサービスアカウントトークンがマウントされます。PodがKube APIと対話する必要がない場合は、Pod仕様またはサービスアカウント定義でautomountServiceAccountToken: falseを設定し、攻撃対象領域を減らします。
  • 監査の欠如: 定期的なレビューなしでは、クラスターのニーズが進化するにつれてRBACポリシーが古くなったり、過剰に寛容になったりする可能性があります。レビュープロセスを実装してください。
  • RoleとClusterRoleの混同: スコープの誤解は、名前空間付きアクセスのみを意図していた場合にクラスター全体のアクセスを付与することにつながる可能性があります。

結論

Kubernetesクラスターのセキュリティ確保は継続的な道のりであり、RBACはセキュリティ対策において不可欠なツールです。最小特権の原則を勤勉に適用し、名前空間を使用してアクセスを分離し、ロールとバインディングを慎重に定義し、厳格な監査プロセスを維持することにより、堅牢なセキュリティ基盤を構築できます。RBACは「設定したら終わり」のソリューションではなく、クラスターとアプリケーションの進化に合わせて継続的な注意と適応が必要であることを忘れないでください。これらのベストプラクティスを採用して、Kubernetes環境が不正アクセスや潜在的な脅威に対して回復力を維持できるようにしてください。