AWS EKS Authentication & Authorisation

Introduction to Authentication and Authorization in EKS

• Authentication: Verifies who the user is. In AWS EKS, this is managed through AWS Identity and Access Management (IAM) or OpenID Connect (OIDC) providers.
• Authorization: Determines what actions the authenticated user can perform within the EKS cluster. This is managed through Kubernetes Role-Based Access Control (RBAC).

AWS EKS Authentication

• Types of Identities in EKS:

  • AWS IAM Principals: Users or roles that are managed through AWS IAM.
  • OIDC Users: Users authenticated through an OIDC provider (not covered in this guide).

• EKS uses IAM to authenticate users who need access to manage clusters or perform operations on Kubernetes objects like pods, deployments, etc.

Deep Dive in Authz & Authn of EKS

• After creating an EKS cluster, the next step is configuring kubectl for cluster access. This section explains the kubeconfig setup and how EKS verifies who is making requests to the Kubernetes API.

• Authentication Example:

  • The AWS CLI generates a kubeconfig file with the necessary details for connecting to the API server.
  • A specific token is generated using aws eks get-token, which allows authentication with the EKS API server.
  • This token is used in HTTP requests (such as with curl) to authenticate and interact with the Kubernetes API.

• Sample EKS Config.

Location: ~/.kube/config

apiVersion: v1
kind: Config
preferences: {}
current-context: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURaRENDQXlDZ0F3SUJBZ0lJYmpKUERuejVVekFKQmdncWhrak9QUVFEQWpCek1TTUdRek0wTURFdwpPREU1TVRVd1dUUXpNalV3TmpReU5UWmpOek1HTm1Rd1l6QTJNVEV5TXprd1pEY3pNVGczTVRBd1dnWURWUVFHCkJCVEpUb2dwNEFNRUlCQ3NHQVRBY0dnMk1UUmdZR0ZNUmlDNFk5ZGdXYmVYTU1CQmZCZ3NxaGtpRzl3MEJBUTAKQUZNUVFmOXBMbjA1WklSTVBpWFRsRnlDZ29vN3Rjb1F3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUlnTUJFRwpRQ3NnS21JRXNEd29wQ1FLS0RFTEJFSXpPUFFrRXhOZ3JqaFZFM3hRb3RMMVRzVW13ZXo5ekJxbWpNRDZKSzdlCmxiT2t1aDBwMGVucm1CUUlGTzN1dTUzM1FZRlZpQm8vM1VaN2dBZ2REWnV2blVTMUtEdnRtS2dVdTNzdmZkcWkKRFR0ckJXRHJvMldRTkVpMEVwdWpXVXg3ek10V1hPN0ZtM1cxSmFRU2VCaDhzYmtuY1AxTkFYUmVnbm1FdlMrZwoxU1ljNlJlVmVPa0JHUm5CQ2pPdVhaYnlHNDZMeUJRTDBDT0dpODZCUnNnb0tJVkRFWGNNTzZXbmhhNGdOcmF6Cm1WZ21TZkZQdEl0SkFBL2h4a2xNb0x5NDRqTXAxK1FFVzdOdW8vRFdBd2dmam9UVk9nR2dxSDZ2RnhCdStFR3gKMWNmN01tb2FkMUNxVVhNSjgvNlAzN3R2RHd4ckJZWEZMR0Ewbk9XTnJmY3NFMmx2M2NFbmdDTE1QOWV1V1RuRQpHRmZnVGp3NU5Mdz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://123456789012.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
    user: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
  name: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
users:
- name: arn:aws:eks:us-west-2:123456789012:cluster/my-eks-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws
      args:
      - eks
      - get-token
      - --region
      - us-west-2
      - --cluster-name
      - my-eks-cluster

• Authorization: aws-auth ConfigMap (Deprecated)

  • Previously, the aws-auth ConfigMap in EKS was used to map IAM roles to Kubernetes roles. However, this method is deprecated and has several limitations, including "shadow administrators" who have invisible privileges.

Challenges of aws-auth ConfigMap (Deprecated):

• It's hard to know who has admin privileges.

• Break-the-glass roles might lack access during incidents.

• Cloud security tools may not track Kubernetes API access effectively.

  • Example: Mapping IAM roles in aws-auth, but realizing hidden admin privileges can't be managed easily.

Under the Hood: aws-iam-authenticator

• The aws-iam-authenticator component handles request authentication in EKS. It works by forwarding authentication tokens to the API server, which then verifies the user’s AWS identity via pre-signed AWS API requests.

• Token Structure Example:

  • The token generated for EKS authentication is a pre-signed request for sts:GetCallerIdentity.
  • Decoding the token reveals that it allows AWS to verify the caller’s identity using this URL.

