After writing part 1 and part 2 on how to authenticate IAM Users against EKS my friend Yossi Cohen kindly suggests in cases when we build CICD into AWS it’s more desirable to use IAM Roles to mitigate the hassle of setting up IAM Users. Thanks for his suggestion and I decided to give it a run as well to draw a good picture on various ways to access EKS.
Some prerequisites after you spin up an EC2 instance in Account B.
- AWS CLI v2.0.1 or above
- Kubectl
- AWS Role, called eks-admin-role
Account A
At part 2 we’ve learned that we need to create a cross-account trust relationship between Account A and Account B for the Role we created in Account A, called eks-admin-role as well:
What it basically says that I trust Account B’s Role named eks-admin-role.
Let’s configure EKS RBAC to ensure this Role has admin access to the EKS cluster. So, when EC2 in Account B assumes this Role EKS will allow its access.
Account B
The only permission I need for the Role is to be able to assume the role:
We can also verify that we have this Role attached to the EC2:
Now, let’s turn our attention to the kube config on the EC2 of the Account B:
Because we allow Account B’s Role to assume Account A’s Role aws eks get-token will succeed.
Now, you can access Account A’s EKS Cluster without using IAM Users at all:
> kubectl get all -n kube-system
NAME READY STATUS RESTARTS AGE
pod/aws-node-qj2hg 1/1 Running 0 3h51m
pod/coredns-56678dcf76-5j5q6 1/1 Running 0 3h55m
pod/coredns-56678dcf76-w5bgt 1/1 Running 0 3h55m
pod/kube-proxy-9qz27 1/1 Running 0 3h51mNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kube-dns ClusterIP 10.100.0.10 <none> 53/UDP,53/TCP 3h55mNAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/aws-node 1 1 1 1 1 <none> 3h55m
daemonset.apps/kube-proxy 1 1 1 1 1 <none> 3h55mNAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/coredns 2/2 2 2 3h55mNAME DESIRED CURRENT READY AGE
replicaset.apps/coredns-56678dcf76 2 2 2 3h55m
