
使用 EKS Access Entry 拯救并恢复集群的访问权限
在过去,管理 Amazon Elastic Kubernetes Service (EKS) 集群的访问权限通常需要依赖 AWS IAM Authenticator 和 aws-auth ConfigMap 的组合。然而,这样的管理方式可能遇到格式错误、自动化更新困难以及 IAM 用户被删除等限制和问题。
为了解决这些问题,EKS 发布了一项新的验证方式 — EKS Access Entry,提供了一个新的优化的解决方案。通过 EKS Access Entry,简化了 aws-auth ConfigMap 的管理配置,甚至在某些场景下恢复 EKS 集群的访问权限。
为什么这个功能这么重要
在过去,Amazon EKS 整合了 IAM 作为主要的身份认证,然而,其中的身份认证仍依赖运行在 EKS 中的 AWS IAM Authenticator 进行验证,这项验证机制需要通过 aws-auth ConfigMap 进行管理。通常,这样的工作流程并不是什么大问题,但随着 EKS 不同使用场景的增加,衍生了几个限制和问题:
- 直接编辑 aws-auth ConfigMap 很容易遇到一些格式问题,例如:缩排错误、不正确的语法和格式、新版的 yaml 与目前线上环境中应用的不一致,新的 yaml 文件导致覆盖了过去的设定,以上种种都有可能不小心造成灾难。
- 整合 CI/CD pipeline 要达到自动化更新需要依赖 Kubernetes 资源的更新 (aws-auth ConfigMap)。不论是 AWS Lambda、Terraform、CloudFormation 或是 CDK,在过去,必须得通过调用 Kubernetes API 达到资源更新控制,难以通过 AWS EKS 本身提供的 API 完成自动化和权限管理,同时,在使用较严谨的 Kubernetes Role-Based Access Control (RBAC) 集群的安全管理下,团队中的开发者使用有限的 Kubernetes 用户身份可能难以通过 Kubernetes API 更新 aws-auth ConfigMap
- 当初创建 EKS Cluster 的 IAM 用户被删除使得团队无法访问 EKS Cluster,也就是本篇内容讨论的主题。常见于整合 AWS Single-Sign On (AWS SSO) 或是同事离职的情境。即使是 AWS 的 Root 账号也没有办法恢复 Kubernetes Cluster 的访问权限
为了解决这个问题,我们可以导入使用 EKS Access Entry 优化 EKS 集群的权限管理,甚至在上述情况中,拯救并恢复集群的访问权限。EKS Access Entry 是一个解决方案,可以让管理者在无需 IAM 用户的情况下,恢复对 EKS 集群的访问权限。
深入了解 EKS Access Entry 的新功能
EKS Access Entry 是一种用于管理 Amazon EKS 集群访问权限的新解决方案。它提供了一个优化的方式来管理集群的验证模式和访问策略,并解决了过去使用 IAM Authenticator 和 aws-auth ConfigMap 管理访问权限所遇到的限制和问题。
默认情况下,在创建 EKS 集群时,会自动赋予操作创建 EKS Cluster 的 IAM 身份在 Kubernetes 的 Role-Based Access Control (RBAC) 中创建规则和 Kubernetes User,并且赋予 system:master
的操作身份。
Kubernetes Role-Based Access Control (RBAC) 是什么?
Kubernetes Role-Based Access Control (RBAC) 是一种在 Kubernetes 集群中实现授权和权限管理的机制。使用 RBAC,您可以定义角色和角色绑定,以授予用户或服务账户对集群资源的特定权限。
EKS 验证身份验证机制
回顾前面所提,在 EKS 中,默认只为创建 EKS Cluster 的 IAM 身份 (比如:arn:aws:iam::123456789:user/eason
) 赋予 system:master
群组操作身份。如果要允许一个新的 IAM 用户 (比如:arn:aws:iam::123456789:user/developer
) 能够操作 EKS Cluster,在 IAM 控制台中设定任何的 IAM 策略,是无法授权任何 EKS Cluster 的访问权限,而是需要通过更新 aws-auth
ConfigMap 资源来赋予其他 IAM 身份的访问:
例如:要为我的 IAM 用户授权访问 EKS Cluster,可以通过使用 kubectl 命令为 aws-auth
ConfigMap 中新增一个 mapUsers
区块,其中包含了指定了一个使用者的 ARN (arn:aws:iam::123456789:user/developer
) ,并且关联 system:master
群组,表示 developer
使用者现在具有访问 EKS Cluster 的访问权限。
$ kubectl get cm/aws-auth -o yaml -n kube-system
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::123456789:role/EKSManagedNodeWorkerRole
username: system:node:
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::123456789:user/developer
username: developer
支持 EKS Access Entry 后的集群验证模式变更
这项更新支持以下 Kubernetes 和平台之后版本的 EKS Cluster:
Kubernetes version | Platform version |
---|---|
1.28 | eks.6 |
1.27 | eks.10 |
1.26 | eks.11 |
1.25 | eks.12 |
1.24 | eks.15 |
1.23 | eks.17 |
将可以支持两种不同的验证模式:
- IAM 集群验证模式:这是 Amazon EKS 的默认验证模式,它基于 IAM 进行身份验证,并且依赖于
aws-auth
ConfigMap。 - EKS 集群验证模式 (Access Entry):这是 EKS Access Entry 引入的新验证模式。它基于 Kubernetes 的原生身份验证机制,但通过 EKS 本身的 API 完成,使得在 EKS 控制台界面上点一点就能完成允许一个 IAM User/Role 的操作成可能。
在新创建的 EKS Cluster 中,您可能会注意到多了以下选项的更新:
EKS Access Entry 的验证方法
先决条件
在使用 EKS Access Entry 之前,您需要确保以下先决条件已满足:
- 您的 Amazon EKS 集群有启用 EKS Access Entry 功能 (前面提到的验证模式支持 EKS API 而不是只有 ConfigMap)。
- 您具有适当的 IAM 权限,以执行与 EKS Access Entry 相关的操作 (例如:
eks:CreateAccessEntry
、eks:AssociateAccessPolicy
、eks:DeleteAccessEntry
、eks:DescribeAccessEntry
等)。
在启用 Access Entry 验证后,便可以使用这个新的验证方式来管理集群的访问权限。
访问策略的访问权限
每个 access entry 都有一个关联的访问策略,该策略定义了对集群资源的访问权限。访问策略使用 AWS Identity and Access Management (IAM) 的 JSON 格式来定义。以下是访问策略示例:
访问策略 | 描述 | Kubernetes verb |
---|---|---|
AmazonEKSAdminPolicy | 完全管理权限 | * |
AmazonEKSClusterAdminPolicy | 集群管理权限 | - |
AmazonEKSEditPolicy | 读写权限 | create, update, delete, get, list |
AmazonEKSViewPolicy | 只读权限 | get, list |
上述表格可能会随着版本更新有所变化,详情请参考1。
实施并利用 EKS Access Entry 管理或恢复 EKS 集群访问权限
在遇到当初创建 EKS Cluster 的 IAM 用户被删除使得团队无法访问 EKS Cluster 的情况下,若当前的 IAM User/Role 具备 Access Entry 的操作权限,则可以通过这项功能恢复 EKS Cluster 的访问权限 (或是撤销访问权限)。EKS Access Entry 可以使用 AWS CLI 或 AWS Management Console 进行操作。
EKS 控制台 (AWS Management Console)
(1) 在 EKS 集群详细信息页面中,点选 “Access” 选项。
(2) 在 “IAM Access Entries” 页面中,点选右上方的 “Create access entry” 按钮。
(3) 在 “Create access entry” 的对话框中,输入以下信息:
- IAM Principal ARN: 指定 IAM User 或 IAM Role 的 ARN。
- Kubernetes groups: 这个字段用于关联 IAM User/Role 使用 Kubernetes RBAC 里面已经定义的 Kubernetes 群组 (Role & Rolebinding)。若要直接关联预先定义好的 Access Entry Policy (例如:AmazonEKSClusterAdminPolicy
),可以略过
- Kubernetes username: 您希望该 IAM 用户或角色在 Kubernetes 中的用户名称,这里可以输入您希望的名称或是省略,例如 admin
。
(4) 在这个步骤中,可以选择默认的的 Access Entry 以赋予 IAM 身份访问 EKS Cluster 的权限,例如:arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
。
- Access Scope: 用于赋予关联策略影响的范围,例如:指定 IAM 用户只能使用这个权限操作特定 Kubernetes namespace。如果不限制,则选择 Cluster 赋予 IAM 用户可以使用这个权限操作整个集群。
(5) 点选 “Add Policy” 按钮以关联访问策略。
至此,您已成功使用 EKS Access Entry 为 EKS 集群新增了一个 Cluster Admin。
AWS CLI
以下是使用 AWS CLI 通过 EKS Access Entry 为 EKS 集群新增 Cluster Admin 的步骤 (集群名称以eks-cluster
为例):
(1) 更新你的 EKS 集群配置以启用 EKS Access Entry 验证模式 (如果已经操作过这步骤可以省略)
aws eks update-cluster-config \
--name eks-cluster \
--access-config authenticationMode=API_AND_CONFIG_MAP
(2) 创建一个 Access Entry,并指定 IAM principal ARN (例如:IAM User 或 IAM Role,这里使用 arn:aws:iam::0123456789012:role/eks-admin
作为范例)
aws eks create-access-entry \
--cluster-name eks-cluster \
--principal-arn "arn:aws:iam::0123456789012:role/eks-admin"
(3) 将访问策略关联到刚刚创建的 Access Entry。这里以 AmazonEKSAdminPolicy (提供完全的管理权限)为例
aws eks associate-access-policy \
--cluster-name eks-cluster \
--principal-arn "arn:aws:iam::0123456789012:role/eks-admin" \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy \
--access-scope '{"type": "cluster"}
完成以上步骤后,您已成功通过 EKS Access Entry 为 EKS 集群新增了一个 Cluster Admin。
其他权限设定
另一种使用情境为通过 EKS Access Entry 功能与 Kubernetes RBAC 本身的权限关联。
例如,我们可以创建一个名为 pod-and-config-viewer
的 Kubernetes Cluster,并授予该角色查看 Kubernetes Pods 的权限。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-viewer-role
rules:
- apiGroups: ['']
resources: ['pods', 'pods/log']
verbs: ['list', 'get', 'watch']
接着,我们将此角色绑定到 pod-viewers
群组上。
注:Kubernetes Group (pod-viewers
) 不需要事先创建即可操作。
kubectl create clusterrolebinding pod-viewer \
--clusterrole=pod-viewer-role \
--group=pod-viewers
接下来即可直接通过 EKS Access Entry 对应的功能将 IAM 角色 arn:aws:iam::0123456789012:role/eks-pod-viewer
关联到 Kubernetes 群组 pod-viewers
上,进一步强化权限设定的灵活性。
aws eks create-access-entry \
--cluster-name eks-cluster \
--principal-arn "arn:aws:iam::0123456789012:role/eks-pod-viewer" \
--kubernetes-group pod-viewers
总结
本文介绍了 EKS Access Entry,这是 Amazon Elastic Kubernetes Service (EKS) 集群的一种新的访问权限管理方法。此功能解决了过去使用 IAM Authenticator 和 aws-auth ConfigMap 进行权限管理时所遇到的问题,例如格式错误、自动更新困难以及 IAM 用户被删除等问题。相较于传统的方法,EKS Access Entry 提供了一种更优化的方式来管理验证模式和访问策略。
此外,本篇内容也详细说明了如何使用 EKS Access Entry 来管理或恢复 EKS 集群的访问权限,包括在 AWS Management Console 或 AWS CLI 中进行操作的具体步骤。这些解决方案不仅可以在 IAM 用户被删除等紧急情况下恢复集群的访问权限,也可用于日常的权限管理中,提高效率与灵活性。
总结来说,EKS Access Entry 的出现为 EKS 集群的权限管理带来了重大的改进,使得管理者能更有效地实现对 EKS 集群的权限管理,进一步提升效率和灵活性。
参考资料