HOW TO CONFIGURE AND MANAGE AUTHENTICATION AND AUTHORIZATION IN AWS ELASTIC KUBERNETES SERVICE.

Two types of identities can access the Amazon EKS cluster:

- AWS Identity and Access Management (IAM) principal (role or user).

- A user in your own OpenID Connect (OIDC) provider.

However, this article will focus on using the AWS IAM principal.

Image Source

Before we get to the heart of this article, let’s clarify the difference between the two main terms: Authentication and Authorization.

1. Authentication: Authentication is the process of verifying the identity of an individual or entity to ensure they are who they claim to be.
2. Authorization: Authorization ensures that only authorized (with access rights to resources) individuals or entities can access specific resources or perform certain actions.

Let’s consider a scenario involving a company’s internal document management system. Employees must access the company’s document management system to view, edit, and upload documents. To do so, they must authenticate themselves by logging in with their username and password. Upon entering the correct credentials, the system verifies their identity and grants them access to the document management system (Authentication). Once authenticated, all employees have varying levels of access based on their roles and responsibilities within the company. The authorization ensures that employees can only access the documents and perform actions relevant to their job roles, maintaining security and confidentiality within the document management system. If an employee attempts to access a document or perform an action outside their authorization scope, the system will deny them access (Authorization).

NOTE: Authentication is the primary security measure that takes place before authorization.

PREREQUISITES

1. EKS Cluster. Refer to my previous article.
2. AWS CLI Installed.

AWS EKS AUTHENTICATION

An AWS Identity and Access Management principal, whether a role or a user, requires authentication through AWS Identity and Access Management (IAM). This means users need to authenticate on AWS EKS using their IAM credentials. They can sign in directly as an IAM user or through a federated identity provider if your administrator has set up a federation using IAM roles. When users use this type of identity

1. You can authenticate these users and grant them permission to work with Kubernetes objects on your cluster. This means they can interact with and manage resources like pods, deployments, and services in your Kubernetes environment.
2. You can also permit IAM users access to manage your Amazon EKS cluster and its resources. This includes using the Amazon EKS API, AWS CLI, AWS CloudFormation, AWS Management Console, or Excel to perform tasks like creating or deleting clusters, scaling node groups, or updating configurations.

Keynote: In AWS, all authentication-related operations are managed through Identity & Access Management (IAM), and EKS is no different. EKS utilizes IAM for authentication, which requires that the user or bot’s identity exists within IAM to communicate with Kubernetes’ control plane.

The first step involves setting up a new user or granting access to an existing IAM user in AWS EKS, focusing solely on enabling “Programmatic access.” Access to the console is only necessary if there are specific environment requirements.

The second step is to attach a policy granting the user eks:DescribeCluster permission. It’s up to you whether you want to limit access to a particular cluster or allow access to all clusters. We will assign this user access to all clusters for demonstration purposes.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DescribeAllEksClusters",
            "Effect": "Allow",
            "Action": "eks:DescribeCluster",
            "Resource": "*"
        }
    ]
}

The next step is to configure AWS CLI. Go to the user’s IAM page, and in the “Security credentials” tab, generate an access key and secret key pair.

# Run on your terminal (already installed aws cli)
aws configure
# To configure the identity
aws sts get-caller-identity

The Next step is to retrieve the credentials for the kubeconfig configuration. This retrieves the credentials required to communicate with the AWS EKS API server.

aws eks update-kubeconfig --name $NAMEOFCLUSTER

N.B Not having the required permission attached (eks:DescribeCluster) to the user will result in an access-denied response, as seen below.

Before and after applying the eks:DescribeCluster policy.

The final step is utilizing the aws-auth configmap, which is responsible for mapping IAM identities to Kubernetes users. The newly created user is currently recognized solely as an identity within AWS IAM, allowing it to interact with AWS resources within the account; however, for this user to communicate with Kubernetes, the aws-auth configmap needs to be modified.

This streamlines the authentication between AWS IAM and the Kubernetes cluster. The aws-auth configmap resides in the kube-system namespace. It contains details regarding which IAM identities, such as roles, users, or groups, are authorized to communicate with the API server.

# To view the content of the aws-auth configmap
# output to a file called auth.yaml
$ kubectl get configmaps aws-auth -n kube-system -o yaml > auth.yaml

# view the content of the file
$ cat auth.yaml

# output
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::ACCOUNTID:role/eks-node-group
      username: system:node:{{EC2PrivateDNSName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2024-03-16T23:26:44Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "1392"
  uid: b6a62a67-6d42-4ebd-bfa9-d5fbcf0c669c

# edit the auth.yaml file to map the IAM user

$ vim auth.yaml
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::ACCOUNTID:role/eks-node-group
      username: system:node:{{EC2PrivateDNSName}}

## add this block
   mapUsers: |
    - userarn: arn:aws:iam::ACCOUNT_NUMBER:user/eks_user
      username: eks_user
kind: ConfigMap
metadata:
  creationTimestamp: "2024-03-16T23:26:44Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "1392"
  uid: b6a62a67-6d42-4ebd-bfa9-d5fbcf0c669c

# APPLY 
$ kubectl apply -f auth.yaml

# If the required IAM identity mapping hasn't been added to `aws-auth` ConfigMap
$ kubectl get pods
E0317 00:28:01.934092     170 memcache.go:265] couldn't get current server API group list: the server has asked for the client to provide credentials
error: You must be logged in to the server (the server has asked for the client to provide credentials)


# After the identity mapping has been added
$ kubectl get pods
Error from server (Forbidden): pods is forbidden: User "eks_user" cannot list resource "pods" in API group "" in the namespace "default"
# This is where authorization comes into play

AWS EKS AUTHORIZATION

Authorization occurs internally within the EKS cluster using Role-Based Access Control (RBAC). This is a widely accepted standard within the Kubernetes community.

AWS EKS leverages Kubernetes RBAC to manage authorization. RBAC allows you to define roles, role bindings, cluster and cluster role bindings to grant permissions to users or groups. Roles define a set of permissions, specifying what actions (verbs) are allowed on which resources (nouns) within a specific namespace and cluster defines across the entire cluster. We will create a role and role binding for the default namespace for demonstration.

# Defining the role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test
  namespace: default
rules:
  - apiGroups:
      - ""
    resources:
      - pods
      - secrets
      - configmaps
      - services
      - serviceaccounts
    verbs:
      - create
      - delete
      - get
      - list
      - patch
      - update
# Defining the rolebinding
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: test
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: eks_user

This above YAML manifest file defines a Role named “test” and a corresponding Role Binding within the default namespace of a Kubernetes cluster. The Role grants create, delete, get, list, patch, and update permissions on pods, secrets, configmaps, services, and service accounts. The RoleBinding binds this Role to a User named “eks_user” that was earlier created within the default namespace, providing them with the specified permissions.

Test output below- Allow and deny permissions have been assigned to the user based on the defined role.

CONCLUSION

The choice between using IAM users or IAM groups to grant access to AWS EKS depends on your organization’s specific requirements and policies. For demonstration I used AWS user using the model of individual identities.

Though it’s recommended to use IAM group as managing permissions through IAM groups simplifies administration and ensures consistency across multiple users or applications and IAM groups are collections of IAM users. You can assign permissions to IAM groups, and all users within the group inherit those permissions.