【Day7】EKSの門を開け！RBACでユーザーに正しい力を授けよ！
クラスタは完成した。Podもサービスも無事に動いている。
しかし、仲間の開発者がこう言った――
「あれ？自分のIAMユーザからだとPodが見れないんだけど…？」
そう、EKSクラスタを作成したあなたにだけ、「神の権限」が与えられていたのだ。
🔰 はじめに：なぜRBACが必要なのか？
Kubernetesでは、IAMのような「誰が何をできるか」の制御をRBAC（Role-Based Access Control）という仕組みで行います。
AWS IAMと違い、Kubernetes内部での「見える・操作できる」対象は、RBACで管理されます。
🧙♂️ クラスタ管理者は誰か？EKSの初期権限の仕組み
EKSクラスタをeksctlで作成すると、EKSクラスタ作成者のIAMユーザー/ロールにだけ、次のような特権が与えられます：
system:mastersというKubernetesの最上位グループにマッピング
→kubectlを使えるのはこのユーザー/ロールだけ！
例えば僕が今回EKSクラスタを作成したIAMユーザは「eks-user」ですが、Administrator権限を持っており、Podに何があるかを見ることができます。
他のIAMユーザーはたとえAWSのIAM側でAdministrator権限を保持していても、何も見えません。
例えばAdministrator権限を持ったIAMユーザ「eks-user-2」を作成して、EKSクラスタのリソースを確認しようとしても、権限によりみることができなくなります。
🛠️ IAM Identity Mapping で道を開く
新たなユーザーにEKSへのアクセスを許すには、IAM Identity Mappingを使います。
以下のように実行することで、別のIAMユーザをEKSのUserとして登録し、system:mastersの権限を与えることができます：
eksctl create iamidentitymapping \
--cluster eks-dojo \
--region ap-northeast-1 \
--arn arn:aws:iam::123456789012:user/eks-user-2 \
--group system:masters \
--username devops
--arn: マッピングしたいIAMユーザー or ロールのARN
--group: 割り当てるKubernetesグループ（ここで権限を制御！）
登録したら、eks-user-2でも見ることができるようになりました！
🧩 カスタム権限を定義せよ！RoleとRoleBindingの力
system:mastersは強力すぎることも。
たとえば「ログの閲覧だけできるユーザー」がほしい場合、最小権限のRoleを定義して、Bindingするのがベストです。
✅ ClusterRole の例（ログ閲覧専用）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
✅ ClusterRoleBinding の例（IAMロールをバインド）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: bind-pod-logs-reader
subjects:
- kind: User
name: "arn:aws:iam::123456789012:role/ReadOnlyRole"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-logs-reader
apiGroup: rbac.authorization.k8s.io
💡 RBACの権限テスト：できること・できないことを確認せよ
ログ閲覧ロールを割り当てたユーザーでログ確認：
kubectl get pods
kubectl logs <pod-name>
Podの削除などは禁止される↓
kubectl delete pod <pod-name> # → エラー（権限不足）
🧠 補足修行：RBACとIAMはどう違うの？
| 比較軸 | AWS IAM | Kubernetes RBAC |
|---|---|---|
| 制御対象 | AWSリソース（S3, EC2など） | Kubernetesリソース（Pod, Serviceなど） |
| 設定単位 | IAMユーザー/ロール | Kubernetesユーザー/グループ |
| 実体 | AWS側の権限管理 | K8s APIサーバーでのアクセス制御 |
この2つをうまく連携させるのが、IRSAやIAM Identity Mappingの技術です。
✅ まとめ
EKSでは、作成者だけが最初からsystem:mastersに所属している
他のユーザーにはIAM Identity Mappingが必要
RBACで細かい権限制御を行うことで、安全で柔軟な運用が可能に！
次回予告 📢：IRSAの真髄！Podに権限を授けてS3へアクセスせよ！
今回はIAMユーザ・IAMロールからKubernetesの世界へアクセスするための権限について解説しました。
次は、PodからAWSリソースへアクセスするにはどう設定すればよいかを解説していきます！
よければフォロー＆いいねお願いします🙏
- 「面白かった」「続きが気になる！」と思ったらLGTM👍
- コメントで「聞きたい内容」「つまずきポイント」などもぜひ教えてください！
それではまた明日、EKS道場でお会いしましょう！押忍🔥