はじめに
Kubernetes では、認可を通常 RBAC（Role-Based Access Control）で管理します。
- ユーザー：従業員（例：
Jane）。 - Role：特定のアクセス権を持つ キーカード（例：「サーバールームに入れる」「ドキュメントを読める」）。
- RoleBinding：従業員に キーカードを渡す 操作。
RBAC が重要なのは、クラスターへのアクセスが認証だけで決まるわけではないためです。ユーザーの身元が確認された後も、そのユーザーが実行できる操作をシステムが判断する必要があります。
この実験では、セキュリティ責任者として次の作業を行います。
- 物を見ることはできても、変更はできない「ビジターパス」（Role）を作成します。
- このパスを
janeというユーザーに割り当てます。 - Jane がクラスター内を確認できる一方、変更しようとすると拒否されることを検証します。
Role を定義する
まず、権限のセットを作成します。ここでは「読み取り専用」の Role を作成します。この Role では、Pod を list および get（読み取り）できますが、Pod の create や delete はできません。
RBAC は Kubernetes の認可の仕組みであり、認証の仕組みではありません。認証は「あなたは誰ですか？」という問いに答えます。認可は「あなたに何が許可されていますか？」という問いに答えます。この実験では、特定のリソースタイプに対して許可する操作を verb として明示的に定義し、2 番目の問いに取り組みます。
role.yaml という名前のファイルを作成します。
nano role.yaml
次の YAML を貼り付けます。この定義により、pods に対して get、watch、list 操作を実行できる Role が作成されます。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] ## "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Ctrl+X、Y、Enter の順に押して保存し、終了します。
次に、このキーカードをクラスターに反映（「apply」）します。
kubectl apply -f role.yaml
Role が存在することを確認します。
kubectl get roles
出力に pod-reader が表示されます。
Role をバインドする
これで、キーカード（pod-reader）と従業員（jane）が用意できました。しかし、Jane にはまだキーカードが渡されていません。両者を関連付けるために RoleBinding が必要です。
Role は、バインドによって参照されるまで、単独では何の権限も付与しません。この分離は意図的なものです。管理者は、再利用可能な権限のまとまりを一度定義し、それを必要に応じて異なるユーザー、グループ、サービスアカウントに割り当てられます。
rolebinding.yaml という名前のファイルを作成します。
nano rolebinding.yaml
次の内容を貼り付けます。これは「pod-reader Role をユーザー jane にバインドする」という意味です。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane ## The employee
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader ## The key card
apiGroup: rbac.authorization.k8s.io
Ctrl+X、Y、Enter の順に押して保存し、終了します。
バインドを適用します。
kubectl apply -f rolebinding.yaml
これで、Jane に default Namespace の読み取り専用アクセスを正式に付与できました。
アクセスを確認する
どのようにテストすればよいでしょうか。Jane としてログアウトしてログインし直す必要はありません。Kubernetes では、--as フラグを使ってユーザーを「なりすまし」、権限をテストできます。
これは実用的な管理手法です。実際のユーザーや自動化用アカウントにアクセス権を渡す前に、ユーザーをシミュレートして権限を確認すれば、より安全に権限を検証できます。クラスターに不要な副作用を発生させずに、意図した設定になっているかを確認できます。
まず、Jane が Pod を一覧表示できることを確認します。
kubectl auth can-i list pods --as jane
出力は yes になります。
特定の Pod の詳細を取得できるかどうかも確認できます。
kubectl auth can-i get pods --as jane
この出力も yes になります。
これで、RoleBinding が正しく機能していることを確認できました。キーカードがドアの読み取り機で機能しています。
制限を確認する
セキュリティでは、できないこと も重要です。Jane に付与されているのは pod-reader Role だけなので、変更操作は厳密に禁止されているはずです。
これは、最小権限 の原則を実践したものです。広範なアクセス権を付与してユーザーが慎重に操作することを期待するのではなく、タスクに必要な最小限の権限から始め、実際に運用上の必要性が生じた場合だけ権限を追加します。
Jane が Pod を作成できるか確認します。
kubectl auth can-i create pods --as jane
出力は no になります。
Jane が Pod を削除できるか確認します。
kubectl auth can-i delete pods --as jane
出力は no になります。
Jane が実際にこれらのコマンドを実行しようとすると、API サーバーは「Forbidden」エラーを返してリクエストを拒否します。これにより、クラスターが保護され、最小権限 の原則に従っていることを確認できます。
まとめ
この実験では、RBAC を使用してクラスターを保護しました。
次の作業を完了しました。
- 限定された読み取り専用権限を持つ Role（「キーカード」）を作成しました。
- RoleBinding を作成し、そのキーカードをユーザー
janeに渡しました。 janeが確認はできるものの、変更はできないことを検証しました。
これは、Kubernetes におけるマルチユーザーセキュリティの基礎です。全員に完全な管理者アクセスを決して与えないでください。
