Mastering AWS EKS Access Entries: A Complete Guide to Secure Cluster Authentication with Terraform

Amazon Elastic Kubernetes Service (EKS) has revolutionized how we manage Kubernetes clusters in the cloud. One of the most critical aspects of EKS management is controlling who can access your cluster and what they can do once they’re in. This is where EKS Access Entries come into play—a powerful feature that provides fine-grained access control to your Kubernetes cluster.

In this comprehensive guide, we’ll dive deep into EKS Access Entries, explore their benefits over traditional authentication methods, and walk through a complete implementation using Terraform.

What Are EKS Access Entries?

EKS Access Entries represent a modern approach to managing authentication and authorization for your EKS cluster. Introduced as part of AWS’s efforts to simplify cluster access management, Access Entries allow you to directly map AWS IAM principals (users, roles, or groups) to Kubernetes permissions without the complexity of managing ConfigMaps or RBAC configurations manually.

Traditional vs. Modern Authentication

Traditional Method (aws-auth ConfigMap):

  • Required manual editing of the aws-auth ConfigMap
  • Error-prone YAML manipulation
  • Difficult to audit and manage at scale
  • Risk of accidentally breaking cluster access

Modern Method (Access Entries):

  • Declarative configuration through APIs
  • Built-in validation and error handling
  • Better integration with AWS IAM
  • Easier to manage through Infrastructure as Code

Key Components of Access Entries

1. Principal ARN

The AWS IAM principal (user, role, or group) that will be granted access to the cluster. This is the “who” in your access control equation.

2. Policy Association

AWS-managed policies that define what actions the principal can perform. These replace the need for manual RBAC configuration.

3. Access Scope

Defines the scope of permissions—either cluster-wide or namespace-specific.

Deep Dive: Understanding the Terraform Configuration

Let’s examine the Access Entries configuration via Terraform code:

access_entries = {
  nasir = {
    principal_arn     = "arn:aws:iam::593793047751:user/nasir"
    policy_associations = {
      admin = {
        policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        access_scope = {
          type = "cluster"
        }
      }
    }
  }
}

Breaking Down the Configuration

Entry Name (nasir): This is a logical identifier for the access entry. Choose descriptive names that reflect the user or role’s purpose.

Principal ARN: Points to the IAM user nasir in account 593793047751. This user will be granted the specified permissions.

Policy Association: Uses the AWS-managed AmazonEKSClusterAdminPolicy, which provides full administrative access to the cluster.

Access Scope: Set to cluster type, meaning the permissions apply to the entire cluster rather than specific namespaces.

AWS-Managed EKS Access Policies

AWS provides several pre-defined policies for common use cases:

Administrative Policies

  • AmazonEKSClusterAdminPolicy: Full cluster administration rights
  • AmazonEKSAdminPolicy: Administrative access with some restrictions

Standard User Policies

  • AmazonEKSEditPolicy: Read/write access to most Kubernetes resources
  • AmazonEKSViewPolicy: Read-only access to cluster resources

Specialized Policies

  • AmazonEKSClusterAdminViewPolicy: Admin-level read access without write permissions

Complete EKS Setup with Access Entries

Here’s a complete Terraform configuration with additional context:

module "eks" {
  source  = "../modules/eks"
  
  cluster_name    = local.name
  cluster_version = "1.32"
  cluster_endpoint_public_access = true
  
  # EKS Addons - Essential cluster components
  cluster_addons = {
    coredns                = {}
    eks-pod-identity-agent = {}
    kube-proxy             = {}
    vpc-cni                = {}
  }
  
  # Network Configuration
  vpc_id     = local.vpc_id
  subnet_ids = [local.subnet-1_id, local.subnet-2_id]
  
  # Node Groups Configuration
  eks_managed_node_groups = {
    nasir = {
      ami_type       = "AL2_x86_64"
      instance_types = ["t3.small"]
      
      min_size = 1
      max_size = 2
      desired_size = 1
    }
  }
  
  # Access Entries - The star of the show
  access_entries = {
    nasir = {
      principal_arn     = "arn:aws:iam::593793047751:user/nasir"
      policy_associations = {
        admin = {
          policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          access_scope = {
            type = "cluster"
          }
        }
      }
    }
  }
}

Advanced Access Entry Patterns

Multiple Users with Different Permissions

access_entries = {
  # Cluster Administrator
  cluster_admin = {
    principal_arn = "arn:aws:iam::593793047751:user/admin"
    policy_associations = {
      admin = {
        policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        access_scope = {
          type = "cluster"
        }
      }
    }
  }
  
  # Developer with Edit Access
  developer = {
    principal_arn = "arn:aws:iam::593793047751:user/developer"
    policy_associations = {
      edit = {
        policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        access_scope = {
          type = "namespace"
          namespaces = ["development", "staging"]
        }
      }
    }
  }
  
  # Read-only User
  auditor = {
    principal_arn = "arn:aws:iam::593793047751:user/auditor"
    policy_associations = {
      view = {
        policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        access_scope = {
          type = "cluster"
        }
      }
    }
  }
}

Role-Based Access for Service Accounts

access_entries = {
  ci_cd_role = {
    principal_arn = "arn:aws:iam::593793047751:role/EKS-CICD-Role"
    policy_associations = {
      deployment = {
        policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        access_scope = {
          type = "namespace"
          namespaces = ["production"]
        }
      }
    }
  }
}

Conclusion

EKS Access Entries represent a significant improvement in managing Kubernetes cluster access. By leveraging AWS-managed policies and native IAM integration, they provide a more secure, scalable, and maintainable approach to cluster authentication.

The Terraform configuration we’ve explored demonstrates how to implement Access Entries effectively, providing a foundation for secure, well-managed EKS clusters. As you scale your Kubernetes operations, Access Entries will prove invaluable in maintaining security while enabling team productivity.

Remember to regularly review and audit your access configurations, follow the principle of least privilege, and leverage the comprehensive monitoring capabilities that AWS provides. With these practices in place, you’ll have a robust, secure foundation for your EKS operations.

You can see sample terraform here : https://github.com/nasir19noor/devops-aws-eks-terraform-actions/blob/main/terraform/services/eks/main.tf

Also published in medium : https://nasir19noor.medium.com/mastering-aws-eks-access-entries-a-complete-guide-to-secure-cluster-authentication-with-terraform-d79c86305ab8

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x