EKS on AWS: how to authenticate and authorize development teams to get access to their specific namespaces

4 min readMay 8, 2020

You have setup your EKS cluster and now want to look at the two main Aspects to provide access to the development teams namely — Authenticate and Authorize which will help dev teams to start using your cluster.

EKS uses AWS IAM for Authentication and Authorization is handled by native kubernetes RBAC.

Lets consider a sample use-case wherein the frontend team require access to the EKS cluster to be able to deploy workloads
the team lead decides that he needs two sets of users
frontend-leads: who could add/edit/delete/list resources {basically namespace admins}
frontend-devs: who can list and monitor their deployed resources, look at logs etc.

Authorization

Lets begin by setting up Authorization for both sets of users which will lay the ground work to build upon so it could be used in tandem with the Authentication process
you would have already created the namespace for the frontend team namely “frontend”

RBAC Roles:

Since we have 2 sets of user we need to define 2 roles; one for the leads and another for the devs specific to their namespace — frontend

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: frontend-leads-role
  namespace: frontend
rules:
- apiGroups: ["","apps","extensions"] # "" indicates the core API group
  resources: ["*"]
  verbs: ["*"]---apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: frontend-devs-role
  namespace: frontend
rules:
- apiGroups: ["","apps","extensions"] # "" indicates the core API group
  resources: ["*"]
  verbs: ["get","watch","list"]

Role Binding:

Next lets bind the roles to specific groups

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-leads-rolebinding
  namespace: frontend #Namespace for this RoleBinding
subjects:
- kind: Group
  name: frontend:leads-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: frontend-leads-role
  apiGroup: rbac.authorization.k8s.io---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: frontend-devs-rolebinding
  namespace: frontend #Namespace for this RoleBinding
subjects:
- kind: Group
  name: frontend:devs-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: frontend-devs-role
  apiGroup: rbac.authorization.k8s.io

Roles in IAM:

Next we create roles in IAM which the respective IAM users can assume, these roles need to have policies attached which have action to describe the cluster -[eks:DescribeCluster]

e.g roles:
 
arn:aws:iam::<account-id>:role/frontend-leads
arn:aws:iam::<account-id>:role/frontend-devs

aws-auth:

Last bit of joining the dots for Authorization is the aws-auth configmap which is the link between the IAM roles and the groups which link to the RBAC role. The configmap sits within the kube-system namespace in EKS { one can use mapUsers as well and use the userarn instead but roles seems more better in terms of best practises}

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::<account-id>:role/frontend-leads
      username: frontend-leads
      groups: 
        - frontend:leads-group
    - rolearn: arn:aws:iam::<account-id>:role/frontend-devs
      username: frontend-devs
      groups: 
        - frontend:devs-group

Authentication

The authentication bit is pretty straightforward as compare to the authorization side and is also well documented in AWS docs

the initial setup required:

the following tools would need to be installed and present on the client machine
1. kubectl: a command line client utility called kubectl for communicating with the cluster API server { installation instructions }
2. aws-iam-authenticator: the above kubectl client makes use of the aws-iam-authenticator to provide authentication to the EKS cluster using the kubectl config file { installation instructions }
3. would already have the aws cli tool configured and setup(accesskey/secretkey) for the IAM user

setting up the kube config:

setting up the kube config for the leads and devs would be as simple as running the below respective commands, running these commands would create entries in the config file located in the root in the file .kube/config

for leads:
aws eks --region $region update-kubeconfig --name $theclustername --alias $thecluster-alias --role-arn arn:aws:iam::<account-id>:role/frontend-leadsfor devs: 
aws eks --region $region update-kubeconfig --name $theclustername --alias $thecluster-alias --role-arn arn:aws:iam::<account-id>:role/frontend-devs

switching namespace and creating a sample pod to test:

creating the pod can be done by the leads and the devs can verify by doing a get on the pod

kubectl config set-context --current --namespace frontend
kubectl run nginx --image nginx --restart Never  (leads)
kubectl get pods (devs/leads)

yoga is 99% practise and 1% theory