- Newest
- Most votes
- Most comments
It is a best practice to use an AWS IAM role principal to create an Amazon EKS cluster. In that case, you would not have to delete the role, as much as remove access to it for users no longer needing it. There is a unique ID for each AWS IAM principal (UserId or RoleId). This ID is stored in the cluster manifest, not visible to users, to give the cluster creator admin access to the cluster. Deleting and recreating an AWS IAM principal, even with the same name and Amazon Resource Name (ARN) would change this principal ID, an that new principal would not have the same access as the original cluster creator.
So, deleting the cluster creator AWS IAM principal should only be done when you are absolutely sure that (1) you have an AWS IAM principal with adequate permissions to call all the Amazon EKS API commands you need to manage the cluster, and (2) you have an AWS IAM principal configured in RBAC with the kube-system/aws-auth
configmap, with system:masters
in order to manage Kubernetes RBAC for subsequent users and resources.
In general, the aws-auth
configmap should never be manually edited, and the cluster creator AWS IAM principal should never be deleted.
For now, the eksctl CLI is the best tool to create and manage AWS IAM identity mappings in the aws-auth
configmap.
This containers roadmap item is also marked as coming soon. This new feature we will make it easier to manage access of AWS IAM principals for Amazon EKS clusters.
Please see the documentation for assuming a role.
You may also want to install the AWS IAM Authenticator; however, it is not necessary. You can also use the AWS CLI eks get-token command.
In your ~/.kube/config file, using aws-iam-authenticator
, you would see something like this:
users:
- name: <COMPUTED_USER_ID>
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- token
- -i
- <CLUSTER_NAME>
command: aws-iam-authenticator
env:
- name: AWS_STS_REGIONAL_ENDPOINTS
value: regional
- name: AWS_DEFAULT_REGION
value: <AWS_REGION>
- name: AWS_PROFILE
value: <AWS_ACCOUNT_ID>-<ROLE_NAME>
interactiveMode: IfAvailable
provideClusterInfo: false
Using aws eks get-token
, you would see this as a user:
users:
- name: <COMPUTED_USER_ID>
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
args:
- --region
- <AWS_REGION>
- eks
- get-token
- --cluster-name
- <CLUSTER_NAME>
command: aws
env:
- name: AWS_PROFILE
value: <AWS_ACCOUNT_ID>-<ROLE_NAME>
interactiveMode: IfAvailable
provideClusterInfo: false
As with everything you change about your Amazon EKS cluster AuthN and AuthZ, I would thoroughly test your remaining access before removing any AWS IAM principal access from your cluster.
Relevant content
- Accepted Answerasked a year ago
- asked a year ago
- asked 5 months ago
- Accepted Answerasked a month ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 months ago
@jimmyray thank you for your detailed answer. It is interesting what you are saying about the principal ID changing when recreating an IAM user, I think I have read in other questions / answers that creating a user with the same name as the original cluster creator has given back lost access to the cluster. How exactly can one create an EKS cluster using an IAM role principal rather than an IAM user principal? E.g. running eksctl commands from an EC2 instance which has a role with appropriate permissions attached?
This is actually not correct, there are load of example of users retrieving eks admin access by re-creating the User/Role initially used. Checked with AWS support and the UserId/RoleId is not used to identify the cluster creator only the arn/name is
@nikos64: to create a cluster using a IAM role you simply need to assume the role before running eksctl