A fresh install has one local user, admin, who can do everything. On a shared platform you want personal logins through SSO and least-privilege roles.
Single sign-on
Argo CD can sign users in through Dex (bundled: GitHub, GitLab, LDAP, SAML, Microsoft) or directly through any OIDC provider (Microsoft Entra ID, Okta, Keycloak, Google). Settings live in argocd-cm:
apiVersion: v1
kind: ConfigMap
metadata: { name: argocd-cm, namespace: argocd }
data:
url: https://argocd.example.com
admin.enabled: "false" # after SSO works
oidc.config: |
name: Company SSO
issuer: https://login.example.com/
clientID: argocd
clientSecret: $oidc.clientSecret # read from Secret argocd-secret, never inline
requestedScopes: [openid, profile, email, groups]
The groups in the user's token (for example shop-devs) are what RBAC maps to roles.
RBAC policies
RBAC lives in argocd-rbac-cm. Each p line grants subject, resource, action, object, effect; each g line puts a group (or user) into a role.
apiVersion: v1
kind: ConfigMap
metadata: { name: argocd-rbac-cm, namespace: argocd }
data:
policy.default: role:readonly
scopes: '[groups]'
policy.csv: |
p, role:shop-dev, applications, get, shop/*, allow
p, role:shop-dev, applications, sync, shop/*-dev, allow
p, role:shop-dev, logs, get, shop/*, allow
p, role:shop-lead, applications, *, shop/*, allow
g, shop-devs, role:shop-dev
g, shop-leads, role:shop-lead
g, platform-admins, role:admin
| Part | Values |
|---|---|
| Resources | applications, applicationsets, projects, clusters, repositories, accounts, certificates, logs, exec |
| Actions | get, create, update, delete, sync, override, action/<group/kind/action>, * |
| Object | <project>/<application> for applications, wildcards allowed |
| Built-in roles | role:readonly, role:admin |
policy.default: role:readonlygives every logged-in user read access; set it to''if even that is too much.- Deny wins: a
denyline beats anyallow. exec(a terminal into Pods from the UI) is off by default — keep it that way unless you need it.
Test before you apply
argocd admin settings rbac validate --policy-file policy.csv
argocd admin settings rbac can role:shop-dev sync applications 'shop/shop-api-prod' --policy-file policy.csv # No
argocd admin settings rbac can role:shop-dev sync applications 'shop/shop-api-dev' --policy-file policy.csv # Yes
argocd account get-user-info
Tokens for automation
CI should not use a person's login. Use a project role token (argocd proj role create-token shop ci-sync) or a local account with apiKey capability, limited to the one action it needs, and store the token in the CI secret store.
Checklist: SSO on · admin.enabled: "false" · argocd-initial-admin-secret deleted · groups mapped to roles · policy.default deliberate · CI uses scoped tokens.