---

Challenges in access management in EKS,

As we knew that AWS create EKS cluster with default invisible system:masters admin access that we are not able to remove. Also, to provide access to EKS we need to map identities to Kubernetes group using Cluster ConfigMap aws-auth and that is in kube-system namespace.

New Cluster Access Management Features,

New features allowing us to manage EKS clusters using API calls. With this,

• allow aws identities to aws managed access policies

• allow aws identities to particular Kubernetes group

• able to check who created eks cluster that have default admin access

This new feature introduce few access policy like,

• AmazonEKSClusterAdminPolicy, same as cluster-admin role

• AmazonEKSAdminPolicysame as admin role

• AmazonEKSEditPolicy, same as edit role

• AmazonEKSViewPolicy, same as view role

As per above SS, now we can disable cluster admin access who created cluster and also manager authentication mode using API, ConfigMap and API , only ConfigMap legacy method.

As usual, the affirmation mode is set to CONFIG_MAP while making one more gathering through the EKS Programming connection point or an AWS SDK. For this present circumstance, the control plane simply considers the aws-auth ConfigMap, and you can’t make access segments in the gathering. In case you make an EKS bunch through the AWS console, the approval mode is set to API_AND_CONFIG_MAP obviously.

Exactly when you set the approval mode to API_AND_CONFIG_MAP, assents yielded in both are thought of. Right when an AWS boss is alluded to both in an entry and in the aws-auth ConfigMap, simply assents permitted through the entry segment are considered, and the aws-auth ConfigMap is ignored. For instance, if an entry section surrenders a central read-only induction to the pack and the aws-auth ConfigMap grants it executive access, the ensuing distinctions are scrutinized only ones exclusively.

Finally, the approval mode Programming point of interaction totally ignores the aws-auth ConfigMap and simply considers access segments.

It’s important to note that switching between these modes is only possible in one direction; for example, you can switch from CONFIG_MAP to API_AND_CONFIG_MAP or the Programming interface, but not vice versa.

---

Common Operations

lets assume eks cluster is created,

you can create an access entry for that cluster and principal,

aws eks create-access-entry \
  --cluster-name eks-cluster \
  --principal-arn "arn:aws:iam::xxxxxxx:role/eks-role"

now associate this role with eks policy,

aws eks associate-access-policy \
  --cluster-name eks-cluster \
  --principal-arn "arn:aws:iam::xxxxxxx:role/eks-role" \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy \
  --access-scope '{"type": "cluster"}

---

With GUI, Go to EKS console and click on access tab,

Create access entry,

Next page,

Create it. and verify access tab

You are now successfully able to connect cluster.

---

Custom Permissions,

In such case when more particular permissions required, we can map to Kubernetes groups. We can create custom cluster role like below,

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["list", "get", "watch"]

next,

kubectl create clusterrolebinding pod-viewer --clusterrole=pod-viewer \
  --group=pod-viewers

Now create access entry,

aws eks create-access-entry \
  --cluster-name eks-cluster \
  --principal-arn "arn:aws:iam::xxxxxxx:role/pod-viewer" \
  --kubernetes-group pod-viewers

---

Conclusion

Enhanced access control through EKS cluster management policies presents a significant advancement in Kubernetes security and operational efficiency within AWS environments. By mastering the implementation of these policies and understanding their impact on common operations, organizations can fortify their EKS clusters with precise, fine-grained access control, mitigating potential security risks and ensuring smoother, more controlled cluster management.