AWS: EKS : error: You must be logged in to the server (Unauthorized) 

This error occurs when you try to access from a user other than the who created the EKS Cluster.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.

Solution: 

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:

[root@ip- ~]# aws sts get-caller-identity
{
    "UserId": "AIDA6JXXXXXXXXX",
    "Account": "9828XXXXXX",
    "Arn": "arn:aws:iam::9828XXXXXX:user/xxxx@cnxxxxxx"
}
[root@ip- ~]#

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.