1. はじめに

EKSではKubernetesのアクセス制御として、IAM、AccessEntry、RBAC、AccessPolicyの仕組みが組み合わさっています。

この記事では、EKSのアクセス制御で登場する次の仕組みを整理します。

EKSのアクセス制御の仕組み
AccessEntryの役割
RBAC（Role Based Access Control）
AccessPolicy

EKSのアクセス制御は次の構造で理解すると整理しやすいです。

IAM
↓
AccessEntry
↓
AccessPolicy / RBAC
↓
Kubernetes API

2. Kubernetesのアクセス制御の基本

　Kubernetesのアクセス制御には次の2つの概念があります。

Authentication（認証）
Authorization（認可）

Authentication（認証）（読み：オーセンティケイション）
ユーザーが「誰であるか」を確認する仕組みです。
AWSでいうと、IAMユーザーやIAMロールなどのIAMプリンシパルを使って
AWSにアクセスする際に本人確認が行われるイメージです。

例えば、サービスにアクセスする際にユーザー名やパスワード、
またはIAM認証（アクセスキーやロールのAssumeRole）によって
「誰がアクセスしているか」が確認されます。

Authorization（認可）（読み：オーソライゼーション）
認証されたユーザーが「何をしてよいか」を決める仕組みです。
AWSではIAMポリシーによって、どのアクションをどのリソースに対して
実行できるかが制御されます。

例えば、特定のIAMロールにS3の読み取り権限や
EC2の操作権限を付与することで、実行できる操作を制限します。

Kubernetesでは、このAuthorization（認可）の仕組みとして RBAC が使用されます。

3. RBACとは？

RBAC（Role Based Access Control）は、Kubernetesの認可（Authorization）を制御する仕組みです。

ユーザーやServiceAccountが、どのKubernetesリソースに対して
どの操作を実行できるかを定義します。

RBACでは主に次のKubernetesリソースを使用します。

ServiceAccount
PodがKubernetes APIにアクセスするためのアカウントです。
PodはServiceAccountを通してKubernetes APIへアクセスします。
Role
特定のNamespace内で操作可能なリソースとアクションを定義します。
例えば、podsの取得（get / list）やDeploymentの作成などの権限を設定できます。
RoleBinding
RoleをServiceAccountやUserに紐付けて権限を付与します。
RoleBindingはNamespaceスコープで動作します。
ClusterRole
クラスター全体に対する権限を定義します。
例えば、Nodeの取得やすべてのNamespaceに対するリソース操作などを定義できます。
ClusterRoleBinding
ClusterRoleをUserやServiceAccountに紐付けて権限を付与します。
ClusterRoleBindingはクラスター全体に対して権限を付与する場合に使用します。

RBACの権限の流れ

Podは直接Kubernetes APIにアクセスするのではなく、
ServiceAccountを通してRBACの権限を利用します。

RBACの基本構造（Namespaceスコープ）

Pod
 │
 │ serviceAccountName
 ▼
ServiceAccount
 │
 │ RoleBinding
 ▼
Role
 │
 ▼
Kubernetes API

Podは ServiceAccount を通してKubernetes APIにアクセス
　　　⇩
RoleBinding が ServiceAccount に Role を紐付ける
　　　⇩
Role に定義された権限が適用される
この構造はNamespace単位の権限管理です。

Namespaceレベルのリソース

Pod
- コンテナを実行する最小単位
Deployment
- Podの作成や更新を管理するリソース
Service
- Podへのアクセスを提供するネットワークリソース
ConfigMap
- アプリケーション設定を管理するリソース
Secret
- パスワードやトークンなどの機密情報を管理するリソース

RBACの基本構造（Clusterスコープ）

Pod / User
 │
 │ ServiceAccount
 ▼
ServiceAccount
 │
 │ ClusterRoleBinding
 ▼
ClusterRole
 │
 ▼
Kubernetes API

Podは ServiceAccount を通してKubernetes APIにアクセス
　　　⇩
ClusterRoleBinding が ServiceAccount に ClusterRole を紐付ける
　　　⇩
ClusterRole に定義された権限が適用される
この構造はクラスター全体に対する権限管理です。

クラスターレベルのリソース

Node
- クラスターに参加しているノード
Namespace
- リソースを論理的に分離する単位
PersistentVolume
- ストレージの実体
StorageClass
- ストレージの種類
VolumeAttachment
- Volumeの接続状態

Role / RoleBinding はNamespace単位の権限管理に使用します。
ClusterRole / ClusterRoleBinding は クラスター全体の権限管理に使用します。

ここまでKubernetesのRBACによる認可の仕組みを説明しました。

しかしEKSでは、RBACの前段にAWSのIAMによる認証が組み合わさります。
次にEKSのアクセス制御の仕組みを見ていきます。

4. EKSのアクセス制御の仕組み

EKSでは、Kubernetes APIへのアクセスを制御するために
次の仕組みが組み合わさっています。

IAM
ユーザーの認証を担当
AccessEntry
IAMプリンシパルをEKSクラスターのアクセス主体として登録
AccessPolicy / RBAC
Kubernetesリソースに対する操作権限を制御

EKSでは、ユーザーがKubernetes APIへアクセスする際に
次のような流れでアクセス制御が行われます。

User
 ↓
