RBAC Policy Configuration

Configure role-based access control policies for Argo CD using Casbin

Overview

Argo CD’s RBAC feature restricts access to resources using policy definitions based on Casbin. RBAC requires SSO configuration or local users to be effective.

Argo CD has only one built-in user (admin) which is a superuser with unrestricted access. Configure additional users or SSO before implementing RBAC.

RBAC ConfigMap

RBAC policies are defined in the argocd-rbac-cm ConfigMap:

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: |
    # Grant team-alpha the ability to sync apps in my-project
    p, my-org:team-alpha, applications, sync, my-project/*, allow
    # Grant team-beta admin privileges
    g, my-org:team-beta, role:admin
  
  policy.default: role:readonly
  scopes: '[groups]'
  policy.matchMode: 'glob'

Built-in Roles

Argo CD provides two pre-defined roles:

• role:readonly: Read-only access to all resources
• role:admin: Unrestricted access to all resources

All authenticated users receive at least the permissions granted by policy.default. This access cannot be blocked by a deny rule.

Policy Syntax

Group Assignment

Assign users or groups to roles:

g, <user/group>, <role>

Example:

g, my-org:team-beta, role:admin
g, [e-mail], role:admin
g, bob, role:readonly

Policy Rules

Define permissions for resources:

p, <role/user/group>, <resource>, <action>, <object>, <effect>

Example:

p, my-org:team-alpha, applications, sync, my-project/*, allow
p, role:dev, applications, get, */*, allow
p, role:dev, applications, delete, default/prod-app, deny

Resource Actions

Resource	get	create	update	delete	sync	action	override	invoke
applications	✅	✅	✅	✅	✅	✅	✅	❌
applicationsets	✅	✅	✅	✅	❌	❌	❌	❌
clusters	✅	✅	✅	✅	❌	❌	❌	❌
projects	✅	✅	✅	✅	❌	❌	❌	❌
repositories	✅	✅	✅	✅	❌	❌	❌	❌
accounts	✅	❌	✅	❌	❌	❌	❌	❌
certificates	✅	✅	❌	✅	❌	❌	❌	❌
gpgkeys	✅	✅	❌	✅	❌	❌	❌	❌
logs	✅	❌	❌	❌	❌	❌	❌	❌
exec	❌	✅	❌	❌	❌	❌	❌	❌
extensions	❌	❌	❌	❌	❌	❌	❌	✅

Application Policies

Application-specific policies use the format <project>/<app-name> for the object:

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

Fine-Grained Resource Permissions

Grant permissions for specific resource types within an application:

# Allow deleting only Pods in prod-app
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

# Allow updating all resources except the application itself
p, example-user, applications, update/*, default/prod-app, allow

# Explicitly deny deleting the application
p, example-user, applications, delete, default/prod-app, deny

Argo CD RBAC doesn’t use / as a separator in glob patterns. Always use four slashes for resource-specific permissions to avoid unexpected matches.

Action Permissions

Control access to custom resource actions:

# Allow maintenance-off action on Pods
p, example-user, applications, action//Pod/maintenance-off, default/*, allow

# Allow all actions on DaemonSets
p, example-user, applications, action/extensions/DaemonSet/*, default/*, allow

# Allow any action
p, example-user, applications, action/*, default/*, allow

Override Permissions

The override action allows syncing arbitrary manifests or different revisions:

p, example-user, applications, override, default/*, allow

The override privilege allows users to completely change or delete deployed resources. It cannot be used when auto-sync is enabled.

ApplicationSet Policies

Control ApplicationSet creation with project-scoped permissions:

# Allow creating ApplicationSets that create apps in dev-project
p, dev-group, applicationsets, *, dev-project/*, allow

ApplicationSets cannot be created with templated project fields via API/CLI, making project restrictions via RBAC safe.

Logs and Exec Policies

Log Access

p, example-user, logs, get, my-project/my-app, allow

Exec Access

p, example-user, exec, create, my-project/my-app, allow

Exec functionality must be enabled separately in the Argo CD configuration.

Extensions Policies

Control access to proxy extensions:

# User needs read permission on the application
p, example-user, applications, get, default/*, allow
# And explicit extension invoke permission
p, example-user, extensions, invoke, httpbin, allow

Using SSO Groups

Configure which OIDC scopes to examine for RBAC:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    p, my-org:team-alpha, applications, sync, my-project/*, allow
    g, my-org:team-beta, role:admin
    g, [e-mail], role:admin
    g, admin, role:admin
    g, role:admin, role:readonly
  
  policy.default: role:readonly
  scopes: '[groups, email]'

The scopes field controls which OIDC scopes are examined (defaults to [groups]).

Local Users

Assign policies directly to local users:

# Direct policy assignment
p, my-local-user, applications, sync, my-project/*, allow

# Role assignment
g, my-local-user, role:admin

If SSO is enabled, any SSO user with a scope matching a local username will receive the same role assignments. To avoid ambiguity, assign policies directly to local users instead of using role assignments.

Policy Composition

Compose policies using multiple ConfigMap entries:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    p, role:tester, applications, get, *, allow
  
  policy.overlay.csv: |
    p, role:tester, applications, *, */*, allow
    p, role:tester, projects, *, *, allow
    g, my-org:team-qa, role:tester
  
  policy.default: role:readonly

Argo CD concatenates all policy.*.csv entries in alphabetical order.

Match Modes

Configure pattern matching behavior:

data:
  policy.matchMode: 'glob'  # or 'regex'

• glob: Uses glob patterns (default)
• regex: Uses regular expressions

Glob Matching

Glob treats policy tokens as single terms without separators:

p, example-user, applications, action/extensions/*, default/*, allow

This matches action/extensions/DaemonSet/test because / is not treated as a separator.

Deny Rules

Deny rules take precedence over allow rules:

# Deny takes precedence even with more specific allow rules
p, example-user, applications, delete, default/prod-app, deny
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow

The user will be denied delete access to the application.

Default Policy

Set the default role for authenticated users:

data:
  policy.default: role:readonly

Anonymous Access

Enable anonymous access with restricted permissions:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
  namespace: argocd
data:
  users.anonymous.enabled: "true"

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:unauthenticated

Validation and Testing

Validate and test RBAC policies using the CLI:

Validate Policy

argocd admin settings rbac validate --policy-file policy.csv

Test Access

argocd admin settings rbac can alice get applications 'default/*'

Example Policies

Development Team

p, role:developer, applications, get, dev-project/*, allow
p, role:developer, applications, sync, dev-project/*, allow
p, role:developer, logs, get, dev-project/*, allow
g, [e-mail], role:developer

Operations Team

p, role:ops, applications, *, */*, allow
p, role:ops, clusters, *, *, allow
p, role:ops, repositories, *, *, allow
g, [e-mail], role:ops

CI/CD Pipeline

p, role:ci, applications, get, */*, allow
p, role:ci, applications, sync, */*, allow
g, ci-service-account, role:ci

Best Practices

Principle of Least Privilege

Grant only the minimum permissions required. Start with role:readonly and add specific permissions as needed.

Use Projects

Leverage AppProjects to group applications and simplify RBAC policies.

SSO Integration

Use SSO groups for team-based access control rather than managing individual local users.

Test Policies

Use argocd admin settings rbac commands to validate and test policies before deployment.