ArgoCD
policy.csv
permissions
user roles
access control

What is 'p' and 'g' in ArgoCD policy.csv?

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

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:

csv
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.

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

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

Role assignment happens in g lines:

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

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

Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

Interview Questions practice on Codemia

Over 8,000 real interview questions from top companies, searchable by company and role.

Browse interview questions

All Rights Reserved.