1. はじめに
EKS クラスターを作成したのはいいが、kubectl で Kubernetes API をコールした際、アクセス権限のエラーが出力されたということはありませんか。
よくある理由としては、デフォルト設定では、 Kubernetes API のコールは、クラスターを作成した IAM ユーザーや IAM ロールに限られます。
クラスターは、Terraform 等でクラスター作成され、Terraform 用 IAM ユーザーが利用されることが多いとおもいます。
そのため、自分自身のIAM ユーザーで Kubernetes API をコールしても、Kubernetes API にアクセスする権限が与えられていないため、Kubernetes API を呼び出すことができないのです。
こういった際にKubernetes API をコールする必要がある IAM ユーザーやロールにアクセス権限を与えるために利用されるのが、Access Entry です。
本記事では、Access Entry の説明や設定例について記述してゆきます。
2. Access Entry とは？
Access Entry とは、Kubernetes内部の設定ファイル（aws-auth ConfigMap）を触ることなく、AWS側（IAM）だけでEKSクラスターのアクセス権限を一元管理できる機能です。
2.1. クラスターの認証モード（Authentication Mode）
Access Entry を利用するにあたり、EKSクラスターには「認証モード」という設定が用意されています。これにより、従来の権限管理から新しい Access Entry へどのように移行するかを制御できます。
| 認証モード | 概要 | 補足・ユースケース |
|---|---|---|
CONFIG_MAP |
従来の方式です。aws-auth ConfigMap のみを使用して権限を管理します。 |
互換性のために残されていますが、現在は非推奨です。 |
API_AND_CONFIG_MAP |
Access Entry（API）と aws-auth ConfigMap の両方を評価します。 |
既存のクラスターから新しい方式へ安全に移行したい場合に最適です。 |
API |
aws-auth ConfigMap を完全に無視し、Access Entry のみで権限を管理します。 |
新規クラスターにおけるベストプラクティスです。 |
2.2. Access Entryの必要性
Access Entry 以前は、aws-auth ConfigMap という機能で認証が利用されていましたが、現在は非推奨となっています。
aws-auth では、いくつかの運用上の問題がありました。
- aws-auth ConfigMapの問題点
- aws-auth ConfigMapは、設定の誤りや誤削除によって、管理者を含む全員がクラスターから完全に締め出されるリスクがある
- クラスター作成者のクラスター管理者権限を削除することができない
Access Entry では、Kubernetesの内部を触ることなくAWS API経由で安全かつシンプルにアクセス権限を管理できるため、これらの問題がすべて解決されています。
3. 設定例（Terraform）
実際に Terraform を使用して、特定の IAM ユーザーやルートアカウント、踏み台サーバー（Bastion）用の IAM ロールにクラスターの管理者権限を付与する設定例です。
# 1. 開発用・管理用のIAMユーザー（例: terraformユーザー）への権限付与
resource "aws_eks_access_entry" "console_user" {
cluster_name = module.eks.cluster_name
principal_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:user/terraform"
type = "STANDARD"
}
resource "aws_eks_access_policy_association" "console_user_admin" {
cluster_name = module.eks.cluster_name
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
principal_arn = aws_eks_access_entry.console_user.principal_arn
access_scope {
type = "cluster"
}
}
# 2. ルートアカウントへの権限付与（エマージェンシー用）
resource "aws_eks_access_entry" "root_user" {
cluster_name = module.eks.cluster_name
principal_arn = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
type = "STANDARD"
}
resource "aws_eks_access_policy_association" "root_user_admin" {
cluster_name = module.eks.cluster_name
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
principal_arn = aws_eks_access_entry.root_user.principal_arn
access_scope {
type = "cluster"
}
}
# 3. 踏み台サーバー（Bastion）のIAMロールへの権限付与
resource "aws_eks_access_entry" "bastion" {
cluster_name = module.eks.cluster_name
principal_arn = var.bastion_iam_role_arn
type = "STANDARD"
# クラスターが作成された後に実行されるよう制御
depends_on = [module.eks]
}
resource "aws_eks_access_policy_association" "bastion_admin" {
cluster_name = module.eks.cluster_name
policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
principal_arn = var.bastion_iam_role_arn
access_scope {
type = "cluster"
}
# Access Entryが作成された後にポリシーを紐付ける
depends_on = [aws_eks_access_entry.bastion]
}
このように Terraform でEKS クラスターと 必要なIAM ユーザーと IAM ロールだけを簡潔にマッピングすることができます。
※ ここでは、AmazonEKSClusterAdminPolicy をロールに割り当てていますが、実運用する際は、最小権限で権限付与することをおすすめします。
4. おわりに
今回は Amazon EKS の Access Entry について、その概要と Terraform での設定例を紹介しました。
これまでの aws-auth ConfigMap 運用上の問題でAccess Entry の登場によって改善されました。
Kubernetes の内部リソース（ConfigMap）に触れることなく、IAMだけで権限を一元管理できるのは、運用面で楽になるはずです。
これから新しく EKS クラスターを構築する際は、ぜひ認証モードを API に設定し、Access Entry を利用してみることをおすすめします。
5. 参考
EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する