feat: use resource actions for auto-sync toggle instead of update permission (#21564)

[ebracha]

Checklist:

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the release note).
• The title of the PR conforms to the Toolchain Guide
• I've included "Closes [ISSUE #]" or "Fixes [ISSUE #]" in the description to automatically close the associated issue.
• I've updated both the CLI and UI to expose my feature, or I plan to submit a second PR with them.
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have signed off all my commits as required by DCO
• I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
• My build is green (troubleshooting builds).
• My new feature complies with the feature status guidelines.
• I have added a brief description of why this PR is necessary and/or what this PR solves.
• Optional. My organization is added to USERS.md.
• Optional. For bug fixes, I've indicated what older releases this fix should be cherry-picked into (this may or may not happen depending on risk/complexity).

Description:
Closes #21564

This PR changes how auto-sync toggle is implemented in Argo CD by:

1. Moving from using update permissions to using resource actions
2. Adding a new resource action 'toggle-auto-sync' for applications
3. Updating the UI to use this action instead of direct application updates
4. Keeps prune and self-heal settings under update permission

The change improves security by:

• Providing more granular control over auto-sync operations
• Following the principle of least privilege
• Allowing separate RBAC permissions for auto-sync vs other application updates

Testing

Action Discovery

The new toggle-auto-sync action is properly discovered for all application types:

# List available actions for different applications
$ argocd app actions list helm-guestbook
GROUP           KIND         NAME            ACTION          DISABLED
argoproj.io     Application  helm-guestbook  toggle-auto-sync false

$ argocd app actions list kustomize-guestbook
GROUP           KIND         NAME                ACTION          DISABLED
argoproj.io     Application  kustomize-guestbook toggle-auto-sync false

$ argocd app actions list sync-waves
GROUP           KIND         NAME        ACTION          DISABLED
argoproj.io     Application  sync-waves  toggle-auto-sync false

Action Execution

The action can be executed on any application:

# Toggle auto-sync on an application
$ argocd app actions run helm-guestbook toggle-auto-sync --kind Application

UI Execution

The UI now uses the same action-based approach for toggling auto-sync:

1. Navigate to an application in the Argo CD UI
2. Click on the "App Details" tab
3. The auto-sync toggle button now uses the toggle-auto-sync action
4. Clicking the toggle executes the action with proper RBAC checks
5. Properties 'prune' and 'self-heal' are still using update permission

RBAC Configuration

The new action-based approach allows for more granular RBAC control using Argo CD's policy format:

# Allow a role to only toggle auto-sync
p, role:auto-sync-toggler, applications, action/argoproj.io/Application/toggle-auto-sync, */*, allow
p, role:auto-sync-toggler, applications, get, */*, allow
g, testuser, role:auto-sync-toggler

This configuration:

• Allows viewing application details (get permission)
• Specifically allows executing the toggle-auto-sync action
• Prevents other application modifications
• Can be assigned to users or groups

[bunnyshell]

🔴 Preview Environment stopped on Bunnyshell

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔵 /bns:start to start the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[agaudreault]

This would be a breaking change... What about only adding a toggle auto-sync action on the application, but not changing the logic of the internal button?

[crenshaw-dev]

Would be nice to have consistent permissioning in the UI... Maybe the button could try the new API first and fall back. The backend could log a deprecation warning for the old API (assuming it's its own endpoint).

[ebracha]

Thanks for the feedback! following your suggestions:

possible approaches are:

1. Minimal Change Approach (suggested by @agaudreault ):

   • Keep the existing UI button behavior using update permissions
   • Add the toggle-auto-sync action as an additional way to toggle auto-sync
   • This maintains backward compatibility while adding the new capability
   • Users can gradually migrate to using the action-based approach

2. Progressive Enhancement Approach (suggested by @crenshaw-dev):

   • Have the UI button try the new action API first
   • Fall back to update permission if the action fails
   • Log deprecation warnings for the old update-based approach

I'm leaning towards the Minimal Change Approach because:

• It maintains consistent behavior in the UI
• It's less disruptive to existing installations
• It still provides the new action-based capability for those who want it

Since this is a security-related change that affects user permissions, I'd like to get your thoughts on which approach would be better for the Argo CD community. What do you think?

[agaudreault]

I think the approach @crenshaw-dev suggested has value because it allows to test the breaking changes and to opt-in the feature.

You can do 2 separate PRs so it is easier to review. Implement approach 1, merge, then implement approach 2.

I would add a requirement to 2)

• Add a feature flag to enable the use of actions rbac instead of update. I think this should be opt-in because multiple people might have given permissions on action/* already. If we default (or fallback) to action/* without a flag, then we might cause users to have more permissions than what the admins expected.

[ebracha]

yea good point doing it as an opt-in feature. I've modified this PR to follow the first approach:

1. Added the toggle-auto-sync action as a separate capability
2. Kept the existing UI button behavior unchanged
3. Maintained backward compatibility

Once this PR is merged, I'll create a new PR for the second approach that will:

1. Add a feature flag for action-based auto-sync (opt-in)
2. Modify the UI to try the action first and fall back to update permission
3. Add deprecation warnings for the update-based approach

Since the UI changes involve feature flags and deprecation warnings, should I create a new issue or link to #21564?