
NB: For CKA or other Exam Practice/Preparation Questions, send an email to info@tekneed.com
In this snippet, we will quickly learn how to create a local user on Argo CD and assign RBAC permissions to the user
In enterprise Kubernetes/OpenShift environments, Argo CD has become a cornerstone for GitOps-based continuous delivery. While integrating with external identity providers like Azure AD, On-prem/local AD or GitHub OAuth is ideal for large teams, sometimes you just need simple local user access for testing, isolated environments, or bootstrapping. Hence, this posts will walk you through how to create a Local user on Argo CD and assign them the right permissions using Argo CD’s RBAC (Role-Based Access Control) system
Prerequisites
Before we start, ensure:
- Argo CD is deployed and accessible (via
kubectl
and UI/API). - You have admin access (e.g.,
admin
user login). kubectl
andargocd
CLI are installed.
Step By Step Guide of How To Create a Local User on Argo CD
We will be creating the user, victor for example. And we will perform the following steps.
1. Enable the Local user in argocd-cm ConfigMap
Local users in Argo CD are declared in the argocd-cm
ConfigMap. You’ll add your user under the accounts.<username>
key
a). Edit the argocd configmap
ansu@mastern-01:~$ kubectl edit configmap argocd-cm -n argocd
Add this under data:
(or update if it already exists):
accounts.victor: login, apiKey

2. Verify that the account has been created.
ansu@mastern-01:~$ argocd account list
NAME ENABLED CAPABILITIES
admin true login
victor true login
3. Define RBAC Policies in argocd-rbac-cm (Assign permissions to the user).
ansu@mastern-01:~$ kubectl edit configmap argocd-rbac-cm -n argocd
Then add this under data:
data:
policy.csv: |
# Application permissions
p, role:creator, applications, create, *, allow
p, role:creator, applications, get, *, allow
p, role:creator, applications, update, *, allow
p, role:creator, applications, delete, *, allow
p, role:creator, applications, sync, *, allow
# Repository read-only access (needed to create apps)
p, role:creator, repositories, get, *, allow
p, role:creator, repositories, list, *, allow
# Map the user to the role
g, victor, role:creator

This gives victor the ability to:
- Create, view, update, delete, and sync applications.
- Also grants read access to repositories, which is essential if the user is to create apps from existing repos
- The
g
line maps the user, victor to thecreator
role. The role defines what actions the user can take
You can restrict by namespace/project later if needed.
Note: One common pitfall is forgetting to grant
repositories, get/list
permissions. Without them, the user won’t be able to see available Git repositories and will fail to create applications.
4. Restart Argo CD Server (Optional)
This reloads the config and RBAC without downtime to running apps.
ansu@mastern-01:~$ kubectl rollout restart deployment argocd-server -n argocd
5. Login to argocd via CLI so you can set the password for the user.
ansu@mastern-01:~$ argocd login 10.10.14.123:30080 --username admin --password yourpassword --insecure
'admin:login' logged in successfully
Context '10.10.14.123:30080' updated
ansu@mastern-01:~$ argocd account update-password --account victor
*** Enter password of currently logged in user (admin):
*** Enter new password for user victor:
*** Confirm new password for user victor:
Password updated
6. You can then login to argocd with the user, victor via the the URL or CLI as the case may be.
with CLI, you can do,
ansu@mastern-01:~$ login 10.10.14.123:30080 --username victor --password <your- password>
Tips on Security
- Avoid using local users in production. Integrate with LDAP, SSO, local AD or OIDC where possible.
- Audit user actions via Argo CD’s API server logs or integrations like Prometheus.
- Rotate passwords periodically and enforce least privilege in RBAC roles.
Conclusion
Creating a local user on Argo CD with properly scoped RBAC roles gives you flexibility in managing small-scale environments, CI/CD pipelines, or bootstrap access. By combining local user creation with clear role definitions, you can safely delegate tasks like application deployment without compromising your GitOps workflow.
Leave a Reply