You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Currently, in order to run an action, the caller needs the
override
permissions on the application. In v1.1 theoverride
action was introduced as a verb that allows a caller to "override" what was in git. There were two cases for introducing this field: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 requiresoverride
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
andactions/resume
to deploy a new version, and resume a blue/green Argo Rollout. However, without this feature, jenkins pipelines needsync
andoverride
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 configureactions/*
to allow a user to perform any actions against an application.The text was updated successfully, but these errors were encountered: