AWS EKS – Part 20 – Authentication and Authorization with Access Entries

Access Entries is a new Authentication and Authorization method in EKS service introduced in late 2023 by AWS to allow customers to manage their Kubernetes authentication and authorization through AWS APIs. As mentioned in the previous articles, if you want to enable IAM principals to access EKS clusters, you must edit the aws-auth ConfigMap within the cluster. Although this method works fine, it’s hard to manage in enterprise environments and at scale, and it’s not easy to handle with Infrastructure as Code(IaC) tools. So, the Access Entries solution is the successor of the old method, and it allows us to manage the cluster accesses from outside Kubernetes in the same way as we create and manage the cluster itself. The other important feature that Access Entries introduced is changing the cluster owner or removing the owner from the cluster. It also provides predefined policies to manage user permissions.

Follow our social media:

https://www.linkedin.com/in/ssbostan

https://www.linkedin.com/company/kubedemy

https://www.youtube.com/@kubedemy

https://telegram.me/kubedemy

Register for the FREE EKS Tutorial:

If you want to access the course materials, register from the following link:

Register for the FREE AWS EKS Black Belt Course

Why do we need EKS Access Entries?

• It allows changing the cluster owner, which was not supported by the old method. In the old one, there was a chance you would lose cluster access if you deleted the cluster owner. You can also add IAM principals by other users than the owner now.
• It allows adding IAM principals to access the cluster through APIs, which means you can easily manage accesses with IaC tools like OpenTofu, Terraform, Pulumi, Ansible, CloudFormation, etc. In the old method, you had to edit aws-auth ConfigMap, which is really hard to manage. Now, you can manage everything in the same way as creating, managing, or deleting the cluster through APIs.
• It provides various predefined access policies that can be assigned to IAM principals outside the cluster through EKS APIs so that the user can access the cluster resources without defining RBAC resources inside the Kubernetes cluster.

EKS Access Entries setup procedure:

• Create or update the cluster to support Access Entries.
• Add, update or delete Access Entries for the EKS cluster.
• Add, update or delete Access Policies to the IAM principal.
• Setup a real-world example of Access Entries and Access Policies.
• Setup kubectl config and access the cluster.
• Investigate permissions from inside/outside of the cluster.

Step 1 – Enable EKS Access Entries:

To enable Access Entries on the new or existing clusters, use the latest version of AWS CLI, which comes with --access-config option in the EKS create/update command. To enable Access Entries on an existing cluster, check the EKS platform version compatible with the Access Entries feature on the EKS documentation page.

AWS EKS – Part 1 – Deploy EKS cluster requirements

AWS EKS – Part 2 – Deploy managed cluster control plane

Create a new cluster with Access Entries enabled:

aws eks create-cluster \
  --name kubedemy \
  --role-arn arn:aws:iam::231144931069:role/Kubedemy_EKS_Cluster_Role \
  --resources-vpc-config subnetIds=subnet-0ff015478090c2174,subnet-01b107cea804fdff1,subnet-09b7d720aca170608,endpointPublicAccess=true,publicAccessCidrs=0.0.0.0/0 \
  --kubernetes-network-config serviceIpv4Cidr=172.20.0.0/16,ipFamily=ipv4 \
  --access-config bootstrapClusterCreatorAdminPermissions=true,authenticationMode=API \
  --kubernetes-version 1.28 \
  --tags owner=kubedemy

Note: You can disable cluster owner permissions when you create a cluster.

Enable Access Entries on an existing cluster:

aws eks update-cluster-config \
  --name kubedemy \
  --access-config authenticationMode=API_AND_CONFIG_MAP

Note: Once enabled on an existing cluster, the owner will be shown in the list.

Supported Authentication modes:

Important: Once the Access Entries feature gets enabled, it cannot be disabled.

By enabling Access Entires, you should see entries in the dashboard.

Step 2 – Manage EKS Access Entries:

You can add any IAM principals, IAM users, IAM roles, etc., as you want. Read the following articles to learn how to create IAM principals and assign the required permissions.

AWS EKS – Part 18 – Kubernetes Authentication with AWS IAM Users

AWS EKS – Part 19 – Kubernetes Authentication with AWS IAM Roles

Important rules:

• You can use path-based ARNs for access entries.
• You cannot create multiple access entries for the same principal.
• After creating the access entry, you cannot update its principal.
• ARN can be in other AWS accounts for STANDARD access entries.
• Access Entry type cannot be changed once created.

Access Entry types:

To list and describe access entries:

aws eks list-access-entries \
  --cluster-name kubedemy

aws eks describe-access-entry \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy

To add a new access entry, run the following command:

If you set a username and groups for the access entry, it will be reflected in Kubernetes to be used by the Kubernetes RBAC system. It’s better to avoid setting the username and let AWS set it using its default patterns. Here is the list of default patterns:

aws eks create-access-entry \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy \
  --kubernetes-groups "admins" \
  --username kubedemy \
  --type STANDARD \
  --tags owner=kubedemy

Important: If you set a username or group, they cannot be started with system: iam: amazon: aws: eks: These prefixes are reserved for internal and AWS uses. You can also update the Username and Groups after creating the access entry.

Important: As mentioned in the previous post, granting access through IAM Roles is better than IAM Users. This best practice is still valid for Access Entries, and it’s better to create an access entry for IAM roles and allow users to assume them.

Important: If you delete the ARN, “IAM user, IAM role, etc.”, and you create it again with the same name, although the ARN is the same, the principal cannot access the cluster because the UserID, RoleID, and the principal ID is changed and EKS count that.

To update the access entry, run the following command:

aws eks update-access-entry \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy \
  --kubernetes-groups "admins" "superadmins" \
  --username kubedemy

Note: You can only update the Username and Groups.

To delete an existing access entry:

aws eks delete-access-entry \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy

Step 3 – Manage EKS Access Policies:

Once you create an access entry, you can assign one or more access policies. AWS provides a couple of predefined access policies with various permissions. Currently, you cannot create custom policies, but the good news is you can use Kubernetes RBAC individually or mix both Access Policies and Kubernetes RBAC simultaneously.

Important rules:

• Access policies can only be assigned to STANDARD access entries.
• Access policies can be assigned cluster-wide or per namespace.
• If multiple access policies are assigned, the IAM principal has all the permissions included in all access policies. If some permissions are assigned through the Kubernetes RBAC to the IAM principal username or groups, “in addition to access policies”, the IAM principal will have all the permissions included in all access policies and Kubernetes roles at the same time. It doesn’t make sense, but it’s true.
• Access policies are managed outside Kubernetes, so you cannot find user permissions within the cluster through the native Kubernetes RBAC system.

To list all predefined access policies:

aws eks list-access-policies

{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

Currently, EKS provides four access policies.

You can find their permissions on the documentation page.

To list assigned policies to the access entry:

aws eks list-associated-access-policies \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy

To associate a new policy, run the following command:

# Cluster-wide policy.
aws eks associate-access-policy \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=cluster

# Namespaced policy.
aws eks associate-access-policy \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy \
  --access-scope type=namespace,namespaces=test,myapp

To disassociate a policy, run the following command:

aws eks disassociate-access-policy \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:user/kubedemy \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Step 4 – Create a real-world example:

We must update our cluster to support Access Entries. It’s better to update the cluster Authentication mode to API_AND_CONFIG_MAP first, migrate the configuration from aws-auth ConfigMap to Access Entries and then disable aws-auth by updating the Authentication mode to API only. Do not touch any Roles in aws-auth added by AWS for managed worker nodes. Only migrate users and roles you added.

aws eks update-cluster-config \
  --name kubedemy \
  --access-config authenticationMode=API_AND_CONFIG_MAP

# Migrate from aws-auth to Access Entries.

aws eks update-cluster-config \
  --name kubedemy \
  --access-config authenticationMode=API

In this example, we want to create an access entry for the KubernetesAdmin role, which can be assumed by the kubedemy IAM user. To do so, let’s create these principals and allow the role to describe the cluster. To learn more, follow the previous articles.

AWS EKS – Part 18 – Kubernetes Authentication with AWS IAM Users

AWS EKS – Part 19 – Kubernetes Authentication with AWS IAM Roles

aws iam create-user \
  --user-name kubedemy \
  --tags Key=owner,Value=kubedemy

cat <<EOF > kubernetes-admin-trust-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::231144931069:user/kubedemy"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF

aws iam create-role \
  --role-name KubernetesAdmin \
  --assume-role-policy-document file://kubernetes-admin-trust-policy.json \
  --tags Key=owner,Value=kubedemy

cat <<EOF > describe-kubedemy-cluster.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Resource": "arn:aws:eks:eu-west-2:231144931069:cluster/kubedemy",
            "Action": "eks:DescribeCluster"
        }
    ]
}
EOF

aws iam put-role-policy \
  --role-name KubernetesAdmin \
  --policy-name Describe_Kubedemy_Cluster \
  --policy-document file://describe-kubedemy-cluster.json

Now, we must create an access entry for the IAM role and assign access policies.

aws eks create-access-entry \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:role/KubernetesAdmin \
  --type STANDARD \
  --tags owner=kubedemy

aws eks associate-access-policy \
  --cluster-name kubedemy \
  --principal-arn arn:aws:iam::231144931069:role/KubernetesAdmin \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Ultimately, create an Access Key to setup the AWS CLI command.

aws iam create-access-key \
  --user-name kubedemy

Step 5 – Generate kubeconfig and access the cluster:

Configure the AWS CLI and create a new profile to assume the KubernetesAdmin role.

aws configure

# Use Access key and Secret key from the previous step.

cat <<EOF >> ~/.aws/config
[profile KubernetesAdmin]
role_arn = arn:aws:iam::231144931069:role/KubernetesAdmin
source_profile = default
region = eu-west-2
output = json
EOF

To generate the kubeconfig file, run this command:

aws --profile KubernetesAdmin eks update-kubeconfig --name kubedemy

To check your access:

kubectl auth whoami

Step 6 – Investigate EKS Access Policies:

It’s exciting to know that Kubernetes has no clue about the access policy permissions. As you can see in the above picture, our principal has no high-privilege groups assigned, and no ClusterRoleBinding/RoleBinding is assigned to the user. Still, somehow, you can access the cluster; It’s the EKS magic. Even if you check your access list, it doesn’t show anything other than all the permissions that system:authenticated has, but if you check each privilege individually, you can see you can do that using access policies.

To check privileges individually:

kubectl auth can-i VERB [TYPE | TYPE/NAME]

Conclusion:

Access Entries is a cool feature introduced recently in AWS EKS, and it helps us to manage authentication without editing aws-auth ConfigMap. Furthermore, it provides access policies to manage permissions as well, but I prefer to use Kubernetes RBAC instead to gain more visibility over permissions from within the cluster.

If you like this series of articles, please share them and write your thoughts as comments here. Your feedback encourages me to complete this massively planned program. Just share them and provide feedback. I’ll make you an AWS EKS black belt.

Follow my LinkedIn https://www.linkedin.com/in/ssbostan

Follow Kubedemy LinkedIn https://www.linkedin.com/company/kubedemy

Follow Kubedemy Telegram https://telegram.me/kubedemy