Introduction

Argo CD uses an RBAC model based on policy lines inside policy.csv. The two prefixes people ask about most are p and g, and they matter because one defines permissions while the other assigns users or groups to roles.

What p Means

p stands for a policy rule. It says what a subject is allowed, or denied, to do on a resource.

In practice, the subject is often a role such as role:dev rather than an individual user. A policy line typically answers four questions:

• who is being described
• what resource type is affected
• what action is allowed
• which object or scope the rule applies to

A simple example looks like this:

p, role:dev, applications, get, my-project/*, allow
p, role:dev, applications, sync, my-project/*, allow
p, role:viewer, applications, get, my-project/*, allow

These lines mean that role:dev can view and sync applications in my-project, while role:viewer can only read them.

The important point is that p lines express permissions directly. If you remove the g lines entirely, the policy rules still exist, but nobody is assigned to them yet.

What g Means

g stands for grouping. It maps a user or external identity group to a role.

g, alice, role:dev
g, bob, role:viewer
g, my-org:platform-team, role:dev

These entries do not grant permissions by themselves. They only connect identities to subjects that already have p rules.

That is the mental model:

• 'p defines capabilities'
• 'g attaches users or groups to those capabilities'

If alice is grouped into role:dev, then alice inherits the permissions from the p rules attached to role:dev.

Read policy.csv as Two Layers

It helps to think of policy.csv as two layers:

1. role design
2. role assignment

Role design happens in p lines:

p, role:ops, applications, get, */*, allow
p, role:ops, applications, sync, production/*, allow

Role assignment happens in g lines:

g, sre-team, role:ops

This separation makes the file easier to maintain. If a new engineer joins the SRE team, you update the identity provider group membership rather than editing every permission rule.

A Practical Example in Argo CD

Here is a small RBAC example that you could place into the Argo CD RBAC config:

1data:
2  policy.csv: |
3    p, role:reader, applications, get, team-a/*, allow
4    p, role:deployer, applications, get, team-a/*, allow
5    p, role:deployer, applications, sync, team-a/*, allow
6    g, jane, role:reader
7    g, release-bot, role:deployer

With that setup:

• 'jane can view applications in team-a'
• 'release-bot can view and sync them'

The distinction between permission rules and assignments stays obvious even as the file grows.

Why This Design Is Useful

The p and g model comes from Casbin-style RBAC semantics, and it scales better than writing one-off rules for every user. Instead of saying "user Jane can sync app X" over and over, you define a reusable role once and map identities into it.

That gives you:

• less duplication
• clearer review of access
• easier auditing
• fewer mistakes when teams change

It also makes it easier to reason about least privilege. You can review roles as policy units instead of hunting through per-user exceptions.

Common Pitfalls

• Mixing up permission rules and assignments. g does not grant access unless matching p rules exist.
• Assigning permissions directly to many individual users instead of stable roles. That becomes hard to audit.
• Making object patterns too broad, such as */*, when the role should only work in one project.
• Forgetting that external SSO group names must match what Argo CD actually receives from the identity provider.
• Reading a denied action as a broken login problem, when the user is authenticated correctly but lacks a matching p rule.

Summary

• In Argo CD policy.csv, p means permission policy and g means grouping.
• 'p lines define what a role or subject can do.'
• 'g lines map users or identity groups to those roles.'
• The usual pattern is to put permissions on roles and assignments on g lines.
• Keeping p and g separate makes RBAC easier to review, scale, and debug.