RBAC configuration

deploynow does not have its own user management system and has only one built in user, admin the rbac feature enables restricted access to deploynow resources the admin user is a superuser with unrestricted access to the system rbac requires either of the following things sso configured one or more local users setup https //github com/argoproj/argo cd/blob/master/docs/operator manual/user management/index md once sso or local users are configured, additional rbac roles can be defined, and sso groups or local users can then be mapped to roles rbac configuration can be defined in policy csv file that can be accessed and updated via admin console login to admin console click on the deploynow card on the homepage select the deploynow instance for which the rbac should be configured click on the config tab and navigate to the config section edit the configuration yaml file the policy yaml block can be found inside the configuration yaml file basic built in roles argo cd has two pre defined roles but rbac configuration allows defining roles and groups (see below) role\ readonly read only access to all resources role\ admin unrestricted access to all resources these default built in role definitions can be seen in builtin policy csv https //github com/argoproj/argo cd/blob/master/assets/builtin policy csv default policy for authenticated users when a user is authenticated in argo cd, it will be granted the role specified in policy default !!! warning "restricting default permissions" all authenticated users get at least the permissions granted by the default policies this access cannot be blocked by a `deny` rule it is recommended to create a new `role\ authenticated` with the minimum set of permissions possible, then grant permissions to individual roles as needed anonymous access enabling anonymous access to the argo cd instance allows users to assume the default role permissions specified by policy default without being authenticated the anonymous access to argo cd can be enabled using the users anonymous enabledfield in argocd cm(see argocd cm yaml https //github com/argoproj/argo cd/blob/master/docs/operator manual/argocd cm yaml md ) !!! warning when enabling anonymous access, consider creating a new default role and assigning it to the default policies with `policy default role\ unauthenticated` rbac model structure the model syntax is based on casbin https //casbin org/docs/overview there are two different types of syntax one for assigning policies, and another one for assigning users to internal roles group allows to assign authenticated users/groups to internal roles syntax g, \<user/group>, \<role> \<user/group> \<role> the internal role to which the entity will be assigned policy allows to assign permissions to an entity syntax p, \<role/user/group>, \<resource>, \<action>, \<object>, \<effect> \<role/user/group> the entity to whom the policy will be assigned \<resource> the type of resource on which the action is performed \<action> the operation that is being performed on the resource \<object> the object identifier representing the resource on which the action is performed depending on the resource, the object's format will vary \<effect> below is a table that summarizes all possible resources and which actions are valid for each of them resource\action get create update delete sync action override invoke applications ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ applicationsets ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ clusters ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ projects ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ repositories ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ accounts ✅ ❌ ✅ ❌ ❌ ❌ ❌ ❌ certificates ✅ ✅ ❌ ✅ ❌ ❌ ❌ ❌ gpgkeys ✅ ✅ ❌ ✅ ❌ ❌ ❌ ❌ logs ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ exec ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌ extensions ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅ application specific policy some policy only have meaning within an application it is the case with the following resources applications applicationsets logs exec while they can be set in the global configuration, they can also be configured in appproject's roles https //github com/argoproj/argo cd/blob/master/docs/user guide/projects md#project roles the expected \<object>value in the policy structure is replaced by \<app project>/\<app name> for instance, these policies would grant example useraccess to get any applications, but only be able to see logs in my appapplication part of the example projectproject p, example user, applications, get, , allow p, example user, logs, get, example project/my app, allow when application in any namespace https //github com/argoproj/argo cd/blob/master/docs/operator manual/app any namespace md is enabled, the expected \<object>value in the policy structure is replaced by \<app project>/\<app ns>/\<app name> since multiple applications could have the same name in the same project, the policy below makes sure to restrict access only to app namespace p, example user, applications, get, /app namespace/ , allow p, example user, logs, get, example project/app namespace/my app, allow the applicationsresource the applicationsresource is an application specific policy https //github com/argoproj/argo cd/blob/master/docs/operator manual/rbac md#application specific policy the updateand deleteactions, when granted on an application, will allow the user to perform the operation on the application itself and all of its resources it can be desirable to only allow updateor deleteon specific resources within an application to do so, when the action if performed on an application's resource, the \<action>will have the \<action>/\<group>/\<kind>/\<ns>/\<name>format for instance, to grant access to example userto only delete pods in the prod appapplication, the policy could be p, example user, applications, delete/ /pod/ , default/prod app, allow if we want to grant access to the user to update all resources of an application, but not the application itself p, example user, applications, update/ , default/prod app, allow if we want to explicitly deny delete of the application, but allow the user to delete pods p, example user, applications, delete, default/prod app, deny p, example user, applications, delete/ /pod/ , default/prod app, allow !!! note it is not possible to deny fine grained permissions for a sub resource if the action was explicitly allowed on the application for instance, the following policies will allow a user to delete the pod and any other resources in the application ```csv p, example user, applications, delete, default/prod app, allow p, example user, applications, delete/ /pod/ , default/prod app, deny ``` the actionaction corresponds to either built in resource customizations defined in the argo cd repository https //github com/argoproj/argo cd/tree/master/resource customizations , or to custom resource actions https //github com/argoproj/argo cd/blob/master/docs/operator manual/resource actions md#custom resource actions defined by you the \<action>has the action/\<group>/\<kind>/\<action name>format for example, a resource customization path resource customizations/extensions/daemonset/actions/restart/action luacorresponds to the actionpath action/extensions/daemonset/restart if the resource is not under a group (for example, pods or configmaps), then the path will be action//pod/action name the following policies allows the user to perform any action on the daemonset resources, as well as the maintenance offaction on a pod p, example user, applications, action//pod/maintenance off, default/ , allow p, example user, applications, action/extensions/daemonset/ , default/ , allow to allow the user to perform any actions p, example user, applications, action/ , default/ , allow when granted along with the syncaction, the override action will allow a user to synchronize local manifests to the application these manifests will be used instead of the configured source, until the next sync is performed the applicationsetsresource the applicationsetsresource is an application specific policy https //github com/argoproj/argo cd/blob/master/docs/operator manual/rbac md#application specific policy applicationsets https //github com/argoproj/argo cd/blob/master/docs/operator manual/applicationset/index md provide a declarative way to automatically create/update/delete applications allowing the createaction on the resource effectively grants the ability to create applications while it doesn't allow the user to create applications directly, they can create applications via an applicationset !!! note in v2 5, it is not possible to create an applicationset with a templated project field (e g `project {{path basename}}`) via the api (or, by extension, the cli) disallowing templated projects makes project restrictions via rbac safe with the resource being application specific, the \<object>of the applicationsets policy will have the format \<app project>/\<app name> however, since an applicationset does belong to any project, the \<app project>value represents the projects in which the applicationset will be able to create applications with the following policy, a dev groupuser will be unable to create an applicationset capable of creating applications outside the dev projectproject p, dev group, applicationsets, , dev project/ , allow the logsresource the logsresource is an application specific policy https //github com/argoproj/argo cd/blob/master/docs/operator manual/rbac md#application specific policy when granted with the getaction, this policy allows a user to see pod's logs of an application via the argo cd ui the functionality is similar to kubectl logs the execresource the execresource is an application specific policy https //github com/argoproj/argo cd/blob/master/docs/operator manual/rbac md#application specific policy when granted with the createaction, this policy allows a user to execinto pods of an application via the argo cd ui the functionality is similar to kubectl exec see web based terminal https //github com/argoproj/argo cd/blob/master/docs/operator manual/web based terminal md for more info the extensionsresource with the extensionsresource, it is possible to configure permissions to invoke proxy extensions https //github com/argoproj/argo cd/blob/master/docs/developer guide/extensions/proxy extensions md the extensionsrbac validation works in conjunction with the applicationsresource a user needs to have read permission on the application where the request is originated from consider the example below, it will allow the example userto invoke the httpbinextensions in all applications under the defaultproject p, example user, applications, get, default/ , allow p, example user, extensions, invoke, httpbin, allow the denyeffect when denyis used as an effect in a policy, it will be effective if the policy matches even if more specific policies with the alloweffect match as well, the denywill have priority the order in which the policies appears in the policy file configuration has no impact, and the result is deterministic policies evaluation and matching the evaluation of access is done in two parts validating against the default policy configuration, then validating against the policies for the current user if an action is allowed or denied by the default policies, then this effect will be effective without further evaluation when the effect is undefined, the evaluation will continue with subject specific policies the access will be evaluated for the user, then for each configured group that the user is part of the matching engine, configured in policy matchmode, can use two different match modes to compare the values of tokens glob regex when all tokens match during the evaluation, the effect will be returned the evaluation will continue until all matching policies are evaluated, or until a policy with the denyeffect matches after all policies are evaluated, if there was at least one alloweffect and no deny, access will be granted glob matching when globis used, the policy tokens are treated as single terms, without separators consider the following policy p, example user, applications, action/extensions/ , default/ , allow when the example userexecutes the extensions/daemonset/testaction, the following globmatches will happen the current user the value the value the value using sso users/groups the scopesfield controls which oidc scopes to examine during rbac enforcement (in addition to subscope) if omitted, it defaults to '\[groups]' the scope value can be a string, or a list of strings for more information on scopesplease review the user management documentation https //github com/argoproj/argo cd/blob/master/docs/operator manual/user management/index md the following example shows targeting emailas well as groupsfrom your oidc provider apiversion v1 kind configmap metadata name argocd rbac cm namespace argocd labels app kubernetes io/name argocd rbac cm app kubernetes io/part of argocd data policy csv | p, my org\ team alpha, applications, sync, my project/ , allow g, my org\ team beta, role\ admin g, user\@example org, role\ admin policy default role\ readonly scopes '\[groups, email]' this can be useful to associate users' emails and groups directly in appproject apiversion argoproj io/v1alpha1 kind appproject metadata name team beta project namespace argocd spec roles \ name admin description admin privileges to team beta policies \ p, proj\ team beta project\ admin, applications, , , allow groups \ user\@example org # value from the email scope \ my org\ team beta # value from the groups scope local users/accounts local users https //github com/argoproj/argo cd/blob/master/docs/operator manual/user management/index md#local usersaccounts are assigned access by either grouping them with a role or by assigning policies directly to them the example below shows how to assign a policy directly to a local user p, my local user, applications, sync, my project/ , allow this example shows how to assign a role to a local user g, my local user, role\ admin !!! warning "ambiguous group assignments" if you have \[enabled sso]\(user management/index md#sso), any sso user with a scope that matches a local user will be added to the same roles as the local user for example, if local user `sally` is assigned to `role\ admin`, and if an sso user has a scope which happens to be named `sally`, that sso user will also be assigned to `role\ admin` an example of where this may be a problem is if your sso provider is an scm, and org members are automatically granted scopes named after the orgs if a user can create or add themselves to an org in the scm, they can gain the permissions of the local user with the same name to avoid ambiguity, if you are using local users and sso, it is recommended to assign policies directly to local users, and not to assign roles to local users in other words, instead of using `g, my local user, role\ admin`, you should explicitly assign policies to `my local user` ```yaml p, my local user, , , , allow ``` policy csv composition it is possible to provide additional entries in the argocd rbac cmconfigmap to compose the final policy csv in this case, the key must follow the pattern policy \<any string> csv argo cd will concatenate all additional policies it finds with this pattern below the main one ('policy csv') the order of additional provided policies are determined by the key string example if two additional policies are provided with keys policy a csvand policy b csv, it will first concatenate policy a csvand then policy b csv this is useful to allow composing policies in config management tools like kustomize, helm, etc the example below shows how a kustomize patch can be provided in an overlay to add additional configuration to an existing rbac configmap apiversion v1 kind configmap metadata name argocd rbac cm namespace argocd data policy tester overlay csv | p, role\ tester, applications, , / , allow p, role\ tester, projects, , , allow g, my org\ team qa, role\ tester validating and testing your rbac policies if you want to ensure that your rbac policies are working as expected, you can use the argocd admin settings rbaccommand https //github com/argoproj/argo cd/blob/master/docs/user guide/commands/argocd admin settings rbac md to validate them this tool allows you to test whether a certain role or subject can perform the requested action with a policy that's not live yet in the system, i e from a local file or config map additionally, it can be used against the live rbac configuration in the cluster your argo cd is running in validating a policy to check whether your new policy configuration is valid and understood by argo cd's rbac implementation, you can use the argocd admin settings rbac validatecommand https //github com/argoproj/argo cd/blob/master/docs/user guide/commands/argocd admin settings rbac validate md testing a policy to test whether a role or subject (group or local user) has sufficient permissions to execute certain actions on certain resources, you can use the argocd admin settings rbac cancommand https //github com/argoproj/argo cd/blob/master/docs/user guide/commands/argocd admin settings rbac can md