fix(rbac): grant Argo Rollouts permissions unconditionally - #540
Merged
Conversation
Rollouts RBAC was gated on .Capabilities.APIVersions.Has, which only passes when the Rollout CRD exists at helm render time. Clusters that install Argo Rollouts after the agent (or use GitOps/templated installs, where .Capabilities cannot see CRDs) never got the grant, so kubewatch could not watch Rollouts and no Rollout change events / spec diffs were emitted until the next helm upgrade. Grant the rules unconditionally instead — the same rationale already applied to the karpenter block: an RBAC rule for an absent CRD is inert and becomes active the moment the CRD is installed. Both kubewatch and the runner probe the CRD before watching, so the grant is safe. Also update the runner's stale comments/log that referenced the old render-time gating.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes the conditional Helm capability checks for Argo Rollouts RBAC permissions, granting them unconditionally across the service accounts. This ensures that the RBAC rules are active immediately when Argo Rollouts is installed, without requiring a subsequent Helm upgrade. Additionally, the Go discovery service has been updated to reflect this change in its logging and comments. I have no feedback to provide as there are no review comments.
kubectl scale on a Rollout patches the rollouts/scale subresource, which is a distinct RBAC resource — verbs on rollouts alone don't cover it, so the runner's kubectl write path failed with Forbidden. Mirror the existing deployments/scale treatment in the apps block.
Contributor
|
📦 Image Tags Updated |
The apps block grants delete on deployments/statefulsets/daemonsets/ replicasets unconditionally, but rollouts delete was gated behind runner.enableWritePermissions — so delete_workload on a Rollout failed on default installs while the same action on a Deployment worked. Ungate delete; create stays gated like create for apps kinds.
Contributor
|
📦 Image Tags Updated |
RamanKharchee
approved these changes
Jul 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
Rollouts RBAC in all three clusterrole templates was gated on
.Capabilities.APIVersions.Has "argoproj.io/v1alpha1/Rollout", which only passes when the Rollout CRD exists at helm render time. Any cluster that installs Argo Rollouts after the agent chart (or installs via GitOps/templated manifests, where.Capabilitiescannot see CRDs) never gets the grant until the nexthelm upgrade.Observed in dev: kubewatch (forwarder) logged
rollouts.argoproj.io is forbiddenon every backoff, so Rollout UPDATE events never reached the trigger engine — noConfigurationChangefindings, no spec diffs for Rollouts, while Deployments worked fine.Fix
Grant the
argoproj.io/rolloutsrules unconditionally in:forwarder-service-account.yaml(get/list/watch)runner-service-account.yaml(get/list/watch/patch/update; create/delete still behindrunner.enableWritePermissions)runner-service-account-readonly.yaml(get/list/watch)This is the same pattern the karpenter block in these files already uses, with the same rationale: an RBAC rule for an absent CRD is inert and becomes active the moment the CRD is installed. Both kubewatch and the runner probe the CRD before watching, so the unconditional grant cannot stall anything.
Also updates the runner's stale comment/log in
pkg/discovery/service.gothat referenced the old render-time gating.Verification
helm lintpasses;helm templaterenders the rollouts rule in default andrunner.readOnly=truemodes.spec.replicasproduced aConfigurationChangefinding with the expected side-by-side spec diff in the UI.