argocd Please read this documentation carefully before you enable this feature Misconfiguration could lead to potential security issues warning Argo CD administrators can define a certain set of namespaces where resources may be created updated and reconciled in However applications in these additional namespaces will only be allowed to use certain as configured by the Argo CD administrators This allows ordinary Argo CD users e g application teams to use patterns like declarative management of resources implementing app of apps and others without the risk of a privilege escalation through usage of other that would exceed the permissions granted to the application teams As of version 2 5 Argo CD supports managing resources in namespaces other than the control plane s namespace which is usually but this feature has to be explicitly enabled and configured appropriately Introduction Applications in any namespace

Answer:
# Applications in any namespace

!!! warning
    Please read this documentation carefully before you enable this feature. Misconfiguration could lead to potential security issues.

## Introduction

As of version 2.5, Argo CD supports managing `Application` resources in namespaces other than the control plane's namespace (which is usually `argocd`), but this feature has to be explicitly enabled and configured appropriately.

Argo CD administrators can define a certain set of namespaces where `Application` resources may be created, updated and reconciled in. However, applications in these additional namespaces will only be allowed to use certain `AppProjects`, as configured by the Argo CD administrators. This allows ordinary Argo CD users (e.g. application teams) to use patterns like declarative management of `Application` resources, implementing app-of-apps and others without the risk of a privilege escalation through usage of other `AppProjects` that would exceed the permissions granted to the application teams.

Some manual steps will need to be performed by the Argo CD administrator in order to enable this feature.