IAM
 ↓
AccessEntry
 ↓
AccessPolicy / RBAC
 ↓
Kubernetes API

まずIAMによって「誰がアクセスしているか」が認証されます。

その後、AccessEntryによってIAMプリンシパルが
EKSクラスターへアクセス可能な主体として登録されます。

最後に、AccessPolicyまたはRBACによって
Kubernetesリソースに対する操作権限が決定されます。

仕組み	役割
IAM	認証
AccessEntry	IAMプリンシパルをクラスターアクセス主体として登録
AccessPolicy / RBAC	認可（操作権限）

このように、EKSでは AccessEntryを中心として
IAMの認証結果とKubernetesの権限管理を接続しています。

次に、このアクセス制御の中心となる AccessEntry について説明します。

5. AccessEntryとは

aws-auth ConfigMapからAccessEntryへ

以前のEKSでは、IAMユーザーやIAMロールと
Kubernetesユーザーに関連付ける設定を aws-auth ConfigMap で管理していました。

aws-auth ConfigMapは
kube-system namespace に存在するConfigMapで、
IAMプリンシパルとKubernetesユーザーの対応関係を定義するために使用されていました。

しかしaws-authでは、ConfigMapを直接編集する必要があり、設定ミスによるアクセス不能や管理の複雑さが課題になることがありました。

現在のEKSでは、この問題を解決するために後継として
AccessEntryによるアクセス管理が利用できるようになっています。

AccessEntryの役割

AccessEntryは、IAMプリンシパルに
Kubernetesのアクセス権限を関連付ける仕組みです。

IAM
↓
AccessEntry
↓
Kubernetes permissions
   ├ AccessPolicy
   └ RBAC
↓
Kubernetes API

AccessEntryの権限付与方法

AccessEntryの後の権限付与には、次の2つの方法があります。

AccessPolicyを使用する方法
RBACを使用する方法

AccessPolicyによる権限管理

AccessPolicyは、EKSが提供する
事前定義されたKubernetesアクセス権限です。

AccessPolicyはAWSが管理するポリシーであり、
ユーザーが内容を変更したり、独自のポリシーを作成することはできません。

AccessPolicyを使用することで、
事前に定義された権限を簡単に付与することができます。

IAM
 ↓
AccessEntry
 ↓
AccessPolicy
 ↓
Kubernetes API

例えば次のようなポリシーがあります。

AmazonEKSClusterAdminPolicy
AmazonEKSAdminPolicy
AmazonEKSEditPolicy
AmazonEKSViewPolicy

AccessPolicyは設定がシンプルなため、
基本的なアクセス管理を行う場合に適しています。

例えば、AmazonEKSAdminPolicy には下記のような権限が記載されています。

Kubernetes API グループ	Kubernetes resources	Kubernetes 動詞（許可）
apps	daemonsets, deployments, deployments/rollback, deployments/scale, replicasets, replicasets/scale, statefulsets, statefulsets/scale	create, delete, deletecollection, patch, update

RBACによる権限管理

RBAC（Role Based Access Control）は、
Kubernetes標準のアクセス制御の仕組みです。

AccessEntryでIAMプリンシパルを
Kubernetesユーザーまたはグループに関連付けた後、
RBAC（RoleBinding / ClusterRoleBinding）によって
Kubernetesリソースの操作権限を定義します。

IAM
 ↓
AccessEntry
 ↓
Kubernetes User / Group
 ↓
RoleBinding / ClusterRoleBinding
 ↓
Role / ClusterRole
 ↓
Kubernetes API

RBACでは次のような柔軟な権限制御が可能です。

Namespace単位の権限制御
特定リソースのみ操作可能
read / write の分離

そのため、より細かいアクセス制御が必要な場合に使用されます。

#　6. AccessPolicyとRBACの使い分け

EKSでは、AccessPolicyとRBACのどちらでも権限管理が可能です。

方法	特徴
AccessPolicy	設定が簡単（EKSが提供する事前定義ポリシー）
RBAC	柔軟な権限制御（Kubernetes標準の仕組み）

実際のEKS運用では、次のように使い分けることが多いです。

簡単な権限管理
→ AccessPolicy
例：開発者・運用IAMロール
Namespace単位など細かい権限制御
→ RBAC
例：アプリごとのNamespaceアクセス制御や
　　特定リソースのみ操作可能な権限設定

AccessEntryのメリット

AccessEntryを使用することで、次のようなメリットがあります。

IAMベースでアクセス管理ができる
aws-auth ConfigMapを直接編集する必要がない
AWS CLIやConsoleからアクセス管理が可能
IAMとKubernetesのアクセス制御を整理して管理できる
IAMロール単位でアクセス管理ができる

6. まとめ

EKSアクセス制御のポイント

IAMでユーザーを認証
AccessEntryでKubernetesアクセス主体を登録
AccessPolicy / RBACで操作権限を管理

7. 所感

今回はEKSアクセス制御の仕組みを整理してみました。
EKSのアクセス制御は実務で使っているとは言え、記事に書けるほどは理解していなかったのですが、本記事を作成することで理解が深まりました。KubernetesはAWS同様にサービスが多く、完全に理解するのは難しいと思いますが、実務や学習をする中で今後も学びを深めていきたいと思います。