Don't show/list project to user if user doesn't have permissions in project

[Brightside56]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
• I've pasted the output of kargo version, if applicable.
• I've pasted logs, if applicable.

Proposed Feature

I would like projects where user doesn't have permissions to be hidden from this user

Motivation

1. It's possible to filter projects using input, but large list of irrelevant projects (20-30-40) on main page causes frustration among users who work with 2-3-4 projects
2. Principle of least privilege/security point of view/best practices

Suggested Implementation

Additional checks and filtering project list on backend

[krancour]

Take Kargo out of this entirely for a moment. This is more of a general Kubernetes problem without a real solution.

If a user can list resources of a given type, their results when doing so are not constrained by what their permissions happen to be on individual resources of that type. Since a pretty direct comparison could also be made between Projects and namespaces, it's also worth pointing out that if a user can list namespaces, their results when doing so are also not constrained by their permissions on resources within each namespace.

I suppose there is some technical possibility of giving the Kargo API server's list Projects endpoint tricks that k8s itself doesn't have, but I would really hate having kubectl get projects and kargo get projects return different results. Even if that weren't a concern, there would still be a question of what the criteria are for deciding to include/exclude a given Project in the results. Even supposing there were a satisfactory answer for that, the next problem is that this could mean performing thousands of subject access reviews per Project list operation, which would slow that operation to a crawl and possibly even impact cluster performance.

All this being said, I agree that the UX could be better and wonder if the ability to star/favorite projects might not be a more viable improvment.

[Brightside56]

If we focus on the Kubernetes resource model, then absence of possibility to make list verb more granular also doesn't make me happy. I understand that overloading a project with features or workarounds to ensure paranoid security measures can negatively affect its functional part

All this being said, I agree that the UX could be better and wonder if the ability to star/favorite projects might not be a more viable improvment.

In general it would be great improvement. In my edge case there is also a requirement to ensure least privilege on top, even if it's list privilege =/

Allright... I'll try to workaround it somehow, probably

[krancour]

If we focus on the Kubernetes resource model, then absence of possibility to make list verb more granular also doesn't make me happy.

Indeed, I empathize.

We are, however, trying pretty hard to keep all RBAC as pure k8s RBAC and not layer something on top of it for enforcement (the way Argo CD does with casbin, for instance). The inherent disadvantage of something like that is too many things are enforced when the API server is involved and aren't enforced at all when you use kubectl. 😦

I'll carve out a separate issue in the morning for starring/favoriting. That should be non-controversial and easy to get done.