KubernetesにおけるRBAC実践ガイド：最小権限原則でセキュリティを強化

Kubernetesクラスターのセキュリティは現代のコンテナ運用において不可欠です。本記事では、Kubernetesの強力な認証・認可メカニズムであるRBAC（Role-Based Access Control）に焦点を当て、その基礎から実践的な設定、そしてセキュリティベストプラクティスまでを徹底解説します。最小権限の原則を適用し、安全なKubernetes環境を構築するための具体的な手法を学びましょう。

Kubernetesセキュリティの課題とRBACの重要性

現代のクラウドネイティブ環境において、Kubernetesはコンテナオーケストレーションのデファクトスタンダードとなっています。しかし、その強力な機能と柔軟性ゆえに、適切なセキュリティ対策が講じられていない場合、重大なリスクに晒される可能性があります。 不正アクセス、設定ミス、脆弱性のあるコンテナイメージの使用などが主なセキュリティ課題として挙げられます。 Kubernetesにおけるセキュリティ対策の要となるのが、認証（Authentication）と認可（Authorization）です。 認証は「誰がアクセスしているか」を検証し、認可は「その人物が何ができるか」を決定します。 特に認可においては、RBAC（Role-Based Access Control）が重要な役割を果たします。 RBACは、ユーザーやサービスアカウントに対して、必要な最小限の権限のみを与える「最小権限の原則」を実装するための強力なメカニズムです。 これにより、意図しない操作や不正なアクセスによる被害を大幅に軽減できます。

RBACの基本要素を理解する

RBACを効果的に利用するには、その構成要素を正確に理解することが不可欠です。 主要な要素として、Role、ClusterRole、RoleBinding、ClusterRoleBinding、そしてService Accountがあります。

RoleとClusterRole

RoleとClusterRoleは、それぞれが許可する操作（verb）と対象リソース（resource）の集合を定義します。

• Role: 特定のKubernetesネームスペース（namespace）内で有効な権限の集合を定義します。 例えば、defaultネームスペース内でPodの作成、更新、削除を許可するRoleなどです。 ClusterRole: クラスター全体にわたる権限の集合を定義します。 また、ネームスペースに依存しないリソース（例: ノード、PersistentVolumeなど）に対する権限や、すべてのネームスペース内の特定のリソースに対する権限も定義できます。

以下は、Roleの定義例です。 このRoleは、developmentネームスペース内でPod、Deployment、Serviceに対するget, list, watch, create, update, delete操作を許可します。 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: dev-resource-manager rules: - apiGroups: ["", "apps"] resources: ["pods", "deployments", "services"] verbs: ["get", "list", "watch", "create", "update", "delete"]

ClusterRoleの定義例です。 このClusterRoleは、すべてのネームスペースのSecretリソースに対してgetとlist操作を許可します。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "list"]

RoleBindingとClusterRoleBinding

RoleBindingとClusterRoleBindingは、定義されたRoleまたはClusterRoleを特定の主体（Subject）に割り当てる役割を担います。

• RoleBinding: 特定のネームスペース内のRoleを、そのネームスペース内のユーザー、グループ、またはサービスアカウントに紐付けます。 ClusterRoleBinding: ClusterRoleをクラスター全体のユーザー、グループ、またはサービスアカウントに紐付けます。 これにより、ClusterRoleで定義された権限がクラスター全体で適用されます。

以下は、RoleBindingの定義例です。 前の例で作成したdev-resource-managerRoleを、developmentネームスペース内のdeveloper-userというユーザーに割り当てます。 apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: bind-dev-manager namespace: development subjects: - kind: User name: developer-user apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: dev-resource-manager apiGroup: rbac.authorization.k8s.io

ClusterRoleBindingの定義例です。 secret-viewerClusterRoleを、audit-serviceaccountというサービスアカウントにクラスター全体で割り当てます。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: bind-secret-viewer subjects: - kind: ServiceAccount name: audit-serviceaccount namespace: default roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.io

Service Account

Service Accountは、人間ではないプロセス（例: Pod内のアプリケーションやCI/CDツール）がKubernetes APIと対話するためのIDです。 各Podは、マウントされたService Accountのトークンを使用してAPIサーバーに認証・認可を要求します。 デフォルトでは、各ネームスペースにdefaultというService Accountが自動的に作成されますが、これに権限を付与することは推奨されません。 アプリケーションごとに専用のService Accountを作成し、最小限の権限を割り当てるべきです。 Service Accountの作成例: apiVersion: v1 kind: ServiceAccount metadata: name: my-app-serviceaccount namespace: production

このService AccountをPodに紐付けるには、Podの定義にserviceAccountNameフィールドを追加します。 apiVersion: apps/v1 kind: Deployment metadata: name: my-app-deployment namespace: production spec: selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: serviceAccountName: my-app-serviceaccount containers: - name: my-app image: my-registry/my-app:latest

RBAC実践ガイド：最小権限の原則

最小権限原則とは

