Authentication & Authorization in AWS EKS for Multiple Env in Single Cluster

To handle authentication and authorization for different environments (e.g., dev, staging, prod) within a single AWS EKS cluster, you can use AWS IAM for authentication and Kubernetes RBAC for fine-grained authorization. Here’s a detailed step-by-step guide on how to set this up:

Step 1: Define the Environment Requirements

Before you start, clarify the access requirements for each environment within the single EKS cluster. For example:

Dev Environment: Developers may need full access.
Staging Environment: Testers may need read and write access, but not administrative permissions.
Prod Environment: Only limited personnel should have access, primarily with read permissions or limited write permissions for specific actions.

Step 2: Configure AWS IAM for Authentication

AWS EKS uses IAM to authenticate users but not to authorize them directly. Instead, IAM users and roles are mapped to Kubernetes users and groups within the cluster.

1) Create IAM Roles for Each Environment:

• Create specific IAM roles for each environment (e.g., EKS-Dev-Role, EKS-Staging-Role, EKS-Prod-Role).
• Attach necessary IAM policies to allow access to the EKS cluster. For example, the following IAM policy provides access to retrieve a token for authenticating with the EKS API server:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster"
      ],
      "Resource": "arn:aws:eks:region:account-id:cluster/your-cluster-name"
    }
  ]
}

2) Map IAM Roles to Kubernetes Users or Groups in aws-auth ConfigMap:

• Once the IAM roles are created, you need to map them to Kubernetes users/groups by editing the aws-auth ConfigMap in the kube-system namespace.

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/EKS-Dev-Role
      username: dev-user
      groups:
        - dev-group
    - rolearn: arn:aws:iam::111122223333:role/EKS-Staging-Role
      username: staging-user
      groups:
        - staging-group
    - rolearn: arn:aws:iam::111122223333:role/EKS-Prod-Role
      username: prod-user
      groups:
        - prod-group

Here, the IAM roles are mapped to Kubernetes groups (dev-group, staging-group, prod-group) for authorization purposes. Users assuming these roles will authenticate as the corresponding Kubernetes user.

Step 3: Configure Kubernetes RBAC for Authorization
Once IAM is used to authenticate users, Kubernetes RBAC takes over to manage what users or groups can do within specific namespaces representing different environments.
1) Create Namespaces for Each Environment:

• Create separate namespaces in the EKS cluster for each environment.

kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace prod

2) Define Roles and RoleBindings for Each Environment:

• Create specific Kubernetes Roles for each namespace to define what actions are permitted in that environment. For example, the dev-group might have full access to the dev namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: dev-full-access
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps", "secrets"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]

Similarly, create roles for staging and prod with the appropriate permissions for each.

3) Bind Roles to Groups Using RoleBindings:

• Use RoleBindings to assign the created roles to groups for each environment. For example, grant dev-group full access to the dev namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-group-access
  namespace: dev
subjects:
  - kind: Group
    name: dev-group
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-full-access
  apiGroup: rbac.authorization.k8s.io

Repeat similar RoleBinding configurations for staging and prod, linking them to staging-group and prod-group with their respective roles.

Step 4: Test the Access Control

1) Assume IAM Roles and Authenticate:

• Use AWS CLI or an identity provider to assume the role for a specific environment (e.g., EKS-Dev-Role for the dev environment).
• Run the aws eks get-token command to retrieve the authentication token for kubectl.

aws eks get-token --cluster-name your-cluster-name --role-arn arn:aws:iam::111122223333:role/EKS-Dev-Role

2) Verify Access Permissions in Kubernetes:

• Switch context to the respective namespace and attempt actions based on the assigned role to ensure users can only perform authorized actions.

kubectl config set-context --current --namespace=dev
kubectl get pods # Should succeed for dev users with list permissions
kubectl delete pod <pod-name> # Should only succeed if allowed by RBAC

This step will confirm that the RBAC permissions align with the IAM roles and the specific environment constraints.

Step 5: Implement Logging and Monitoring for Security

Audit Logs: Enable Kubernetes audit logs to monitor access and actions within each namespace.
CloudTrail: Use AWS CloudTrail to track IAM role assumptions and API access for better visibility and auditing of authentication events.
GuardDuty and AWS Config: Enable GuardDuty for threat detection and AWS Config to monitor IAM configuration compliance.

Summary

This approach allows you to handle authentication with AWS IAM and authorization within the Kubernetes cluster using RBAC:

1) IAM Roles authenticate users and are mapped to environment-specific groups in the aws-auth ConfigMap.
2) Kubernetes RBAC then defines permissions per namespace, granting access only as needed per environment.

By combining these practices, you can securely manage multi-environment access within a single EKS cluster, providing clear separation and control over each environment's resources.