RBAC Interview Questions & Answers

Q: What is RBAC in ArgoCD?

ArgoCD RBAC controls what authenticated users and groups can do within ArgoCD—viewing, syncing, creating, or deleting Applications, and managing clusters, repos, and projects. It's separate from Kubernetes RBAC (which governs cluster resource access) and is defined in the argocd-rbac-cm ConfigMap using policy rules and roles.

Q: What are the built-in roles in ArgoCD?

ArgoCD ships two built-in roles: role:admin (full access to everything) and role:readonly (view-only). You define custom roles in the RBAC policy for finer control. The policy.default sets the fallback role for users without a specific grant (often readonly or empty to deny).

Q: How is an ArgoCD RBAC policy rule structured?

Policy lines use a CSV-like format: `p, , , , , `. Resources include applications, clusters, repositories, projects, logs, exec. Actions include get, create, update, delete, sync, override. Objects scope by project/app (e.g., proj/app) and support wildcards. `g` lines map users/groups to roles.

Q: How do you scope RBAC to specific projects and applications?

Use the object field as project/application with wildcards, e.g., `team-a/*` grants a role over all apps in the team-a project. Because AppProjects group apps and constrain destinations/sources, scoping RBAC by project gives clean multi-tenant boundaries—each team manages only its project's apps.

Q: How does ArgoCD integrate with SSO for authentication?

ArgoCD supports SSO via OIDC (directly or through its bundled Dex connector for LDAP, SAML, GitHub, etc.). Users log in with their identity provider; group claims from the token are mapped to ArgoCD roles in the RBAC policy via `g, , ` lines, centralizing access control with corporate identity.

Q: How do AppProjects and RBAC work together for multi-tenancy?

AppProjects enforce what can be deployed (allowed repos, destinations, resource kinds) while RBAC enforces who can act on which project's apps. Together they isolate tenants: a team's role is scoped to its project, and the project restricts that team's apps to approved repos, clusters, and namespaces—limiting both authority and blast radius.

Q: How do you grant fine-grained permissions like sync but not delete?

List only the allowed actions in policy lines, omitting others (default deny). For example allow get and sync but not delete or override. Because ArgoCD RBAC is deny-by-default, granting sync without a delete rule means the user can trigger syncs but cannot delete the application.

Q: What is the exec resource in RBAC and why is it sensitive?

The exec resource controls whether a user can open a shell into a running pod via ArgoCD's terminal feature. It's powerful (equivalent to kubectl exec) and can bypass other controls, so it's disabled by default and granted narrowly. Enabling it requires both the feature flag and an explicit RBAC allow.

Q: How do you manage RBAC for API/automation accounts (project roles and tokens)?

Beyond user SSO, ArgoCD supports local accounts and AppProject roles with scoped JWT tokens for automation. A project role defines allowed actions on that project's apps, and you issue a token bound to it for CI to sync apps—least privilege for pipelines without granting a human-level or admin account.

Q: Where is ArgoCD RBAC configured?

RBAC policy lives in the argocd-rbac-cm ConfigMap, with keys policy.csv (the rules), policy.default (fallback role), and scopes (which token claims to use for group mapping). Changes take effect without restart. Managing it declaratively (in Git) keeps access control itself under GitOps.

What is RBAC in ArgoCD?

Beginner

ArgoCD RBAC controls what authenticated users and groups can do within ArgoCD—viewing, syncing, creating, or deleting Applications, and managing clusters, repos, and projects. It's separate from Kubernetes RBAC (which governs cluster resource access) and is defined in the argocd-rbac-cm ConfigMap using policy rules and roles.

# argocd-rbac-cm
data:
  policy.default: role:readonly

Real-world example Developers get a role that can view and sync their team's apps but not delete clusters or edit other teams' apps.

Common follow-ups: How does ArgoCD RBAC differ from Kubernetes RBAC? | Where is it configured?

Applications Multi-cluster RBAC

What are the built-in roles in ArgoCD?

Beginner

ArgoCD ships two built-in roles: role:admin (full access to everything) and role:readonly (view-only). You define custom roles in the RBAC policy for finer control. The policy.default sets the fallback role for users without a specific grant (often readonly or empty to deny).

policy.default: role:readonly

Real-world example Unmapped users default to readonly, while a custom 'team-a' role grants sync rights on team-a apps only.

Common follow-ups: What does role:admin allow? | What is policy.default for?

Applications RBAC Multi-cluster

How is an ArgoCD RBAC policy rule structured?

Intermediate

Policy lines use a CSV-like format: `p, <subject>, <resource>, <action>, <object>, <effect>`. Resources include applications, clusters, repositories, projects, logs, exec. Actions include get, create, update, delete, sync, override. Objects scope by project/app (e.g., proj/app) and support wildcards. `g` lines map users/groups to roles.

