[EKS] [request]: extend AmazonEKSAdminPolicy to support Gateway API resources

[Lokendra-Reddy]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Tell us about your request

Please extend the Amazon EKS managed access policy:
arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy to include namespace-scoped Kubernetes Gateway API resources in the gateway.networking.k8s.io API group.

At minimum, we request support for:
gateway.networking.k8s.io:

• gateways
• httproutes
• grpcroutes
• tcproutes
• tlsroutes
• referencegrants

Suggested permissions:
get, list, watch, create, update, patch, delete, deletecollection

The policy should remain namespace-scoped when associated through an EKS Access Entry.

Optionally, it would also be helpful to support AWS Load Balancer Controller Gateway API custom resources where they are namespaced, for example:
gateway.k8s.aws:

• loadbalancerconfigurations
• targetgroupconfigurations

Which service(s) is this request for?
Amazon Elastic Kubernetes Service (Amazon EKS)

Specifically:

EKS Access Entries
EKS managed cluster access policies
AmazonEKSAdminPolicy

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We use the Amazon EKS managed Argo CD capability for GitOps application delivery.

We are migrating away from broad cluster-level access:
AmazonEKSClusterAdminPolicy
system:masters

towards a least-privilege model based on EKS Access Entries and namespace-scoped managed access policies.

Our applications use the Kubernetes Gateway API. Helm charts managed by Argo CD create and reconcile namespaced resources such as:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute

For example, Argo CD needs to patch an HTTPRoute in an approved application namespace:

httproutes.gateway.networking.k8s.io "ce-sample-backend-route" is forbidden:
User "arn:aws:sts:::assumed-role/AmazonEKSCapabilityArgoCDRole/"
cannot patch resource "httproutes"
in API group "gateway.networking.k8s.io"
in namespace "sample-backend"

AmazonEKSAdminPolicy already supports many common namespaced workload resources, such as Deployments, StatefulSets, Services, Jobs, ConfigMaps, Secrets, Ingresses, NetworkPolicies, and Role/RoleBinding resources. However, it currently does not cover Gateway API resources.

This creates a gap for teams adopting Gateway API while using EKS managed access policies. Teams must either:

1. Retain or reintroduce overly broad AmazonEKSClusterAdminPolicy;
2. Create and maintain custom Kubernetes RBAC for Gateway API resources;
3. Maintain additional RBAC and EKS Access Entry group mappings for each cluster and application namespace.

The first option is not acceptable for production least-privilege environments. The second and third options add significant operational overhead and reduce the benefit of using AWS-managed EKS access policies.
We would like an AWS-managed, namespace-scoped policy option that supports common application deployment patterns using Gateway API resources without granting cluster-wide administration or CRD management.

Are you currently working around this issue?
We are considering a supplemental custom Kubernetes RBAC configuration:

1. Add a custom Kubernetes group to the Argo CD capability role's EKS Access Entry;
2. Grant only get, list, watch, create, update, patch, and delete for gateway.networking.k8s.io/httproutes;
3. Bind that permission only in explicitly approved application namespaces.

However, this requires custom RBAC resources and ongoing maintenance for every additional Gateway API or vendor-specific custom resource required by applications.
We are also evaluating Argo CD resource exclusions for infrastructure resources that Argo CD does not manage. This does not solve the need to create or patch Gateway API resources that are part of the application manifests.

Additional context
N/A

Attachments
N/A