Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource actions need their own dynamic RBAC action/* verbs #2002

Closed
jessesuen opened this issue Jul 24, 2019 · 2 comments
Closed

Resource actions need their own dynamic RBAC action/* verbs #2002

jessesuen opened this issue Jul 24, 2019 · 2 comments
Assignees
Labels
enhancement New feature or request security Security related
Milestone

Comments

@jessesuen
Copy link
Member

Currently, in order to run an action, the caller needs the override permissions on the application. In v1.1 the override action was introduced as a verb that allows a caller to "override" what was in git. There were two cases for introducing this field:

  • local sync
  • argocd app patch

Using this verb, an Argo CD operator can decide if they wanted to employ a strict set of GitOps principles, where everything must go through git, versus a looser practice of allowing ad-hoc resource patching on the part of the developer.

See some more discussion about the need for the separate override verb:
#1578 (comment)

The consequence of introducing override, was that we currently equate the running a resource actions as a resource patch, even though they are semantically different. Therefore, in Argo CD v1.1, the running of an action requires override permissions (it previously was update).

In truth, the ability to run resource actions is a less of a security concern than patching, because the available resource actions are under control by an Argo CD operator, and are limited in scope of what they can mutate/run/deploy in the application. For example, the "resume" action for Argo Rollouts, simply unpauses a rollout, and it is impossible to exploit the resume action to run arbitrary images.

On the other hand, pathing/override would allow users to patch an existing deployment, to run arbitrary container images, so there there is a much higher security risk of giving someone override permissions.

This issue is about introducing actions/<actionname> as a new verb to an application. This would provide a better security model of least amount of privilege, and allow operators to grant users/automation the ability to perform actions, but not override what's in git.

The concrete use case here is the following: Using this feature, jenkins pipelines would only need sync and actions/resume to deploy a new version, and resume a blue/green Argo Rollout. However, without this feature, jenkins pipelines need sync and override to do this, the latter of which is a security concern since they could patch an existing deployment to run arbitrary images.

The <actionname> would be need to be dynamic, and would depending on the actions configured in Argo CD. (NOTE: it should also be possible to configure actions/* to allow a user to perform any actions against an application.

@jessesuen jessesuen added enhancement New feature or request security Security related labels Jul 24, 2019
@jessesuen jessesuen added this to the v1.2 milestone Jul 24, 2019
@alexec
Copy link
Contributor

alexec commented Jul 24, 2019

are you sure this is v1.2 not v1.3?

@jessesuen jessesuen modified the milestones: v1.2, v1.3 Jul 24, 2019
@simster7
Copy link
Member

simster7 commented Aug 5, 2019

@jessesuen @alexec I can work on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request security Security related
Projects
None yet
Development

No branches or pull requests

4 participants