• Example: Using aws eks get-token to generate a pre-signed token, which is then decoded to show the authentication request to AWS.

Authorization: EKS Cluster Access Management (Recommended)

In November 2023, AWS introduced a better way to manage access to EKS clusters through AWS APIs, eliminating the drawbacks of the aws-auth ConfigMap.

• Recommended Practice:
  • Migrating from aws-auth to the new access management feature is advised for improved security and control.

Steps by step guide to understand EKS authentication

• Step 1: Create or Use an Existing IAM User or Role

  • The first step in setting up authentication is to create an IAM user or use an existing IAM role. Focus on enabling "Programmatic Access" if you only need CLI/API interaction.

• Step 2: Attach Required Permissions to IAM User

  • Attach a policy that gives the user permission to access the cluster. For example, the eks:DescribeCluster permission allows the user to see details about EKS clusters.

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

• Step 3: Configure AWS CLI

aws configure

• Step 4: Update kubeconfig

aws eks update-kubeconfig --name <cluster-name>

AWS EKS Authorization

• Step 1: Understand the aws-auth ConfigMap (deprecated)

kubectl get configmaps aws-auth -n kube-system -o yaml > auth.yaml

• Step 2: Add IAM User to aws-auth ConfigMap

data:
  mapUsers: |
    - userarn: arn:aws:iam::ACCOUNTID:user/eks_user
      username: eks_user

• Step 3: Define Kubernetes RBAC Roles

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-manager
  namespace: default
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create", "delete", "get", "list", "patch", "update"]

• Step 4: Bind the Role to a User (RoleBinding)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-manager-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-manager
subjects:
  - kind: User
    name: eks_user
    apiGroup: rbac.authorization.k8s.io

• Step 5: Test the Permissions

kubectl auth can-i create pods --namespace default

Conclusion

• Authentication happens before Authorization.
• RBAC roles and bindings in Kubernetes control what a user can do within a specific namespace or the entire cluster.

EKS CLuster Access Management

• In EKS, managing who has access to your cluster is crucial for security. Here’s how you can securely manage access: ConfigMap-based Authentication

• Earlier, the aws-auth ConfigMap was used to control access to EKS clusters. However, this approach had limitations:

  • The creator of the cluster had invisible administrative access.
  • Admin roles were not visible through the AWS API.

New EKS Cluster Access Management

• Starting November 2023, AWS introduced EKS Cluster Access Management:

  • Now grant access through AWS APIs instead of relying solely on aws-auth.
  • This method provides better visibility and control over who can access the cluster.

To switch to the new access management system, it’s recommended to migrate from aws-auth ConfigMap to EKS API-based access management.

Key Concepts of EKS Cluster Access Management

• Two important concepts in this new method are:

  • Access Entries: This is where you define which AWS user or role can access the EKS cluster.
  • Access Policies: These are predefined sets of permissions that specify what actions the user or role can perform in the cluster.

• Authentication Modes

  • In EKS, the cluster’s access management can work in three different modes:

    • CONFIG_MAP: Uses only the aws-auth ConfigMap to manage access.
    • API: Uses only access entries created via the AWS API.
    • API_AND_CONFIG_MAP: Uses both methods, but gives preference to access entries from the API.

The default mode for most clusters is API_AND_CONFIG_MAP, which is recommended for better control.

• Step-by-Step: Managing Cluster Access with Access Entries

  • Step 1: Create a Cluster Admin User

    • First, create an IAM user that will act as the cluster admin. Use the following command to generate access keys, refer to example..

      aws iam create-access-key --user-name cluster-admin
      

  • Step 2: Create an Access Entry

    • Now, create an access entry for this IAM user in the cluster, refer to example.

      aws eks create-access-entry --cluster-name demo-cluster \
        --principal-arn arn:aws:iam::123456789012:user/cluster-admin
      

  • Step 3: Associate an Access Policy

    • To grant admin-level access, associate the AmazonEKSClusterAdminPolicy with the access entry, refer to example.

      aws eks associate-access-policy --cluster-name demo-cluster \
        --principal-arn arn:aws:iam::123456789012:user/cluster-admin \
        --policy-arn arn:aws:eks::aws:policy/AmazonEKSClusterAdminPolicy \
        --access-scope type=cluster
      

Conclusion:

• The aws-auth ConfigMap is deprecated but still functional for older clusters.
  • aws-auth ConfigMap is legacy way.
  • API-based access management is the new way Create a dedicated section for new API-based access management with detailed examples.
• aws-iam-authenticator is embedded and doesn't require manual setup in EKS-managed clusters.

Credits:

• securitylabs.datadoghq.com
• ChatGPT [For re-phrasing & re-writing]
• okeyebereblessing.medium.com

⭐⭐⭐⭐⭐