Local Users and RBAC: Give One Teammate One Project
Step 2: Grant Rights
argocd-rbac-cm accepts two kinds of lines, and that is the whole syntax:
- A
pline is a permission. It says a subject may (or may not) do something. - A
gline is a group mapping. It says a subject belongs to a role and inherits that role's permissions.
You grant rights with p lines, with g lines, or with both.
Here is the skeleton of the ConfigMap we will apply to grant permissions. The ... means "and so on": you can have as many p and g lines as you need.
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
namespace: , , ,
g, ,
...
The p Line
A p line has six comma-separated fields:
p, , , , Below is what each field means and the possible values it can take.
| Field | Meaning | Possible values |
|---|---|---|
subject | Who the rule applies to | A local user (alice), an SSO user or group, or a role (role:readonly) |
resource | What kind of thing | applications, clusters, projects, repositories, accounts, logs, exec, and a few more |
action | The operation | get, create, update, delete, sync, plus special ones like action and override. Not every action is valid on every resource |
object | Which specific instances | The format depends on the resource. For applications it is * matches all |
effect | Allow or block | allow or deny. A matching deny always wins over a matching allow |
Which actions are valid depends on the resource. The official documentation lists every resource and the valid actions. The ones you will probably use most often are these:
| Resource | What it controls | Valid actions you care about |
|---|---|---|
applications | The Application objects themselves: viewing, creating, syncing, and deleting deployed apps | get, create, update, delete, sync, plus action and override |
clusters | The external clusters Argo CD deploys to, registered as cluster credentials | get, create, update, delete |
projects | AppProjects, which group apps and set guardrails on what they may deploy | get, create, update, delete |
repositories | The Git and Helm repos Argo CD pulls manifests from, including their credentials | get, create, update, delete |
logs | Viewing a pod's logs in the UI, the equivalent of kubectl logs | get |
exec | Opening a shell into a pod from the UI, the equivalent of kubectl exec (feature not active by default) | create |
You can read p lines as sentences. Let's see some examples.
Assigned to a local user:
p, alice, applications, sync, team-alpha/*, allow
Reads: allow alice to sync any application whose object matches team-alpha/*, meaning every app in the team-alpha project.
The subject does not have to be a user. The same p line works with a role or an SSO group in the subject field.
Assigned to a role:
p, role:team-alpha-dev, applications, get, team-alpha/*, allow
Reads: allow anyone in role:team-alpha-dev to get (view) any application in the team-alpha project.
(i) Nobody has this permission yet. A role only grants something once subjects are attached to it with
glines (g, alice, role:team-alpha-dev). We will see this in the next subsection.
Assigned to an SSO group:
p, my-org:platform-team, repositories, *, *, allow
Reads: allow any member of the SSO group my-org:platform-team to perform every action (*) on every repository (*). The group string must match what your identity provider puts in the token claim.
GitOps the Hard Way, with Argo CD
Build Real GitOps Pipelines From Empty Clusters to Automated DeploysEnroll now to unlock all content and receive all future updates for free.