p, role:dev, applications, sync, team-a/*, allow
p, role:dev, applications, get, team-a/*, allow
g, team-a-group, role:dev

Real-world example The dev role can get and sync any application in the team-a project, and the SSO group team-a-group is bound to it.

Common follow-ups: What does a 'p' line define? | How do 'g' lines work?

Applications Multi-cluster RBAC

How do you scope RBAC to specific projects and applications?

Intermediate

Use the object field as project/application with wildcards, e.g., `team-a/*` grants a role over all apps in the team-a project. Because AppProjects group apps and constrain destinations/sources, scoping RBAC by project gives clean multi-tenant boundaries—each team manages only its project's apps.

p, role:team-a, applications, *, team-a/*, allow

Real-world example Team A's role has full application actions but only within the team-a project, isolating them from other teams.

Common follow-ups: Why scope RBAC by project? | What does the object field represent?

Applications Multi-cluster RBAC

How does ArgoCD integrate with SSO for authentication?

Intermediate

ArgoCD supports SSO via OIDC (directly or through its bundled Dex connector for LDAP, SAML, GitHub, etc.). Users log in with their identity provider; group claims from the token are mapped to ArgoCD roles in the RBAC policy via `g, <group>, <role>` lines, centralizing access control with corporate identity.

g, "my-org:platform-team", role:admin
g, "my-org:developers", role:dev

Real-world example Engineers log in with corporate SSO, and their IdP group memberships automatically grant the right ArgoCD roles.

Common follow-ups: What is Dex used for? | How are IdP groups mapped to roles?

RBAC Multi-cluster Applications

How do AppProjects and RBAC work together for multi-tenancy?

Advanced

AppProjects enforce what can be deployed (allowed repos, destinations, resource kinds) while RBAC enforces who can act on which project's apps. Together they isolate tenants: a team's role is scoped to its project, and the project restricts that team's apps to approved repos, clusters, and namespaces—limiting both authority and blast radius.

# Project restricts destinations; RBAC restricts who can sync them
p, role:team-a, applications, sync, team-a/*, allow

Real-world example Team A can only sync apps in its project, and that project can only deploy to team-a namespaces on approved clusters.

Common follow-ups: What does a Project restrict vs what does RBAC restrict? | How do they combine for isolation?

Applications Multi-cluster RBAC

How do you grant fine-grained permissions like sync but not delete?

Advanced

List only the allowed actions in policy lines, omitting others (default deny). For example allow get and sync but not delete or override. Because ArgoCD RBAC is deny-by-default, granting sync without a delete rule means the user can trigger syncs but cannot delete the application.

p, role:operator, applications, get, '*/*', allow
p, role:operator, applications, sync, '*/*', allow
# no delete rule -> delete denied

Real-world example On-call operators can sync any app to recover from drift but cannot delete apps, limiting accidental damage.

Common follow-ups: Is ArgoCD RBAC deny-by-default? | How do you allow sync but block delete?

Applications Sync & Health RBAC

What is the exec resource in RBAC and why is it sensitive?

Intermediate

The exec resource controls whether a user can open a shell into a running pod via ArgoCD's terminal feature. It's powerful (equivalent to kubectl exec) and can bypass other controls, so it's disabled by default and granted narrowly. Enabling it requires both the feature flag and an explicit RBAC allow.

p, role:admin, exec, create, '*/*', allow

Real-world example Only senior SREs get exec permission for emergency debugging, and it's off by default for everyone else.

Common follow-ups: Why is exec disabled by default? | What does exec permission allow?

RBAC Applications Multi-cluster

How do you manage RBAC for API/automation accounts (project roles and tokens)?

Advanced

Beyond user SSO, ArgoCD supports local accounts and AppProject roles with scoped JWT tokens for automation. A project role defines allowed actions on that project's apps, and you issue a token bound to it for CI to sync apps—least privilege for pipelines without granting a human-level or admin account.

# AppProject role for CI
roles:
  - name: ci-deployer
    policies:
      - p, proj:team-a:ci-deployer, applications, sync, team-a/*, allow

Real-world example The CI pipeline uses a project-scoped token that can only sync team-a apps, never touching other projects.

Common follow-ups: What is an AppProject role? | Why use scoped tokens for CI?

Applications Multi-cluster RBAC

Where is ArgoCD RBAC configured?

Beginner

RBAC policy lives in the argocd-rbac-cm ConfigMap, with keys policy.csv (the rules), policy.default (fallback role), and scopes (which token claims to use for group mapping). Changes take effect without restart. Managing it declaratively (in Git) keeps access control itself under GitOps.

data:
  policy.default: role:readonly
  policy.csv: |
    g, my-team, role:admin

Real-world example Access control changes go through a PR to the argocd-rbac-cm manifest, so permissions are reviewed and versioned.

Common follow-ups: What keys does argocd-rbac-cm have? | Do RBAC changes need a restart?

RBAC GitOps Principles Applications