AWS运维部署实践--配置跨账号通过kubectl管理EKS集群
# 前言
通常我们的eks集群都应该是集中管理的,在同一账号中,可直接通过集中的某台主机进行管理,但在跨账号场景中,则需要费一番周折,此处记录下配置的过程。
需求:想要在A账号的主机X上,通过kubectl管理B账号下的EKS集群。
先概述下配置思路:在
B账号中创建角色,并将角色共享给A账号,然后A账号创建一个用户,通过该用户,来实现认证并管理集群的功能。
# 在B账号的操作
这里假设B账号的EKS集群已经成功创建,并且在B账号的某台服务器上已经配置好了集群认证。
# 创建授权的角色
来到B账号的IAM中,找到角色,点击创建角色:

步骤1选择账号,步骤2填入A账号的ID。
点击下一步,是授予该角色具体的权限,一般授予其AmazonEKSClusterPolicy和AmazonEKSWorkerNodePolicy的权限即可。
再往下给该角色做下命名,创建即可。
创建完成之后,会获得一个重要的信息,该角色的ARN,例如:arn:aws:iam::00000008:role/aws3-iam-aws1。
# 更新集群认证
上一步创建了角色之后,现在需要将上一步的角色,添加到EKS集群的认证中。
现在登录到B账号中已经配置好集群认证的服务器,如果没有配置好,可通过如下命令更新kubeconfig:
$ aws eks update-kubeconfig --region ap-southeast-1 --name aws3-sgp-eks-cluster
然后编辑aws-auth的configmap。
$ kubectl edit configmap aws-auth -n kube-system
将如下内容添加上去:
mapRoles: |
- rolearn: arn:aws:iam::00000008:role/aws3-iam-aws1
username: aws-a-account-user
groups:
- system:masters
2
3
4
5
6
7
8
保存并退出,保存成功之后,即表示这个IAM角色拥有了集群的管理员权限。
# 在A账号操作
概述:在A账号的操作就是创建一个用户,关联上边的角色,然后生成秘钥,之后再在
X服务器上配置aws cli认证,然后再update-kubeconfig即可。
创建策略
在A账号找到
IAM,然后点击策略,创建策略,并将如下权限关联给该策略:{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::00000008:role/aws3-iam-aws1" } ] }1
2
3
4
5
6
7
8
9
10创建用户
然后点击用户,创建一个EKS用户(此用户可只开通编程访问),关联上上一步的策略。
生成秘钥
然后给刚刚创建的用户,生成一个秘钥。
配置秘钥认证
拿上秘钥,来到A账号的服务器X,执行如下命令配置访问秘钥:
aws configure1输入以下信息:
- AWS Access Key ID:
Your_Access_Key_ID - AWS Secret Access Key:
Your_Secret_Access_Key - Default region name:
YOUR_REGION(例如,ap-southeast-1) - Default output format:
json。
- AWS Access Key ID:
配置aws配置文件支持角色假设
编辑
~/.aws/config文件,添加一个配置文件以允许用户假设账户A的角色。例如,添加以下内容:[profile eks-account-aws3] role_arn = arn:aws:iam::00000008:role/aws3-iam-aws1 source_profile = default1
2
3这里,
default是使用刚配置的访问密钥的默认配置文件,eks-account-a是您为账户A角色假设创建的新配置文件名称。生成kubeconfig
然后直接执行命令获取配置:
$ aws eks update-kubeconfig --region ap-southeast-1 --name aws3-sgp-eks-cluster --profile eks-account-aws31需要注意,此命令中,指定的
--profile是上一步骤中对应的profile名字。生成之后,你查看一下kubeconfig文件,会发现,此文件内有一个内容如下:
env: - name: AWS_PROFILE value: eks-account-aws31
2
3因此,后续你所执行的bash里边,在~/.aws/config里边,必须要要包含第5步所配置的内容,否则此配置文件也无法正常工作。
验证
kubectl get nodes1此处除了确保上边的权限配置正确之外,还需要注意,要提前把
A和B两个账号的VPC进行打通。
# 补充
我看到还有一种更简便的在A账号的操作方案,未经验证,在此简单记录。
在A账号创建一个IAM角色,该角色关联的策略如下:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_B_ID:role/EC2Role" }, "Action": "sts:AssumeRole", "Condition": {} } ] }1
2
3
4
5
6
7
8
9
10
11
12
13然后直接在A账号的服务器X上配置角色切换
使用AWS CLI的
aws sts assume-role命令获取临时凭证:aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_A_ID:role/eks-cross-account-role --role-session-name EKSAccessSession1将返回的
AccessKeyId、SecretAccessKey和SessionToken配置为环境变量,或存储在~/.aws/credentials文件中。相当于当前bash已拥有了刚才角色关联的权限,那么接下来直接update-kubeconfig就可以拿到集群的认证信息了。
# 最后
如此就可以实现在一个账号的某台服务器,集中管理不同账号中的EKS集群了。之所以有这个需求,是在多个账号,但是发布系统集中在某台服务器的场景中。
但是需要注意的是,如果账号或者集群存在多个,那么你的配置文件可能不好兼容,所以建议最后执行kubectl部署的环境,封装到一个容器里边,然后借助jenkins的容器执行的方法进行部署。
如果你还有更好的方案,或者有什么其他方法,欢迎在评论区留言交流。
|