最小権限の原則（Principle of Least Privilege: PoLP）とは、ユーザーやプロセスが必要なタスクを実行するために、最小限のアクセス権限のみを付与すべきであるというセキュリティ概念です。 Kubernetes環境では、これにより不正なアクセスや設定ミスが発生した場合の影響範囲を最小限に抑えることができます。 過剰な権限はセキュリティホールとなり得ます。

具体的なRBAC設定例

以下に、一般的なシナリオにおけるRBAC設定の具体例を示します。

開発者向けRBAC設定

特定のネームスペースdev-team-a内で、Pod、Deployment、Service、Ingressなどのアプリケーション関連リソースのget、list、watch、create、update、delete権限を開発者グループに付与します。 apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: dev-team-a name: app-developer rules: - apiGroups: ["", "apps", "networking.k8s.io"] resources: ["pods", "deployments", "services", "ingresses", "configmaps", "secrets"] verbs: ["get", "list", "watch", "create", "update", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: bind-app-developer namespace: dev-team-a subjects: - kind: Group name: dev-team-a-group apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: app-developer apiGroup: rbac.authorization.k8s.io

オペレーター（監視者）向けRBAC設定

クラスター全体のPod、Deployment、Serviceなどのリソースのget、list、watch（閲覧）権限のみをオペレーター向けサービスアカウントに付与します。 これにより、システムの状態を監視できますが、変更はできません。 apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-viewer rules: - apiGroups: ["", "apps", "batch", "extensions"] resources: ["pods", "deployments", "services", "daemonsets", "statefulsets", "jobs", "cronjobs", "configmaps", "secrets"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: bind-cluster-viewer subjects: - kind: ServiceAccount name: monitor-sa namespace: monitoring roleRef: kind: ClusterRole name: cluster-viewer apiGroup: rbac.authorization.k8s.io

Mermaid図: Kubernetes RBAC承認フロー

Kubernetes APIサーバーがリクエストを処理し、RBACによって認可が行われる一般的なフローを図解します。

比較表: RoleとClusterRole、RoleBindingとClusterRoleBinding

RBACの主要な要素の違いを以下の表で整理します。

RBAC設定のベストプラクティスと監査

ベストプラクティス

• デフォルトService Accountの使用を避ける: Podには必ず専用のService Accountを割り当て、最小限の権限を付与してください。 ワイルドカード（*）の使用は慎重に: rules.verbs: ["*"] や rules.resources: ["*"] は強力な権限を与えるため、特別な理由がない限り避けるべきです。 必要な権限のみを明示的に指定してください。 特定のネームスペースにスコープを限定する: 可能であれば、RoleとRoleBindingを使用して権限のスコープをネームスペース内に限定し、ClusterRoleやClusterRoleBindingの使用は最小限に留めてください。 権限の定期的な見直しと監査: 時間の経過とともに権限が過剰になることがあります。 定期的にRBAC設定を見直し、不要な権限がないか確認してください。 kubectl auth can-i コマンドの活用: 特定のユーザーやサービスアカウントが、特定のリソースに対してどのような操作が可能かを確認する際に役立ちます。 例: kubectl auth can-i create pods --namespace dev-team-a --as developer-user

権限監査ツール

RBAC設定の複雑さから、手動での監査は困難になることがあります。 以下のツールを活用することで、セキュリティリスクを特定しやすくなります。

• Kube-audit: RBACの設定ミスや脆弱性を検出するツールです。 Polaris: Kubernetesのセキュリティとベストプラクティスを検証するためのオープンソースツールで、RBAC設定の推奨事項も提供します。 Kubernetes APIサーバーの監査ログ: APIサーバーの監査ログを有効にすることで、誰が、いつ、どのような操作を行ったかを詳細に記録し、不正なアクセスや操作の検知に役立てることができます。

注意点とトラブルシューティング

RBACは強力な一方で、設定ミスは予期せぬアクセス拒否や過剰な権限付与につながります。

• 権限が効かない場合: kubectl describe rolebinding [name] -n [namespace] や kubectl describe clusterrolebinding [name] で定義されているroleRefが正しいか、subjectsが正しく指定されているかを確認してください。 また、kubectl auth can-iで実際にその操作が可能かテストすることも重要です。 APIバージョンの違い: RBACリソースのapiVersionはrbac.authorization.k8s.io/v1を使用することを推奨します。 既存のRBACポリシーの確認: kubectl get roles --all-namespaces、kubectl get clusterroles、kubectl get rolebindings --all-namespaces、kubectl get clusterrolebindings コマンドで現在のRBAC設定を確認できます。 特にkubectl get (cluster)roles -o yamlで詳細を確認しましょう。

まとめ

KubernetesにおけるRBACは、クラスターセキュリティの基盤であり、最小権限の原則を実装することで不正アクセスや設定ミスによるリスクを大幅に軽減します。Role、ClusterRole、RoleBinding、ClusterRoleBinding、Service Accountといった主要な構成要素を理解し、具体的な設定例とベストプラクティスを適用することが重要です。定期的な監査と適切なツールの活用により、より安全で堅牢なKubernetes環境を維持しましょう。