- Newest
- Most votes
- Most comments
Deleting or altering Kubernetes default clusterRoles like cluster-admin or admin can significantly affect how access is managed within your EKS cluster, but it won't directly impact the AWS IAM policies. Here's a detailed breakdown of how EKS access policies work in conjunction with Kubernetes RBAC:
Kubernetes RBAC and EKS IAM
Kubernetes RBAC (Role-Based Access Control):
RBAC in Kubernetes defines what actions users can perform within the cluster. It uses Role and ClusterRole objects to define permissions and RoleBinding and ClusterRoleBinding objects to grant those permissions to users or groups. ClusterRole: A set of permissions that can be applied across the entire cluster. Role: A set of permissions that apply within a specific namespace.
EKS IAM (AWS Identity and Access Management):
IAM in AWS is used to manage access to AWS resources, including the EKS cluster itself. EKS IAM Roles and Policies: These define who can create, manage, and delete EKS clusters and related resources. EKS uses IAM for authentication (identifying who you are) and Kubernetes RBAC for authorization (what you can do). Interaction Between IAM and RBAC
Authentication:
IAM roles and users are mapped to Kubernetes RBAC through the aws-auth ConfigMap in the kube-system namespace. This mapping allows IAM entities to authenticate to the EKS cluster.
Authorization:
Once authenticated, the permissions of the IAM entities are governed by Kubernetes RBAC. For example, an IAM user or role might be mapped to the cluster-admin role in Kubernetes. Impact of Modifying or Deleting Default ClusterRoles
Deleting or altering cluster-admin or admin roles:
If you delete or modify the cluster-admin or admin roles, any bindings to these roles will be affected. For instance, if an IAM role is mapped to the cluster-admin role via a ClusterRoleBinding, deleting the cluster-admin role will revoke the permissions granted by that role. Independent of IAM Policies:
The Kubernetes RBAC permissions (like cluster-admin) are independent of IAM policies. IAM policies control access to AWS resources, while RBAC controls access within the Kubernetes cluster.
Example Scenario:
If an IAM role is granted access to the EKS cluster and mapped to the cluster-admin role, deleting the cluster-admin role will remove the administrative access for that IAM role within the cluster. The IAM role will still exist and have permissions to interact with AWS resources, but it won't have the same permissions within the Kubernetes cluster unless re-mapped to another role.
Best Practices
Avoid deleting default roles unless you have a clear understanding of the implications and have a replacement strategy. Create custom roles if you need to modify permissions and map users or groups to these custom roles instead of modifying the default ones. Regular audits of RBAC permissions can help ensure that only necessary permissions are granted and maintained.
Relevant content
- asked 10 months ago
- asked 5 months ago
- asked a year ago
- AWS OFFICIALUpdated 5 days ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a year ago
Hi, I believe this answer is missing adding users via EKS API on the EKS console, those IAM access entries dont necessarily need to belong to an existing RBAC group, they are assigned their own AWS policy which I assume has nothing to do with cluster RBAC any more?