aws-auth と Access Entry の違いまとめ
EKS には2025年現在 aws-auth ConfigMap と Access Entry 2つの認証方式があります。aws-auth ConfigMap は廃止がアナウンスされており、各社で Access Entry への移行が進められています。それぞれの特徴についてまとめました。
TL;DR
- aws-auth
- ConfigMap を設定して IAM/RBAC を紐づけ
- Access Entry
- EKS API で設定が完結
- Access Policy という抽象化層
- IAM と Access Policy を紐づけ
aws-auth
以下のような ConfigMap を設定することで AWS IAM と k8s RBAC を紐づける仕組みです。
apiVersion: v1
data:
mapRoles: |
[]
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::11111111:user/hoge
username: hoge
kind: ConfigMap
AWS IAM でログインするだけでシームレスに k8s API を実行できる点と、権限も柔軟に設定することができるのが特徴になります。上記の設定例では system:masters （何でも出来る権限）を割り当てていますが、より権限を狭めた別の Grop を割り当てることもできます。
AWS と k8s のユーザを個別に管理しなくてすむのは便利な一方、単一の ConfigMap ですべての IAM/RBAC の紐づけを管理しているため、ユーザを追加しようとして設定をミスると権限管理全体が壊れて EKS クラスタへアクセスできなる可能性があります。
k8s の権限設定をするために k8s API を実行する必要があるという、鶏卵問題のような状況を解決しつつ、より使いやすいインターフェースを提供しているのが後述する Access Entry になります。
Access Entry
k8s の認証・認可設定を EKS API で完結する仕組みです。
以下で aws-auth の時に出した例と同じ設定内容になります。
$ aws eks create-access-entry \
--cluster-name test-cluster \
--principal-arn arn:aws:iam::11111111:user/hoge
$ aws eks associate-access-policy \
--cluster-name test-cluster \
--principal-arn arn:aws:iam::11111111:user/hoge \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
--access-scope type=cluster
access-policy がポイントです。access-policy とは AWS が用意した k8s の権限セットで IAM と紐づけることができます（IAM ポリシーと似ていますが IAM の権限は含まれていません）。これによって RBAC を一切触らずに k8s の権限設定を行うことが出来るようになっています。
どの access-policy が何の k8s 権限を持っているかは公式ドキュメントでまとめられています。
ちなみに access-policy ではカバーしきれない細かな権限設定もできるようになっており、以下のように k8s group を IAM に直接紐づけることもできます（つまり access-policy と k8s group を併用できます）。
$ aws eks create-access-entry \
--cluster-name test-cluster \
--principal-arn arn:aws:iam::11111111:user/hoge
--kubernetes-group hoge
まとめ
aws-auth、Access Entry の何れも「IAM 認証したユーザ（またはロール）で k8s API を実行できるようにする」という点は同じです。
異なる点は認証ユーザに対してどのように権限を付与するかという認可の方法です。aws-auth は RBAC を使って IAM と k8s API を紐づけているのに対し、Access Entry では access-policy を使うことで AWS の世界のみで認可までを完結しているのが違いになります。これが Access Entry の特徴だと言えます。
補足
aws-auth と Access Entry は併用して利用することができます。
この場合、どちらで認証しているかを確認したくなるケースがあると思いますが、監査ログから確認できます。
以下 CloudWatch Logs Insights を使った確認例です。
fields @timestamp, userAgent, requestMethod, @message
| filter userAgent like "kubectl"
| sort @timestamp desc
aws-auth の場合
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": ""
}
Access Entry の場合
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "EKS Access Policy: allowed by ClusterRoleBinding \"arn:aws:iam::11111111:user/hoge+arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy\" of ClusterRole \"arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy\" to User \"XXXXXXXXXXXXXX\""
}
Discussion