aws / aws/containers-roadmap

[EKS] [request]: Argo CD capability — allow read-only (VIEWER) users to see cluster names for clusters registered as shared destinations

Open
#2,873 0 comments 4 reactions 0 assignees View on GitHub
EKS EKS Capabilities 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](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) 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**

The EKS managed Argo CD capability provides three built-in RBAC roles (ADMIN, EDITOR, VIEWER) that are mapped to IAM Identity Center users and groups. VIEWER users cannot list clusters, and the only supported way to grant cluster-name visibility is the project-role pattern documented at https://docs.aws.amazon.com/eks/latest/userguide/argocd-permissions.html:

p, proj::viewer, clusters, get, *, allow

This pattern only takes effect for cluster secrets that carry a project field. In Argo CD, a cluster's RBAC object is built as / only when the secret is project-scoped; without a project field the object is just the cluster server/ARN, so a project-role clusters, get grant is never evaluated against it. As a result, VIEWER users get no cluster-name visibility for clusters registered the standard shared way (no project field, used by multiple AppProjects).

We would like a supported way to grant a read-only role cluster-name visibility for these shared clusters — for example, adding clusters, get to the built-in VIEWER role, or exposing a supported RBAC override on the managed capability.

**Which service(s) is this request for?**

EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

We run a hub-and-spoke topology where each remote cluster is a destination for several AppProjects, so the cluster secrets are registered globally (no project field). Our read-only users are mapped to VIEWER. Applications are visible to them, but Settings > Clusters is empty and every Application tile shows "Destination Unknown," because the project-role clusters, get grant does not resolve for global cluster secrets.

A cluster secret can name only one project, so scoping it to a single project would only help that one project's viewers and is not viable for a /shared cluster. This leaves no supported way to give our read-only users cluster-name visibility
today.

**Are you currently working around this issue?**

Partially. Setting spec.destination.server: on Applications makes the UI display the ARN instead of "Unknown," but this is cosmetic only — it shows the ARN rather than the friendly cluster name, and Settings > Clusters remains empty for VIEWER users. A custom argocd-rbac-cm ConfigMap is not honored by the managed capability, so there is no configuration-level workaround. ADMIN sees everything, but ADMIN is a full read/write role and is not appropriate for read-only users.

We have also considered:

- Scoping each cluster secret to a single project — not viable, clusters serve multiple projects
- Using ADMIN for read-only users — over-privileged, violates least privilege
- Self-managed Argo CD with a custom RBAC ConfigMap — loses the managed experience

Contributor guide

Open the contributing guide

Research direction

Start with the EKS managed Argo CD permissions documentation linked in the issue and the described VIEWER, shared-destination, and project-role behavior. Done means read-only VIEWER users can see friendly names for globally registered clusters in Settings > Clusters and Application tiles without gaining write access.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.