【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道場でお会いしましょう！押忍🔥