How do I provide access to other users and roles after cluster creation in Amazon EKS?

Last updated: 2019-12-09

When I try to access the Amazon Elastic Kubernetes Service (Amazon EKS) cluster through kubectl commands, I get the following authorization error: "error: You must be logged in to the server (Unauthorized)." How can I resolve this error?

Short Description

You get an authorization error when your AWS Identity and Access Management (IAM) entity isn't authorized by the role-based access control (RBAC) configuration of the Amazon EKS cluster. This happens when the Amazon EKS cluster is created by an IAM user or role that's different from the one used by aws-iam-authenticator.

Initially, only the creator of the Amazon EKS cluster has system:masters permissions to configure the cluster. To extend system:masters permissions to other users and roles, you must add the aws-auth ConfigMap to the configuration of the Amazon EKS cluster. The ConfigMap allows other IAM entities, such as users and roles, to access the Amazon EKS cluster.

Resolution

Before completing the following steps, identify the IAM user or IAM role (the cluster creator) that has master access to configure your Amazon EKS cluster. Also, identify the IAM user that the cluster creator will be granting authorization to after cluster creation. To identify the cluster creator, search for the CreateCluster API call in AWS CloudTrail, and then check the userIdentity section of the API call.

Note: In the following steps, the cluster creator is cluster_creator, and the user that doesn't currently have access to the cluster but needs access is designated_user.

Add designated_user to the ConfigMap if cluster_creator is an IAM user

1.    Use SSH to connect to the kubectl instance.

2.    In the AWS Command Line Interface (CLI), run the following command:

aws sts get-caller-identity

The output shows the IAM user details for designated_user.

3.    To list the pods running in the cluster of the default namespace, run the following kubectl command:

kubectl get pods

The output shows the following: “error: You must be logged in to the server (Unauthorized).” This error means that designated_user doesn't have authorization to access the Amazon EKS cluster.

4.    To configure the AWS access key ID and the AWS secret access key of cluster_creator, run the following command:

aws configure

5.    To verify that cluster_creator has access to the cluster, run the following command:

kubectl get pods

You shouldn't get an unauthorized error message. The output should list all the pods running in the default namespace. If the output shows that no resources are found, then no pods are running.

6.    To give designated_user access to the cluster, add the mapUsers section to your aws-auth.yaml file. See the following example aws-auth.yaml file from Managing Users or IAM Roles for your Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

7.    Add designated_user to the mapUsers section of the aws-auth.yaml file in step 6, and then save the file. See the following example:

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: aws-auth 
  namespace: kube-system 
data: 
  mapRoles: | 
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B 
      username: system:node:{{EC2PrivateDNSName}} 
      groups: 
        - system:bootstrappers 
        - system:nodes 
  mapUsers: | 
    - userarn: arn:aws:iam::11122223333:user/designated_user 
      username: designated_user 
      groups: 
        - system:masters

Note: The username in the preceding example is the name that Kubernetes uses to map to the IAM entity passed in userarn.

8.    To apply the new ConfigMap to the RBAC configuration of the cluster, run the following command:

kubectl apply -f aws-auth.yaml

9.    To change the AWS CLI configuration again to use the credentials of designated_user, run the following command:

aws configure

10.    To verify that designated_user has access to the cluster, run the following command:

kubectl get pods

You shouldn't get an unauthorized error message. The output should list all the pods running in the default namespace. If the output shows that no resources are found, then no pods are running.

Add designated_user to the ConfigMap if the cluster_creator is an IAM role

In the preceding steps, you used the credentials of cluster_creator to provide access to designated_user. However, if the cluster was created by an IAM role instead of an IAM user, there will be no credentials that you can use. In such cases, you must assume the IAM role that created the cluster to provide access to designated_user. If the cluster creator is not an IAM role, then you don't need to complete the following steps.

To assume the IAM role and edit the aws-auth ConfigMap on the cluster so that you can provide access to designated_user, complete the following steps:

1.    To show the IAM user details of designated_user, run the following command:

aws sts get-caller-identity

2.    To confirm that designated_user has access to the cluster, run the following command:

kubectl get pods

The output shows the following error: “error: You must be logged in to the server (Unauthorized).” This error means that the designated user doesn't have authorization to configure the Amazon EKS cluster.

3.    To allow designated_user to assume the role of cluster_creator, run the following command:

aws sts assume-role --role-arn arn:aws:iam:11122223333:role/cluster_creator --role-session-name test

The output shows the temporary IAM credentials for designated_user, who is using the assumed role of cluster_creator.

4.    Use the temporary IAM credentials to set the AWS_ACCESS_KEY_ID, AWS_SESSION_TOKEN, and AWS_SECRET_ACCESS_KEY environment variables. See the following example:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SESSION_TOKEN=EXAMPLETOKEN
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

The AWS CLI now prioritizes the credentials set in the environment variables and uses them to make calls to AWS services.

5.    To verify that the AWS CLI is using the assumed role for cluster_creator, run the following command:

aws sts get-caller-identity

6.    To give designated_user access to the cluster, add the mapUsers section to your aws-auth.yaml file. See the following example aws-auth.yaml file from Managing Users or IAM Roles for your Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

7.    In your aws-auth.yaml file, add mapUsers. See the following example:

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: aws-auth 
  namespace: kube-system 
data: 
  mapRoles: | 
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}} 
      groups: 
        - system:bootstrappers 
        - system:nodes 
  mapUsers: | 
    - userarn: arn:aws:iam::11122223333:user/designated_user 
      username: designated_user 
      groups: 
        - system:masters

Note: The username in the preceding example is the name that Kubernetes uses to map to the IAM entity passed in userarn.

8.    Add designated_user to the aws-auth.yaml file, and then save your changes.

9.    To apply the new configuration to the RBAC configuration of the Amazon EKS cluster, run the following command:

kubectl apply -f aws-auth-cm.yml

10.    To unset the following environment variables, run the following commands:

unset AWS_ACCESS_KEY_ID
unset AWS_SESSION_TOKEN
unset AWS_SECRET_ACCESS_KEY

11.    To show the IAM user details of designated_user, run the following command:

aws sts get-caller-identity

12.    To confirm that designated_user has access to the cluster, run the following command:

kubectl get pods

You shouldn't get an unauthorized error message. The output should list all the pods running in the default namespace. If the output shows that no resources are found, then no pods are running.


Did this article help you?

Anything we could improve?


Need more help?