aws / aws/containers-roadmap

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

Open
#2,863 0 comments 4 reactions 0 assignees View on GitHub
EKS EKS Networking Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### 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

Contributor guide

Open the contributing guide

Research direction

No repository file, test, or implementation entry point is identified; this is a request for AWS EKS managed policy behavior. Start by reviewing the requested Gateway API resources, permissions, and namespace-scoping requirements, then confirm whether AWS has an implementation path. Done means AmazonEKSAdminPolicy supports the listed namespaced resources without cluster-wide administration.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
authorization, cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.