"argocd proj list" returns an empty list when user lacks permissions on projects

[aminerachyd]

Checklist:

• [x] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• [x] I've included steps to reproduce the bug.
• [x] I've pasted the output of argocd version.

Describe the bug

The CLI returns a silent error, an empty list, when listing projects with a user which lacks permissions to do. Without required rights, when getting a project we encounter this error:

$ argocd --auth-token $ARGOCD_TOKEN --grpc-web --server $ARGOCD_INSTANCE proj get default
FATA[0000] rpc error: code = PermissionDenied desc = permission denied

While when querying a list of projects, we get this silent error output:

$ argocd --auth-token $ARGOCD_TOKEN --grpc-web --server $ARGOCD_INSTANCE proj list
NAME  DESCRIPTION  DESTINATIONS  SOURCES  CLUSTER-RESOURCE-WHITELIST  NAMESPACE-RESOURCE-BLACKLIST  SIGNATURE-KEYS  ORPHANED-RESOURCES  DESTINATION-SERVICE-ACCOUNTS

To Reproduce

A user lacking permissions on listing project resources.

Expected behavior

Return a permission error, like:

FATA[0000] rpc error: code = PermissionDenied desc = permission denied: projects, list

Version

argocd: v2.13.3+a25c8a0
  BuildDate: 2025-01-03T19:06:52Z
  GitCommit: a25c8a0eef7830be0c2c9074c92dbea8ff23a962
  GitTreeState: clean
  GoVersion: go1.22.10
  Compiler: gc
  Platform: linux/amd64
argocd-server: v3.0.6+db93798

[ppapapetrou76]

@aminerachyd thanks for raising this issue but I don't think there's anything wrong with the current implementation. The way proj list command works is based on which projects the current user is allowed to access ( get ) With that said if you have multiple projects and the user is only allowed to access ( get ) only one of them then the list will return back the allowed project

I added locally a new project called project-1 and I gave allow permissions to a user. The same user has no permissions to get the default project.

Running the argocd proj list command I get this output

NAME       DESCRIPTION  DESTINATIONS  SOURCES  CLUSTER-RESOURCE-WHITELIST  NAMESPACE-RESOURCE-BLACKLIST  SIGNATURE-KEYS  ORPHANED-RESOURCES  DESTINATION-SERVICE-ACCOUNTS
project-1               <none>        <none>   <none>                      <none>                        <none>          disabled            <none>

which is expected

There's no list action in the current RBAC scheme so if a list command returns an empty list it means that the user has access to nothing.

@blakepettersson I think you have contributed most to the RBAC component so please correct me if I'm wrong

[Mangaal]

I agree with the current behavior and with what @ppapapetrou76 explained.

When a user explicitly tries to get a project (e.g., argocd proj get default) and they lack permission, Argo CD correctly returns a PermissionDenied error — this is expected because the user is performing a direct GET operation.

However, argocd proj list does not perform a single “list” action (there is no list verb in the RBAC model). Instead, Argo CD iterates over all projects and returns only those for which the user has get permission.

[aminerachyd]

Thank you for the input. So gathering what was cited here, and the comments in the PR I opened https://github.com/argoproj/argo-cd/pull/25297, the right way to move forward would be to have a "list" action added on Argo CD RBAC model.

And this would perhaps follow the way the "list" action is working on Kubernetes ?

• First check if a user is authorized to list a certain resource.
• Second, filter the instances of the resource and only return those for which the user has the right to see.

[ppapapetrou76]

Thank you for the input. So gathering what was cited here, and the comments in the PR I opened #25297, the right way to move forward would be to have a "list" action added on Argo CD RBAC model.

And this would perhaps follow the way the "list" action is working on Kubernetes ?

• First check if a user is authorized to list a certain resource.
• Second, filter the instances of the resource and only return those for which the user has the right to see.

@aminerachyd actually we don't need to change anything - the system works as expected and we don't need any list action in RBAC

[blakepettersson]

@ppapapetrou76 you're right - this is intended behavior.

[ppapapetrou76]

@ppapapetrou76 you're right - this is intended behavior.

@blakepettersson thanks for the confirmation - should we close this issue?

[choejwoo]

Hi, I think what @ppapapetrou76 mentioned makes sense from a security perspective. If the CLI were to return a “Permission Denied” error when listing projects, it would reveal that projects do exist and that the user is specifically restricted from accessing them, which unintentionally leaks information. This is different from denying access when the user explicitly queries a known project by name, in which case it is expected to return a permission error.

[aminerachyd]

Under my proposal, being able to "list" projects and having the ability to "get" individual would be two separate things.

The proposal I came up with was to have a proper "list" action. The corollary is that a user who legitimately does not have the right to perform a "list" action will not be able to know if there are any projects. And if they do have the right to list objects, then it's the per-project/resource RBAC which takes the lead; the "list" returns only the projects on which the user has a read right.

Here are the scenarios I can think of (assuming only project FOO exists):

Can List Projects?	Can Get Project FOO?	Result of List Action
Yes	Yes	List returns FOO
Yes	No	List returns nothing
No	Yes	Permission error on list action

With this implementation, returning a permission error would give no hint that something exists. Quite the opposite actually, IMO the "list" action proposal is an enabler to perform extra gatekeeping on what a user is capable of doing.

[ppapapetrou76]

@aminerachyd yes I understand that you are proposing to add a new list action but what I'm explaining is that this doesn't exist in any of the resources managed by the CLI. If we decide to add it then we need to update / adjust all the commands that list some kind of resource to keep things consistent

[choejwoo]

@aminerachyd Thanks for the explanation. That helps clarify the scope concern.

In the current RBAC model, the proj list command depends on the get permission, and access control is managed centrally by admin. The security considerations mentioned earlier stem from this dependency and the centrallized management approach. If a user has no get permissions, there's no need to display a "permission denied" msg. When you referenced proj get default in your initial example, I explained the behavior based on that scenario. Of course, if a separate list permission were introduced and the RBAC model changed, the behavior could be different. My point was simply that under current structure, the system works as intended.

On the other hand, the web UI follows the same logic(you can check in setting > projects page), so changing the cli behavior alone wouldn't be consistent. Other resources work similary, so this change would need to consider the overall RBAC structure, the relationship between Projects and Applications, and consistency across cli, UI, and resources. Your proposal is clear and makes sense, but it would be a feature request rather than an issue, and given its scope, it would require a well-defined need before moving forward.