feat: Fine grained update delete RBAC w/ v3 gate #20671
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We would like to allow our engineers to use the rollback functionality while having auto-sync enabled, without granting them the ability to edit an application's sub-resource manifests. For compliance purposes, we can only deploy using a known set of manifests from a protected source, which is the git repo holding our manifests that engineers do not have access to.
Using the rollback functionality when auto-sync is enabled requires the user to disable auto-sync, which in turn requires update permissions on the application itself. We can allow this by doing the following:
However, this will also allow engineers to edit application manifests. It follows that we would like to add a deny for the application's sub-resources, but as the RBAC documentation states, this deny is ignored.
This PR changes application resource RBAC to allow users to set separate update/delete permissions for the application itself, but still deny sub-resources. We can then do something like this:
It introduces a breaking change to RBAC (see #19988), so it will have to wait until V3. To allow this functionality in V2, a config value (
server.rbac.enablev3
inargocd-cm
) was added that allows the user to opt in to this new behavior. I did my best to implement #19988 in the first commit, and then to add the config value gating in a following commit, so that the first commit can be cherry-picked or the second commit reverted when the V3 release is cut.RBAC docs: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#fine-grained-permissions-for-updatedelete-action
Closes #20600
Checklist: