/kind bug
The current validation logic for EKS ControlPlane IAM mappings requires the groups list to be non-empty. This prevents users from implementing a common security pattern where an IAM role is mapped to a specific Kubernetes username with no global groups, allowing for granular, namespace-scoped authorization via separate RoleBindings.
What steps did you take and what happened:
- Define an AWSManagedControlPlane resource.
- Add an entry to iamAuthenticatorConfig.mapRoles with a valid rolearn and username.
- Set groups: [] (an empty list).
- Attempt to apply the manifest.
Example
iamAuthenticatorConfig:
mapRoles:
......
- rolearn: arn:aws:iam::123456789012:role/AWSServiceRoleForAmazonEMRContainers
username: emr-containers
groups: [] # This triggers the validation error
This error is unexpected
Invalid value: v1beta2.RoleMapping{RoleARN:"arn:aws:iam::123456789012:role/AWSServiceRoleForAmazonEMRContainers", KubernetesMapping:v1beta2.KubernetesMapping{UserName:"emr-containers", Groups:[]string{}}}: groups are required
What did you expect to happen:
CAPA should allow empty groups as long as a username is provided. This aligns with standard EKS aws-auth behavior and modern security practices.
Anything else you would like to add:
In controlplane/eks/api/v1beta2/validate.go, the code explicitly checks for the length of the groups slice:
if len(role.Groups) == 0 {
allErrs = append(allErrs, field.Required(fldPath.Index(i).Child("Groups"), "groups are required"))
}While this was likely intended to prevent "useless" mappings, an identity with a username but no groups is a valid and recommended state in Kubernetes for scoped access (e.g., mapping a service-linked role like AWSServiceRoleForAmazonEMRContainers).
/kind bug
The current validation logic for EKS ControlPlane IAM mappings requires the groups list to be non-empty. This prevents users from implementing a common security pattern where an IAM role is mapped to a specific Kubernetes username with no global groups, allowing for granular, namespace-scoped authorization via separate RoleBindings.
What steps did you take and what happened:
Example
This error is unexpected
What did you expect to happen:
CAPA should allow empty groups as long as a username is provided. This aligns with standard EKS aws-auth behavior and modern security practices.
Anything else you would like to add:
In controlplane/eks/api/v1beta2/validate.go, the code explicitly checks for the length of the groups slice:
While this was likely intended to prevent "useless" mappings, an identity with a username but no groups is a valid and recommended state in Kubernetes for scoped access (e.g., mapping a service-linked role like AWSServiceRoleForAmazonEMRContainers).