One additional advantage of adopting applications in any namespace is to allow end-users to configure notifications for their Argo CD application in the namespace where Argo CD application is running in. See notifications [namespace based configuration](notifications/index.md#namespace-based-configuration) page for more information.

## Prerequisites

### Cluster-scoped Argo CD installation

This feature can only be enabled and used when your Argo CD is installed as a cluster-wide instance, so it has permissions to list and manipulate resources on a cluster scope. It will not work with an Argo CD installed in namespace-scoped mode.

### Switch resource tracking method

Also, while technically not necessary, it is strongly suggested that you switch the application tracking method from the default `label` setting to either `annotation` or `annotation+label`. The reasoning for this is, that application names will be a composite of the namespace's name and the name of the `Application`, and this can easily exceed the 63 characters length limit imposed on label values. Annotations have a notably greater length limit.

To enable annotation based resource tracking, refer to the documentation about [resource tracking methods](../../user-guide/resource_tracking/)

## Implementation details

### Overview

In order for an application to be managed and reconciled outside the Argo CD's control plane namespace, two prerequisites must match:

1. The `Application`'s namespace must be explicitly enabled using the `--application-namespaces` parameter for the `argocd-application-controller` and `argocd-server` workloads. This parameter controls the list of namespaces that Argo CD will be allowed to source `Application` resources from globally. Any namespace not configured here cannot be used from any `AppProject`.
1. The `AppProject` referenced by the `.spec.project` field of the `Application` must have the namespace listed in its `.spec.sourceNamespaces` field. This setting will determine whether an `Application` may use a certain `AppProject`. If an `Application` specifies an `AppProject` that is not allowed, Argo CD refuses to process this `Application`. As stated above, any namespace configured in the `.spec.sourceNamespaces` field must also be enabled globally.

`Applications` in different namespaces can be created and managed just like any other `Application` in the `argocd` namespace previously, either declaratively or through the Argo CD API (e.g. using the CLI, the web UI, the REST API, etc).

### Reconfigure Argo CD to allow certain namespaces

#### Change workload startup parameters

In order to enable this feature, the Argo CD administrator must reconfigure the `argocd-server` and `argocd-application-controller` workloads to add the `--application-namespaces` parameter to the container's startup command.

The `--application-namespaces` parameter takes a comma-separated list of namespaces where `Applications` are to be allowed in. Each entry of the list supports:

- shell-style wildcards such as `*`, so for example the entry `app-team-*` would match `app-team-one` and `app-team-two`. To enable all namespaces on the cluster where Argo CD is running on, you can just specify `*`, i.e. `--application-namespaces=*`.
- regex, requires wrapping the string in ```/```, example to allow all namespaces except a particular one: ```/^((?!not-allowed).)*$/```.

The startup parameters for both, the `argocd-server` and the `argocd-application-controller` can also be conveniently set up and kept in sync by specifying the `application.namespaces` settings in the `argocd-cmd-params-cm` ConfigMap _instead_ of changing the manifests for the respective workloads. For example:

```yaml
data:
  application.namespaces: app-team-one, app-team-two
```

would allow the `app-team-one` and `app-team-two` namespaces for managing `Application` resources. After a change to the `argocd-cmd-params-cm` namespace, the appropriate workloads need to be restarted:

```bash
kubectl rollout restart -n argocd deployment argocd-server
kubectl rollout restart -n argocd statefulset argocd-application-controller
```

#### Adapt Kubernetes RBAC

We decided to not extend the Kubernetes RBAC for the `argocd-server` workload by default for the time being. If you want `Applications` in other namespaces to be managed by the Argo CD API (i.e. the CLI and UI), you need to extend the Kubernetes permissions for the `argocd-server` ServiceAccount.

We supply a `ClusterRole` and `ClusterRoleBinding` suitable for this purpose in the `examples/k8s-rbac/argocd-server-applications` directory. For a default Argo CD installation (i.e. installed to the `argocd` namespace), you can just apply them as-is:

```shell
kubectl apply -k examples/k8s-rbac/argocd-server-applications/
```

`argocd-notifications-controller-rbac-clusterrole.yaml` and `argocd-notifications-controller-rbac-clusterrolebinding.yaml` are used to support notifications controller to notify apps in all namespaces.

!!! note
    At some later point in time, we may make this cluster role part of the default installation manifests.

### Allowing additional namespaces in an AppProject

Any user with Kubernetes access to the Argo CD control plane's namespace (`argocd`), especially those with permissions to create or update `Applications` in a declarative way, is to be considered an Argo CD admin.

This prevented unprivileged Argo CD users from declaratively creating or managing `Applications` in the past. Those users were constrained to using the API instead, subject to Argo CD RBAC which ensures only `Applications` in allowed `AppProjects` were created.

For an `Application` to be created outside the `argocd` namespace, the `AppProject` referred to in the `Application`'s `.spec.project` field must include the `Application`'s namespace in its `.spec.sourceNamespaces` field.

For example, consider the two following (incomplete) `AppProject` specs:

```yaml
kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: project-one
  namespace: argocd
spec:
  sourceNamespaces:
  - namespace-one
```

and

```yaml
kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
  name: project-two
  namespace: argocd
spec:
  sourceNamespaces:
  - namespace-two
```

In order for an Application to set `.spec.project` to `project-one`, it would have to be created in either namespace `namespace-one` or `argocd`. Likewise, in order for an Application to set `.spec.project` to `project-two`, it would have to be created in either namespace `namespace-two` or `argocd`.

If an Application in `namespace-two` would set their `.spec.project` to `project-one` or an Application in `namespace-one` would set their `.spec.project` to `project-two`, Argo CD would consider this as a permission violation and refuse to reconcile the Application.

Also, the Argo CD API will enforce these constraints, regardless of the Argo CD RBAC permissions.

The `.spec.sourceNamespaces` field of the `AppProject` is a list that can contain an arbitrary amount of namespaces, and each entry supports shell-style wildcard, so that you can allow namespaces with patterns like `team-one-*`.

!!! warning
    Do not add user controlled namespaces in the `.spec.sourceNamespaces` field of any privileged AppProject like the `default` project. Always make sure that the AppProject follows the principle of granting least required privileges. Never grant access to the `argocd` namespace within the AppProject.

!!! note
    For backwards compatibility, Applications in the Argo CD control plane's namespace (`argocd`) are allowed to set their `.spec.project` field to reference any AppProject, regardless of the restrictions placed by the AppProject's `.spec.sourceNamespaces` field.

### Application names

For the CLI and UI, applications are now referred to and displayed as in the format `<namespace>/<name>`.

For backwards compatibility, if the namespace of the Application is the control plane's namespace (i.e. `argocd`), the `<namespace>` can be omitted from the application name when referring to it. For example, the application names `argocd/someapp` and `someapp` are semantically the same and refer to the same application in the CLI and the UI.

### Application RBAC

The RBAC syntax for Application objects has been changed from `<project>/<application>` to `<project>/<namespace>/<application>` to accommodate the need to restrict access based on the source namespace of the Application to be managed.

For backwards compatibility, Applications in the `argocd` namespace can still be refered to as `<project>/<application>` in the RBAC policy rules.

Wildcards do not make any distinction between project and application namespaces yet. For example, the following RBAC rule would match any application belonging to project `foo`, regardless of the namespace it is created in:

```
p, somerole, applications, get, foo/*, allow
```

If you want to restrict access to be granted only to `Applications` in project `foo` within namespace `bar`, the rule would need to be adapted as follows:

```
p, somerole, applications, get, foo/bar/*, allow
```

## Managing applications in other namespaces

### Declaratively

For declarative management of Applications, just create the Application from a YAML or JSON manifest in the desired namespace. Make sure that the `.spec.project` field refers to an AppProject that allows this namespace. For example, the following (incomplete) Application manifest creates an Application in the namespace `some-namespace`:

```yaml
kind: Application
apiVersion: argoproj.io/v1alpha1
metadata:
  name: some-app
  namespace: some-namespace
spec:
  project: some-project
  # ...
```

The project `some-project` will then need to specify `some-namespace` in the list of allowed source namespaces, e.g.

```yaml
kind: AppProject
apiVersion: argoproj.io/v1alpha1
metadata:
    name: some-project
    namespace: argocd
spec:
    sourceNamespaces:
    - some-namespace
```

### Using the CLI

You can use all existing Argo CD CLI commands for managing applications in other namespaces, exactly as you would use the CLI to manage applications in the control plane's namespace.

For example, to retrieve the `Application` named `foo` in the namespace `bar`, you can use the following CLI command:

```shell
argocd app get foo/bar
```

Likewise, to manage this application, keep referring to it as `foo/bar`:

```bash
# Create an application
argocd app create foo/bar ...
# Sync the application
argocd app sync foo/bar
# Delete the application
argocd app delete foo/bar
# Retrieve application's manifest
argocd app manifests foo/bar
```

As stated previously, for applications in the Argo CD's control plane namespace, you can omit the namespace from the application name.

### Using the UI

Similar to the CLI, you can refer to the application in the UI as `foo/bar`.

For example, to create an application named `bar` in the namespace `foo` in the web UI, set the application name in the creation dialogue's _Application Name_ field to `foo/bar`. If the namespace is omitted, the control plane's namespace will be used.

### Using the REST API

If you are using the REST API, the namespace for `Application` cannot be specified as the application name, and resources need to be specified using the optional `appNamespace` query parameter. For example, to work with the `Application` resource named `foo` in the namespace `bar`, the request would look like follows:

```bash
GET /api/v1/applications/foo?appNamespace=bar
```

For other operations such as `POST` and `PUT`, the `appNamespace` parameter must be part of the request's payload.

For `Application` resources in the control plane namespace, this parameter can be omitted.

Applications in any namespace      warning     Please read this documentation carefully before you enable this feature  Misconfiguration could lead to potential security issues      Introduction  As of version 2 5  Argo CD supports managing  Application  resources in namespaces other than the control plane s namespace  which is usually  argocd    but this feature has to be explicitly enabled and configured appropriately   Argo CD administrators can define a certain set of namespaces where  Application  resources may be created  updated and reconciled in  However  applications in these additional namespaces will only be allowed to use certain  AppProjects   as configured by the Argo CD administrators  This allows ordinary Argo CD users  e g  application teams  to use patterns like declarative management of  Application  resources  implementing app of apps and others without the risk of a privilege escalation through usage of other  AppProjects  that would exceed the permissions granted to the application teams   Some manual steps will need to be performed by the Argo CD administrator in order to enable this feature    One additional advantage of adopting applications in any namespace is to allow end users to configure notifications for their Argo CD application in the namespace where Argo CD application is running in  See notifications  namespace based configuration  notifications index md namespace based configuration  page for more information      Prerequisites      Cluster scoped Argo CD installation  This feature can only be enabled and used when your Argo CD is installed as a cluster wide instance  so it has permissions to list and manipulate resources on a cluster scope  It will not work with an Argo CD installed in namespace scoped mode       Switch resource tracking method  Also  while technically not necessary  it is strongly suggested that you switch the application tracking method from the default  label  setting to either  annotation  or  annotation label   The reasoning for this is  that application names will be a composite of the namespace s name and the name of the  Application   and this can easily exceed the 63 characters length limit imposed on label values  Annotations have a notably greater length limit   To enable annotation based resource tracking  refer to the documentation about  resource tracking methods        user guide resource tracking       Implementation details      Overview  In order for an application to be managed and reconciled outside the Argo CD s control plane namespace  two prerequisites must match   1  The  Application  s namespace must be explicitly enabled using the    application namespaces  parameter for the  argocd application controller  and  argocd server  workloads  This parameter controls the list of namespaces that Argo CD will be allowed to source  Application  resources from globally  Any namespace not configured here cannot be used from any  AppProject   1  The  AppProject  referenced by the   spec project  field of the  Application  must have the namespace listed in its   spec sourceNamespaces  field  This setting will determine whether an  Application  may use a certain  AppProject   If an  Application  specifies an  AppProject  that is not allowed  Argo CD refuses to process this  Application   As stated above  any namespace configured in the   spec sourceNamespaces  field must also be enabled globally    Applications  in different namespaces can be created and managed just like any other  Application  in the  argocd  namespace previously  either declaratively or through the Argo CD API  e g  using the CLI  the web UI  the REST API  etc        Reconfigure Argo CD to allow certain namespaces       Change workload startup parameters  In order to enable this feature  the Argo CD administrator must reconfigure the  argocd server  and  argocd application controller  workloads to add the    application namespaces  parameter to the container s startup command   The    application namespaces  parameter takes a comma separated list of namespaces where  Applications  are to be allowed in  Each entry of the list supports     shell style wildcards such as      so for example the entry  app team    would match  app team one  and  app team two   To enable all namespaces on the cluster where Argo CD is running on  you can just specify      i e     application namespaces       regex  requires wrapping the string in          example to allow all namespaces except a particular one           not allowed              The startup parameters for both  the  argocd server  and the  argocd application controller  can also be conveniently set up and kept in sync by specifying the  application namespaces  settings in the  argocd cmd params cm  ConfigMap  instead  of changing the manifests for the respective workloads  For example      yaml data    application namespaces  app team one  app team two      would allow the  app team one  and  app team two  namespaces for managing  Application  resources  After a change to the  argocd cmd params cm  namespace  the appropriate workloads need to be restarted      bash kubectl rollout restart  n argocd deployment argocd server kubectl rollout restart  n argocd statefulset argocd application controller           Adapt Kubernetes RBAC  We decided to not extend the Kubernetes RBAC for the  argocd server  workload by default for the time being  If you want  Applications  in other namespaces to be managed by the Argo CD API  i e  the CLI and UI   you need to extend the Kubernetes permissions for the  argocd server  ServiceAccount   We supply a  ClusterRole  and  ClusterRoleBinding  suitable for this purpose in the  examples k8s rbac argocd server applications  directory  For a default Argo CD installation  i e  installed to the  argocd  namespace   you can just apply them as is      shell kubectl apply  k examples k8s rbac argocd server applications        argocd notifications controller rbac clusterrole yaml  and  argocd notifications controller rbac clusterrolebinding yaml  are used to support notifications controller to notify apps in all namespaces       note     At some later point in time  we may make this cluster role part of the default installation manifests       Allowing additional namespaces in an AppProject  Any user with Kubernetes access to the Argo CD control plane s namespace   argocd    especially those with permissions to create or update  Applications  in a declarative way  is to be considered an Argo CD admin   This prevented unprivileged Argo CD users from declaratively creating or managing  Applications  in the past  Those users were constrained to using the API instead  subject to Argo CD RBAC which ensures only  Applications  in allowed  AppProjects  were created   For an  Application  to be created outside the  argocd  namespace  the  AppProject  referred to in the  Application  s   spec project  field must include the  Application  s namespace in its   spec sourceNamespaces  field   For example  consider the two following  incomplete   AppProject  specs      yaml kind  AppProject apiVersion  argoproj io v1alpha1 metadata    name  project one   namespace  argocd spec    sourceNamespaces      namespace one      and     yaml kind  AppProject apiVersion  argoproj io v1alpha1 metadata    name  project two   namespace  argocd spec    sourceNamespaces      namespace two      In order for an Application to set   spec project  to  project one   it would have to be created in either namespace  namespace one  or  argocd   Likewise  in order for an Application to set   spec project  to  project two   it would have to be created in either namespace  namespace two  or  argocd    If an Application in  namespace two  would set their   spec project  to  project one  or an Application in  namespace one  would set their   spec project  to  project two   Argo CD would consider this as a permission violation and refuse to reconcile the Application   Also  the Argo CD API will enforce these constraints  regardless of the Argo CD RBAC permissions   The   spec sourceNamespaces  field of the  AppProject  is a list that can contain an arbitrary amount of namespaces  and each entry supports shell style wildcard  so that you can allow namespaces with patterns like  team one          warning     Do not add user controlled namespaces in the   spec sourceNamespaces  field of any privileged AppProject like the  default  project  Always make sure that the AppProject follows the principle of granting least required privileges  Never grant access to the  argocd  namespace within the AppProject       note     For backwards compatibility  Applications in the Argo CD control plane s namespace   argocd   are allowed to set their   spec project  field to reference any AppProject  regardless of the restrictions placed by the AppProject s   spec sourceNamespaces  field         Application names  For the CLI and UI  applications are now referred to and displayed as in the format   namespace   name      For backwards compatibility  if the namespace of the Application is the control plane s namespace  i e   argocd    the   namespace   can be omitted from the application name when referring to it  For example  the application names  argocd someapp  and  someapp  are semantically the same and refer to the same application in the CLI and the UI       Application RBAC  The RBAC syntax for Application objects has been changed from   project   application   to   project   namespace   application   to accommodate the need to restrict access based on the source namespace of the Application to be managed   For backwards compatibility  Applications in the  argocd  namespace can still be refered to as   project   application   in the RBAC policy rules   Wildcards do not make any distinction between project and application namespaces yet  For example  the following RBAC rule would match any application belonging to project  foo   regardless of the namespace it is created in       p  somerole  applications  get  foo    allow      If you want to restrict access to be granted only to  Applications  in project  foo  within namespace  bar   the rule would need to be adapted as follows       p  somerole  applications  get  foo bar    allow           Managing applications in other namespaces      Declaratively  For declarative management of Applications  just create the Application from a YAML or JSON manifest in the desired namespace  Make sure that the   spec project  field refers to an AppProject that allows this namespace  For example  the following  incomplete  Application manifest creates an Application in the namespace  some namespace       yaml kind  Application apiVersion  argoproj io v1alpha1 metadata    name  some app   namespace  some namespace spec    project  some project              The project  some project  will then need to specify  some namespace  in the list of allowed source namespaces  e g      yaml kind  AppProject apiVersion  argoproj io v1alpha1 metadata      name  some project     namespace  argocd spec      sourceNamespaces        some namespace          Using the CLI  You can use all existing Argo CD CLI commands for managing applications in other namespaces  exactly as you would use the CLI to manage applications in the control plane s namespace   For example  to retrieve the  Application  named  foo  in the namespace  bar   you can use the following CLI command      shell argocd app get foo bar      Likewise  to manage this application  keep referring to it as  foo bar       bash   Create an application argocd app create foo bar       Sync the application argocd app sync foo bar   Delete the application argocd app delete foo bar   Retrieve application s manifest argocd app manifests foo bar      As stated previously  for applications in the Argo CD s control plane namespace  you can omit the namespace from the application name       Using the UI  Similar to the CLI  you can refer to the application in the UI as  foo bar    For example  to create an application named  bar  in the namespace  foo  in the web UI  set the application name in the creation dialogue s  Application Name  field to  foo bar   If the namespace is omitted  the control plane s namespace will be used       Using the REST API  If you are using the REST API  the namespace for  Application  cannot be specified as the application name  and resources need to be specified using the optional  appNamespace  query parameter  For example  to work with the  Application  resource named  foo  in the namespace  bar   the request would look like follows      bash GET  api v1 applications foo appNamespace bar      For other operations such as  POST  and  PUT   the  appNamespace  parameter must be part of the request s payload   For  Application  resources in the control plane namespace  this parameter can be omitted


argocd warning Alpha Feature Since 2 13 0 Please read this documentation carefully before you enable this feature Misconfiguration could lead to potential security issues warning the control plane operations feature that allows you to control the service account used for the sync operation The configured service account Application Sync using impersonation could have lesser privileges required for creating resources compared to the highly privileged access required for This is an experimental

Answer:
# Application Sync using impersonation

!!! warning "Alpha Feature (Since 2.13.0)"
    This is an experimental, [alpha-quality](https://github.com/argoproj/argoproj/blob/main/community/feature-status.md#alpha)
    feature that allows you to control the service account used for the sync operation. The configured service account
    could have lesser privileges required for creating resources compared to the highly privileged access required for
    the control plane operations.

!!! warning
    Please read this documentation carefully before you enable this feature. Misconfiguration could lead to potential security issues.

## Introduction

Argo CD supports syncing `Application` resources using the same service account used for its control plane operations. This feature enables users to decouple service account used for application sync from the service account used for control plane operations.

By default, application syncs in Argo CD have the same privileges as the Argo CD control plane. As a consequence, in a multi-tenant setup, the Argo CD control plane privileges needs to match the tenant that needs the highest privileges. As an example, if an Argo CD instance has 10 Applications and only one of them requires admin privileges, then the Argo CD control plane must have admin privileges in order to be able to sync that one Application. This provides an opportunity for malicious tenants to gain admin level access. Argo CD provides a multi-tenancy model to restrict what each `Application` is authorized to do using `AppProjects`, however it is not secure enough and if Argo CD is compromised, attackers will easily gain `cluster-admin` access to the cluster.

Some manual steps will need to be performed by the Argo CD administrator in order to enable this feature, as it is disabled by default.

!!! note
    This feature is considered alpha as of now. Some of the implementation details may change over the course of time until it is promoted to a stable status. We will be happy if early adopters use this feature and provide us with bug reports and feedback.

### What is Impersonation

Impersonation is a feature in Kubernetes and enabled in the `kubectl` CLI client, using which, a user can act as another user through impersonation headers. For example, an admin could use this feature to debug an authorization policy by temporarily impersonating another user and seeing if a request was denied.

Impersonation requests first authenticate as the requesting user, then switch to the impersonated user info.

## Prerequisites

In a multi-team/multi-tenant environment, a team/tenant is typically granted access to a target namespace to self-manage their kubernetes resources in a declarative way.
A typical tenant onboarding process looks like below:
1. The platform admin creates a tenant namespace and the service account to be used for creating the resources is also created in the same tenant namespace.
2. The platform admin creates one or more Role(s) to manage kubernetes resources in the tenant namespace
3. The platform admin creates one or more RoleBinding(s) to map the service account to the role(s) created in the previous steps.
4. The platform admin can choose to use either the [apps-in-any-namespace](./app-any-namespace.md) feature or provide access to tenants to create applications in the ArgoCD control plane namespace.
5. If the platform admin chooses apps-in-any-namespace feature, tenants can self-service their Argo applications in their respective tenant namespaces and no additional access needs to be provided for the control plane namespace.

## Implementation details

### Overview

In order for an application to use a different service account for the application sync operation, the following steps needs to be performed:

1. The impersonation feature flag should be enabled. Please refer the steps provided in [Enable application sync with impersonation feature](#enable-application-sync-with-impersonation-feature)

2. The `AppProject` referenced by the `.spec.project` field of the `Application` must have the `DestinationServiceAccounts` mapping the destination server and namespace to a service account to be used for the sync operation. Please refer the steps provided in [Configuring destination service accounts](#configuring-destination-service-accounts)

### Enable application sync with impersonation feature

In order to enable this feature, the Argo CD administrator must reconfigure the `application.sync.impersonation.enabled` settings in the `argocd-cm` ConfigMap as below:

```yaml
data:
  application.sync.impersonation.enabled: "true"
```

### Disable application sync with impersonation feature

In order to disable this feature, the Argo CD administrator must reconfigure the `application.sync.impersonation.enabled` settings in the `argocd-cm` ConfigMap as below:

```yaml
data:
  application.sync.impersonation.enabled: "false"
```

!!! note
    This feature is disabled by default.

!!! note
    This feature can be enabled/disabled only at the system level and once enabled/disabled it is applicable to all Applications managed by ArgoCD.

## Configuring destination service accounts

Destination service accounts can be added to the `AppProject` under `.spec.destinationServiceAccounts`. Specify the target destination `server` and `namespace` and provide the service account to be used for the sync operation using `defaultServiceAccount` field. Applications that refer this `AppProject` will use the corresponding service account configured for its destination.

During the application sync operation, the controller loops through the available `destinationServiceAccounts` in the mapped `AppProject` and tries to find a matching candidate. If there are multiple matches for a destination server and namespace combination, then the first valid match will be considered. If there are no matches, then an error is reported during the sync operation. In order to avoid such sync errors, it is highly recommended that a valid service account may be configured as a catch-all configuration, for all target destinations and kept in lowest order of priority.

It is possible to specify service accounts along with its namespace. eg: `tenant1-ns:guestbook-deployer`. If no namespace is provided for the service account, then the Application's `spec.destination.namespace` will be used. If no namespace is provided for the service account and the optional `spec.destination.namespace` field is also not provided in the `Application`, then the Application's namespace will be used.

`DestinationServiceAccounts` associated to a `AppProject` can be created and managed, either declaratively or through the Argo CD API (e.g. using the CLI, the web UI, the REST API, etc).

### Using declarative yaml

For declaratively configuring destination service accounts, create an yaml file for the `AppProject` as below and apply the changes using `kubectl apply` command.

```yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
  namespace: argocd
spec:
  description: Example Project
  # Allow manifests to deploy from any Git repos
  sourceRepos:
    - '*'
  destinations:
    - '*'
  destinationServiceAccounts:
    - server: https://kubernetes.default.svc
      namespace: guestbook
      defaultServiceAccount: guestbook-deployer
    - server: https://kubernetes.default.svc
      namespace: guestbook-dev
      defaultServiceAccount: guestbook-dev-deployer
    - server: https://kubernetes.default.svc
      namespace: guestbook-stage
      defaultServiceAccount: guestbook-stage-deployer
    - server: https://kubernetes.default.svc # catch-all configuration
      namespace: '*'
      defaultServiceAccount: default
```

### Using the CLI

Destination service accounts can be added to an `AppProject` using the ArgoCD CLI.

For example, to add a destination service account for `in-cluster` and `guestbook` namespace, you can use the following CLI command:

```shell
argocd proj add-destination-service-account my-project https://kubernetes.default.svc guestbook guestbook-sa
```

Likewise, to remove the destination service account from an `AppProject`, you can use the following CLI command:

```shell
argocd proj remove-destination-service-account my-project https://kubernetes.default.svc guestbook
```

### Using the UI

Similar to the CLI, you can add destination service account when creating or updating an `AppProject` from the UI

Application Sync using impersonation      warning  Alpha Feature  Since 2 13 0       This is an experimental   alpha quality  https   github com argoproj argoproj blob main community feature status md alpha       feature that allows you to control the service account used for the sync operation  The configured service account      could have lesser privileges required for creating resources compared to the highly privileged access required for      the control plane operations       warning     Please read this documentation carefully before you enable this feature  Misconfiguration could lead to potential security issues      Introduction  Argo CD supports syncing  Application  resources using the same service account used for its control plane operations  This feature enables users to decouple service account used for application sync from the service account used for control plane operations   By default  application syncs in Argo CD have the same privileges as the Argo CD control plane  As a consequence  in a multi tenant setup  the Argo CD control plane privileges needs to match the tenant that needs the highest privileges  As an example  if an Argo CD instance has 10 Applications and only one of them requires admin privileges  then the Argo CD control plane must have admin privileges in order to be able to sync that one Application  This provides an opportunity for malicious tenants to gain admin level access  Argo CD provides a multi tenancy model to restrict what each  Application  is authorized to do using  AppProjects   however it is not secure enough and if Argo CD is compromised  attackers will easily gain  cluster admin  access to the cluster   Some manual steps will need to be performed by the Argo CD administrator in order to enable this feature  as it is disabled by default       note     This feature is considered alpha as of now  Some of the implementation details may change over the course of time until it is promoted to a stable status  We will be happy if early adopters use this feature and provide us with bug reports and feedback       What is Impersonation  Impersonation is a feature in Kubernetes and enabled in the  kubectl  CLI client  using which  a user can act as another user through impersonation headers  For example  an admin could use this feature to debug an authorization policy by temporarily impersonating another user and seeing if a request was denied   Impersonation requests first authenticate as the requesting user  then switch to the impersonated user info      Prerequisites  In a multi team multi tenant environment  a team tenant is typically granted access to a target namespace to self manage their kubernetes resources in a declarative way  A typical tenant onboarding process looks like below  1  The platform admin creates a tenant namespace and the service account to be used for creating the resources is also created in the same tenant namespace  2  The platform admin creates one or more Role s  to manage kubernetes resources in the tenant namespace 3  The platform admin creates one or more RoleBinding s  to map the service account to the role s  created in the previous steps  4  The platform admin can choose to use either the  apps in any namespace    app any namespace md  feature or provide access to tenants to create applications in the ArgoCD control plane namespace  5  If the platform admin chooses apps in any namespace feature  tenants can self service their Argo applications in their respective tenant namespaces and no additional access needs to be provided for the control plane namespace      Implementation details      Overview  In order for an application to use a different service account for the application sync operation  the following steps needs to be performed   1  The impersonation feature flag should be enabled  Please refer the steps provided in  Enable application sync with impersonation feature   enable application sync with impersonation feature   2  The  AppProject  referenced by the   spec project  field of the  Application  must have the  DestinationServiceAccounts  mapping the destination server and namespace to a service account to be used for the sync operation  Please refer the steps provided in  Configuring destination service accounts   configuring destination service accounts        Enable application sync with impersonation feature  In order to enable this feature  the Argo CD administrator must reconfigure the  application sync impersonation enabled  settings in the  argocd cm  ConfigMap as below      yaml data    application sync impersonation enabled   true           Disable application sync with impersonation feature  In order to disable this feature  the Argo CD administrator must reconfigure the  application sync impersonation enabled  settings in the  argocd cm  ConfigMap as below      yaml data    application sync impersonation enabled   false           note     This feature is disabled by default       note     This feature can be enabled disabled only at the system level and once enabled disabled it is applicable to all Applications managed by ArgoCD      Configuring destination service accounts  Destination service accounts can be added to the  AppProject  under   spec destinationServiceAccounts   Specify the target destination  server  and  namespace  and provide the service account to be used for the sync operation using  defaultServiceAccount  field  Applications that refer this  AppProject  will use the corresponding service account configured for its destination   During the application sync operation  the controller loops through the available  destinationServiceAccounts  in the mapped  AppProject  and tries to find a matching candidate  If there are multiple matches for a destination server and namespace combination  then the first valid match will be considered  If there are no matches  then an error is reported during the sync operation  In order to avoid such sync errors  it is highly recommended that a valid service account may be configured as a catch all configuration  for all target destinations and kept in lowest order of priority   It is possible to specify service accounts along with its namespace  eg   tenant1 ns guestbook deployer   If no namespace is provided for the service account  then the Application s  spec destination namespace  will be used  If no namespace is provided for the service account and the optional  spec destination namespace  field is also not provided in the  Application   then the Application s namespace will be used    DestinationServiceAccounts  associated to a  AppProject  can be created and managed  either declaratively or through the Argo CD API  e g  using the CLI  the web UI  the REST API  etc        Using declarative yaml  For declaratively configuring destination service accounts  create an yaml file for the  AppProject  as below and apply the changes using  kubectl apply  command      yaml apiVersion  argoproj io v1alpha1 kind  AppProject metadata    name  my project   namespace  argocd spec    description  Example Project     Allow manifests to deploy from any Git repos   sourceRepos              destinations              destinationServiceAccounts        server  https   kubernetes default svc       namespace  guestbook       defaultServiceAccount  guestbook deployer       server  https   kubernetes default svc       namespace  guestbook dev       defaultServiceAccount  guestbook dev deployer       server  https   kubernetes default svc       namespace  guestbook stage       defaultServiceAccount  guestbook stage deployer       server  https   kubernetes default svc   catch all configuration       namespace            defaultServiceAccount  default          Using the CLI  Destination service accounts can be added to an  AppProject  using the ArgoCD CLI   For example  to add a destination service account for  in cluster  and  guestbook  namespace  you can use the following CLI command      shell argocd proj add destination service account my project https   kubernetes default svc guestbook guestbook sa      Likewise  to remove the destination service account from an  AppProject   you can use the following CLI command      shell argocd proj remove destination service account my project https   kubernetes default svc guestbook          Using the UI  Similar to the CLI  you can add destination service account when creating or updating an  AppProject  from the UI


argocd user management system and has only one built in user The user is a superuser and 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 it has unrestricted access to the system RBAC requires or The RBAC feature enables restrictions of access to Argo CD resources Argo CD does not have its own The global RBAC config map see RBAC Configuration There are two main components where RBAC configuration can be defined

Answer:
# RBAC Configuration

The RBAC feature enables restrictions of access to Argo CD resources. Argo CD does not have its own
user management system and has only one built-in user, `admin`. The `admin` user is a superuser and
it has unrestricted access to the system. RBAC requires [SSO configuration](user-management/index.md) or [one or more local users setup](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.

There are two main components where RBAC configuration can be defined:

- The global RBAC config map (see [argo-rbac-cm.yaml](argocd-rbac-cm-yaml.md))
- The [AppProject's roles](../user-guide/projects.md#project-roles)

## 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.enabled` field in `argocd-cm` (see [argocd-cm.yaml](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>`: The entity to whom the role will be assigned. It can be a local user or a user authenticated with SSO.
  When SSO is used, the `user` will be based on the `sub` claims, while the group is one of the values returned by the `scopes` configuration.
- `<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>`: Whether this policy should grant or restrict the operation on the target object. One of `allow` or `deny`.

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](../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-user` access to get any applications,
but only be able to see logs in `my-app` application part of the `example-project` project.

```csv
p, example-user, applications, get, *, allow
p, example-user, logs, get, example-project/my-app, allow
```

#### Application in Any Namespaces

When [application in any namespace](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`.

```csv
p, example-user, applications, get, */app-namespace/*, allow
p, example-user, logs, get, example-project/app-namespace/my-app, allow
```

### The `applications` resource

The `applications` resource is an [Application-Specific Policy](#application-specific-policy).

#### Fine-grained Permissions for `update`/`delete` action

The `update` and `delete` actions, 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 `update` or `delete` on 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-user` to only delete Pods in the `prod-app` Application, the policy could be:

```csv
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow
```

!!!warning "Understand glob pattern behavior"

    Argo CD RBAC does not use `/` as a separator when evaluating glob patterns. So the pattern `delete/*/kind/*`
    will match `delete/<group>/kind/<namespace>/<name>` but also `delete/<group>/<kind>/kind/<name>`.

    The fact that both of these match will generally not be a problem, because resource kinds generally contain capital
    letters, and namespaces cannot contain capital letters. However, it is possible for a resource kind to be lowercase.
    So it is better to just always include all the parts of the resource in the pattern (in other words, always use four
    slashes).

If we want to grant access to the user to update all resources of an application, but not the application itself:

```csv
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:

```csv
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 `action` action

The `action` action 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](resource_actions.md#custom-resource-actions) defined by you.

See the [resource actions documentation](resource_actions.md#built-in-actions) for a list of built-in actions.

The `<action>` has the `action/<group>/<kind>/<action-name>` format.

For example, a resource customization path `resource_customizations/extensions/DaemonSet/actions/restart/action.lua`
corresponds to the `action` path `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-off` action on a Pod:

```csv
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:

```csv
p, example-user, applications, action/*, default/*, allow
```

#### The `override` action

When granted along with the `sync` action, 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 `applicationsets` resource

The `applicationsets` resource is an [Application-Specific policy](#application-specific-policy).

[ApplicationSets](applicationset/index.md) provide a declarative way to automatically create/update/delete Applications.

Allowing the `create` action 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: `)
    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-group` user will be unable to create an ApplicationSet capable of creating Applications
outside the `dev-project` project.

```csv
p, dev-group, applicationsets, *, dev-project/*, allow
```

### The `logs` resource

The `logs` resource is an [Application-Specific Policy](#application-specific-policy).

When granted with the `get` action, 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 `exec` resource

The `exec` resource is an [Application-Specific Policy](#application-specific-policy).

When granted with the `create` action, this policy allows a user to `exec` into Pods of an application via
the Argo CD UI. The functionality is similar to `kubectl exec`.

See [Web-based Terminal](web_based_terminal.md) for more info.

### The `extensions` resource

With the `extensions` resource, it is possible to configure permissions to invoke [proxy extensions](../developer-guide/extensions/proxy-extensions.md).
The `extensions` RBAC validation works in conjunction with the `applications` resource.
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-user` to invoke the `httpbin` extensions in all
applications under the `default` project.

```csv
p, example-user, applications, get, default/*, allow
p, example-user, extensions, invoke, httpbin, allow
```

### The `deny` effect

When `deny` is used as an effect in a policy, it will be effective if the policy matches.
Even if more specific policies with the `allow` effect match as well, the `deny` will 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`: based on the [`glob` package](https://pkg.go.dev/github.com/gobwas/glob).
- `regex`: based on the [`regexp` package](https://pkg.go.dev/regexp).

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 `deny` effect matches.
After all policies are evaluated, if there was at least one `allow` effect and no `deny`, access will be granted.

### Glob matching

When `glob` is 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-user` executes the `extensions/DaemonSet/test` action, the following `glob` matches will happen:

1. The current user `example-user` matches the token `example-user`.
2. The value `applications` matches the token `applications`.
3. The value `action/extensions/DaemonSet/test` matches `action/extensions/*`. Note that `/` is not treated as a separator and the use of `**` is not necessary.
4. The value `default/my-app` matches `default/*`.

## Using SSO Users/Groups

The `scopes` field controls which OIDC scopes to examine during RBAC enforcement (in addition to `sub` scope).
If omitted, it defaults to `'[groups]'`. The scope value can be a string, or a list of strings.

For more information on `scopes` please review the [User Management Documentation](user-management/index.md).

The following example shows targeting `email` as well as `groups` from your OIDC provider.

```yaml
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.

```yaml
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](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.

```yaml
p, my-local-user, applications, sync, my-project/*, allow
```

This example shows how to assign a role to a local user.

```yaml
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-cm` configmap 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.csv` and `policy.B.csv`,
it will first concatenate `policy.A.csv` and 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.

```yaml
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 rbac` command](../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 validate` command](../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 can` command](../user-guide/commands/argocd_admin_settings_rbac_can.md).

RBAC Configuration  The RBAC feature enables restrictions of access to Argo CD resources  Argo CD does not have its own user management system and has only one built in user   admin   The  admin  user is a superuser and it has unrestricted access to the system  RBAC requires  SSO configuration  user management index md  or  one or more local users setup  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   There are two main components where RBAC configuration can be defined     The global RBAC config map  see  argo rbac cm yaml  argocd rbac cm yaml md     The  AppProject s roles     user guide projects md project roles      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 enabled  field in  argocd cm   see  argocd cm yaml  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    The entity to whom the role will be assigned  It can be a local user or a user authenticated with SSO    When SSO is used  the  user  will be based on the  sub  claims  while the group is one of the values returned by the  scopes  configuration      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    Whether this policy should grant or restrict the operation on the target object  One of  allow  or  deny    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     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 user  access to get any applications  but only be able to see logs in  my app  application part of the  example project  project      csv p  example user  applications  get     allow p  example user  logs  get  example project my app  allow           Application in Any Namespaces  When  application in any namespace  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       csv p  example user  applications  get    app namespace    allow p  example user  logs  get  example project app namespace my app  allow          The  applications  resource  The  applications  resource is an  Application Specific Policy   application specific policy         Fine grained Permissions for  update   delete  action  The  update  and  delete  actions  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  update  or  delete  on 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 user  to only delete Pods in the  prod app  Application  the policy could be      csv p  example user  applications  delete   Pod      default prod app  allow         warning  Understand glob pattern behavior       Argo CD RBAC does not use     as a separator when evaluating glob patterns  So the pattern  delete   kind        will match  delete  group  kind  namespace   name   but also  delete  group   kind  kind  name         The fact that both of these match will generally not be a problem  because resource kinds generally contain capital      letters  and namespaces cannot contain capital letters  However  it is possible for a resource kind to be lowercase       So it is better to just always include all the parts of the resource in the pattern  in other words  always use four      slashes    If we want to grant access to the user to update all resources of an application  but not the application itself      csv 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      csv 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  action  action  The  action  action 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  resource actions md custom resource actions  defined by you   See the  resource actions documentation  resource actions md built in actions  for a list of built in actions   The   action   has the  action  group   kind   action name   format   For example  a resource customization path  resource customizations extensions DaemonSet actions restart action lua  corresponds to the  action  path  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 off  action on a Pod      csv 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      csv p  example user  applications  action    default    allow           The  override  action  When granted along with the  sync  action  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  applicationsets  resource  The  applicationsets  resource is an  Application Specific policy   application specific policy     ApplicationSets  applicationset index md  provide a declarative way to automatically create update delete Applications   Allowing the  create  action 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         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 group  user will be unable to create an ApplicationSet capable of creating Applications outside the  dev project  project      csv p  dev group  applicationsets     dev project    allow          The  logs  resource  The  logs  resource is an  Application Specific Policy   application specific policy    When granted with the  get  action  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  exec  resource  The  exec  resource is an  Application Specific Policy   application specific policy    When granted with the  create  action  this policy allows a user to  exec  into Pods of an application via the Argo CD UI  The functionality is similar to  kubectl exec    See  Web based Terminal  web based terminal md  for more info       The  extensions  resource  With the  extensions  resource  it is possible to configure permissions to invoke  proxy extensions     developer guide extensions proxy extensions md   The  extensions  RBAC validation works in conjunction with the  applications  resource  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 user  to invoke the  httpbin  extensions in all applications under the  default  project      csv p  example user  applications  get  default    allow p  example user  extensions  invoke  httpbin  allow          The  deny  effect  When  deny  is used as an effect in a policy  it will be effective if the policy matches  Even if more specific policies with the  allow  effect match as well  the  deny  will 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   based on the   glob  package  https   pkg go dev github com gobwas glob      regex   based on the   regexp  package  https   pkg go dev regexp    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  deny  effect matches  After all policies are evaluated  if there was at least one  allow  effect and no  deny   access will be granted       Glob matching  When  glob  is 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 user  executes the  extensions DaemonSet test  action  the following  glob  matches will happen   1  The current user  example user  matches the token  example user   2  The value  applications  matches the token  applications   3  The value  action extensions DaemonSet test  matches  action extensions     Note that     is not treated as a separator and the use of      is not necessary  4  The value  default my app  matches  default         Using SSO Users Groups  The  scopes  field controls which OIDC scopes to examine during RBAC enforcement  in addition to  sub  scope   If omitted  it defaults to    groups     The scope value can be a string  or a list of strings   For more information on  scopes  please review the  User Management Documentation  user management index md    The following example shows targeting  email  as well as  groups  from your OIDC provider      yaml 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      yaml 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  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      yaml p  my local user  applications  sync  my project    allow      This example shows how to assign a role to a local user      yaml 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 cm  configmap 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 csv  and  policy B csv   it will first concatenate  policy A csv  and 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      yaml 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 rbac  command     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 validate  command     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 can  command     user guide commands argocd admin settings rbac can md


argocd loading a CSS file directly onto the argocd server container Both mechanisms are driven by modifying the argocd cm configMap Argo CD imports the majority of its UI stylesheets from the project Sometimes it may be desired to customize certain components of the UI for branding purposes or to Such custom styling can be applied either by supplying a URL to a remotely hosted CSS file or by help distinguish between multiple instances of Argo CD running in different environments Custom Styles

Answer:
# Custom Styles

Argo CD imports the majority of its UI stylesheets from the [argo-ui](https://github.com/argoproj/argo-ui) project.
Sometimes, it may be desired to customize certain components of the UI for branding purposes or to
help distinguish between multiple instances of Argo CD running in different environments.

Such custom styling can be applied either by supplying a URL to a remotely hosted CSS file, or by
loading a CSS file directly onto the argocd-server container.  Both mechanisms are driven by modifying
the argocd-cm configMap.

## Adding Styles Via Remote URL

The first method simply requires the addition of the remote URL to the argocd-cm configMap:

### argocd-cm
```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: argocd-cm
data:
  ui.cssurl: "https://www.example.com/my-styles.css"
```

## Adding Styles Via Volume Mounts

The second method requires mounting the CSS file directly onto the argocd-server container and then
providing the argocd-cm with the properly configured path to that file.  In the following example,
the CSS file is actually defined inside of a separate configMap (the same effect could be achieved
by generating or downloading a CSS file in an initContainer):

### argocd-cm
```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: argocd-cm
data:
  ui.cssurl: "./custom/my-styles.css"
```

Note that the `cssurl` should be specified relative to the "/shared/app" directory;
not as an absolute path.

### argocd-styles-cm
```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: argocd-styles-cm
data:
  my-styles.css: |
    .sidebar {
      background: linear-gradient(to bottom, #999, #777, #333, #222, #111);
    }
```

### argocd-server
```yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-server
  ...
spec:
  template:
    ...
    spec:
      containers:
      - command:
        ...
        volumeMounts:
        ...
        - mountPath: /shared/app/custom
          name: styles
      ...
      volumes:
      ...
      - configMap:
          name: argocd-styles-cm
        name: styles
```

Note that the CSS file should be mounted within a subdirectory of the "/shared/app" directory
(e.g. "/shared/app/custom").  Otherwise, the file will likely fail to be imported by the browser with an
"incorrect MIME type" error. The subdirectory can be changed using `server.staticassets` key of the
[argocd-cmd-params-cm.yaml](./argocd-cmd-params-cm.yaml) ConfigMap.

## Developing Style Overlays
The styles specified in the injected CSS file should be specific to components and classes defined in [argo-ui](https://github.com/argoproj/argo-ui).
It is recommended to test out the styles you wish to apply first by making use of your browser's built-in developer tools.  For a more full-featured
experience, you may wish to build a separate project using the [Argo CD UI dev server](https://webpack.js.org/configuration/dev-server/).

## Banners

Argo CD can optionally display a banner that can be used to notify your users of upcoming maintenance and operational changes. This feature can be enabled by specifying the banner message using the `ui.bannercontent` field in the `argocd-cm` ConfigMap and Argo CD will display this message at the top of every UI page. You can optionally add a link to this message by setting `ui.bannerurl`. You can also make the banner sticky (permanent) by setting `ui.bannerpermanent` to true and change its position to "both" or "bottom" by using `ui.bannerposition: "both"`, allowing the banner to display on both the top and bottom, or `ui.bannerposition: "bottom"` to display it exclusively at the bottom.

### argocd-cm
```yaml
---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: argocd-cm
data:
    ui.bannercontent: "Banner message linked to a URL"
    ui.bannerurl: "www.bannerlink.com"
    ui.bannerpermanent: "true"
    ui.bannerposition: "bottom"
```

![banner with link](../assets/banner.png)

Custom Styles  Argo CD imports the majority of its UI stylesheets from the  argo ui  https   github com argoproj argo ui  project  Sometimes  it may be desired to customize certain components of the UI for branding purposes or to help distinguish between multiple instances of Argo CD running in different environments   Such custom styling can be applied either by supplying a URL to a remotely hosted CSS file  or by  loading a CSS file directly onto the argocd server container   Both mechanisms are driven by modifying the argocd cm configMap      Adding Styles Via Remote URL  The first method simply requires the addition of the remote URL to the argocd cm configMap       argocd cm    yaml     apiVersion  v1 kind  ConfigMap metadata          name  argocd cm data    ui cssurl   https   www example com my styles css          Adding Styles Via Volume Mounts  The second method requires mounting the CSS file directly onto the argocd server container and then providing the argocd cm with the properly configured path to that file   In the following example  the CSS file is actually defined inside of a separate configMap  the same effect could be achieved by generating or downloading a CSS file in an initContainer        argocd cm    yaml     apiVersion  v1 kind  ConfigMap metadata          name  argocd cm data    ui cssurl     custom my styles css       Note that the  cssurl  should be specified relative to the   shared app  directory   not as an absolute path       argocd styles cm    yaml     apiVersion  v1 kind  ConfigMap metadata          name  argocd styles cm data    my styles css         sidebar         background  linear gradient to bottom   999   777   333   222   111                  argocd server    yaml     apiVersion  apps v1 kind  Deployment metadata    name  argocd server       spec    template              spec        containers          command                      volumeMounts                        mountPath   shared app custom           name  styles                 volumes                    configMap            name  argocd styles cm         name  styles      Note that the CSS file should be mounted within a subdirectory of the   shared app  directory  e g    shared app custom     Otherwise  the file will likely fail to be imported by the browser with an  incorrect MIME type  error  The subdirectory can be changed using  server staticassets  key of the  argocd cmd params cm yaml    argocd cmd params cm yaml  ConfigMap      Developing Style Overlays The styles specified in the injected CSS file should be specific to components and classes defined in  argo ui  https   github com argoproj argo ui   It is recommended to test out the styles you wish to apply first by making use of your browser s built in developer tools   For a more full featured experience  you may wish to build a separate project using the  Argo CD UI dev server  https   webpack js org configuration dev server        Banners  Argo CD can optionally display a banner that can be used to notify your users of upcoming maintenance and operational changes  This feature can be enabled by specifying the banner message using the  ui bannercontent  field in the  argocd cm  ConfigMap and Argo CD will display this message at the top of every UI page  You can optionally add a link to this message by setting  ui bannerurl   You can also make the banner sticky  permanent  by setting  ui bannerpermanent  to true and change its position to  both  or  bottom  by using  ui bannerposition   both    allowing the banner to display on both the top and bottom  or  ui bannerposition   bottom   to display it exclusively at the bottom       argocd cm    yaml     apiVersion  v1 kind  ConfigMap metadata          name  argocd cm data      ui bannercontent   Banner message linked to a URL      ui bannerurl   www bannerlink com      ui bannerpermanent   true      ui bannerposition   bottom         banner with link     assets banner png