# 前言

通常我们的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

保存并退出，保存成功之后，即表示这个IAM角色拥有了集群的管理员权限。

# 在A账号操作

概述：在A账号的操作就是创建一个用户，关联上边的角色，然后生成秘钥，之后再在X服务器上配置aws cli认证，然后再update-kubeconfig即可。

1. 创建策略

   在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
   

2. 创建用户

   然后点击用户，创建一个EKS用户(此用户可只开通编程访问)，关联上上一步的策略。

3. 生成秘钥

   然后给刚刚创建的用户，生成一个秘钥。

4. 配置秘钥认证

   拿上秘钥，来到A账号的服务器X，执行如下命令配置访问秘钥：

   输入以下信息：

   • 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。

5. 配置aws配置文件支持角色假设

   编辑~/.aws/config文件，添加一个配置文件以允许用户假设账户A的角色。例如，添加以下内容：

   [profile eks-account-aws3]
   role_arn = arn:aws:iam::00000008:role/aws3-iam-aws1
   source_profile = default
   

   1
   2
   3
   

   这里，default是使用刚配置的访问密钥的默认配置文件，eks-account-a是您为账户A角色假设创建的新配置文件名称。

6. 生成kubeconfig

   然后直接执行命令获取配置：

   $ aws eks update-kubeconfig --region ap-southeast-1 --name aws3-sgp-eks-cluster --profile eks-account-aws3
   

   1
   

   需要注意，此命令中，指定的--profile是上一步骤中对应的profile名字。

   生成之后，你查看一下kubeconfig文件，会发现，此文件内有一个内容如下：

       env:
         - name: AWS_PROFILE
           value: eks-account-aws3
   

   1
   2
   3
   

   因此，后续你所执行的bash里边，在~/.aws/config里边，必须要要包含第5步所配置的内容，否则此配置文件也无法正常工作。

7. 验证

   此处除了确保上边的权限配置正确之外，还需要注意，要提前把A和B两个账号的VPC进行打通。

# 补充

我看到还有一种更简便的在A账号的操作方案，未经验证，在此简单记录。

1. 在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
   

2. 然后直接在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 EKSAccessSession
     

     1
     

   • 将返回的AccessKeyId、SecretAccessKey和SessionToken配置为环境变量，或存储在~/.aws/credentials文件中。

   • 相当于当前bash已拥有了刚才角色关联的权限，那么接下来直接update-kubeconfig就可以拿到集群的认证信息了。

# 最后

如此就可以实现在一个账号的某台服务器，集中管理不同账号中的EKS集群了。之所以有这个需求，是在多个账号，但是发布系统集中在某台服务器的场景中。

但是需要注意的是，如果账号或者集群存在多个，那么你的配置文件可能不好兼容，所以建议最后执行kubectl部署的环境，封装到一个容器里边，然后借助jenkins的容器执行的方法进行部署。

如果你还有更好的方案，或者有什么其他方法，欢迎在评论区留言交流。