Argo CD offers Role Based Access Control (RBAC) to provide the least privilege access to users. Although Argo CD does not have built-in identity access management (user management), it supports integration with 3rd party authentication and authorization providers. The preliminary step to achieve RBAC is to ensure sign-on (SSO) in Argo CD, after which the roles and privileges can be set up. ( Read how to enable SSO in Argo CD using Okta).
Note, by default Argo CD provides only two roles:
- admin: super-admin user for unrestricted access to Argo CD resources and
- readonly: user for viewing of all resources (refer to build-in-policy).
Hence it is highly recommended to set RBAC for production usage. In this article, I will explain all the steps to configure RBAC in Argo CD (assuming user management is already in place).
To enable RBAC, there are three important items to consider- user/groups, Argo CD resources, and action. Argo CD supports 3rd party authentication providers such as LDAP and SAML, where users and groups are defined as per roles. Argo will use the user/groups from the 3rd party providers, and you can specify the action/permissions to various resources against each user/group in the argocd-rbac-cm configmap file.
List of actions and resources in Argo CD for RBAC
The are various resources available in Argo CD for which one has to provide permissions, such as:
- Applications
- Logs
- Accounts
- Projects
- Clusters
- Repositories
- Certificates
- Applicationsets
- Gpgkeys
Similarly, there various kinds of actions users would require permission to perform:
- Get
- Create
- Update
- Delete
- Sync
- Override
Prerequisite
- Argocd installed ( read if you want to install Argo CD using manifest or HELM)
Enabling RBAC with Argo CD internal accounts
Setting up anonymous access
The anonymous access to Argo CD can be enabled using users.anonymous.enabled field in argocd-cm. The anonymous users get role permissions specified in the policy section of argocd-rbac-cm.yaml.
For e.g If you want to provide read-only access, you’ll have to mention policy.default: role:readonly in the yaml file.
Configuring RBAC for SDLC members
Now let us assume you want to create three groups of users- developer, QA, and anonymous. You want to provide developers with the capability to create and delete applications but avoid them from deploying to the clusters. At the same time, members of the QA team should be able to deploy an application or sync it but should not be allowed to create a new application or delete them. And, rest everyone should be able to log in to Argo CD but should be able to view any resources.
In our example, Alice Pepper is a developer, Raj Kota is a QA tester, and Jason J is an anonymous user. For anonymous users, we have used a code name called ‘John’ ( John Wick is my favorite movie).
A tabular representation of the above use case is defined below.
Steps to configure Argo CD RBAC
To implement the following RBAC use-case, we will follow the below steps.
1. Create users in Argo CD by editing argocd-cm. Note, the common concepts of groups (such as developer, QAtesters, DevOps) are referred to as users in Argo CD.
kubectl edit cm argocd-cm -n argocd
2. List the users to check of you have added all the
Login to argocd via cli
argocd login <ARGOCD-URL>
List users
argocd account list
3. Set password for all the users- Developer, QAtester, and John respectively.
argocd account update-password --account developer --new-password Developer123
argocd account update-password --account qa-tester --new-password Qatester123
argocd account update-password --account john --new-password User123
4. Define the RBAC rules by adding new policies to argocd-rbac-cm config map file.
kubectl edit cm argocd-rbac-cm -n argocd
data:
policy.csv: |
p, role:readwrite, applications, get, */*, allow
p, role:readwrite, applications, create, */*, allow
p, role:readwrite, applications, delete, *, allow
p, role:readexecute, applications, get, */*, allow
p, role:readexecute, applications, sync, */*, allow
g, developer, role:readwrite
g, qa-tester, role:readexecute
policy.default: role:readonly
5. Test the configurations by logging as one of the users- developers, QAtesters or anonymous (John).
- Login as developer , and you will realise that he/she can only create, delete and see the apps, but he can not sync the applications.
- Login as qa-tester where as he can only visualise the apps, and sync the application for GitOps deployment.
- Login as john he can only see all resources as default policy readonly is applied in this case.
Next step
So we have learned how to configure RBAC in Argo CD. If you want to get insights into some of the advanced use cases then please refer to how to configure LDAP in Argo CD for RBAC.
If you need to save all the hassle and get started with enterprise-wide GitOps deployment, then use OpsMx Intelligent Software Delivery (ISD) for Argo, which comes with all the bells and whistles for security and scale requirements for your software delivery. Free trial for ISD for Argo is available here.
OpsMx also provides Argo Center of Excellence (COE) for enterprises needing expert services or consultation on Argo CD and Argo Rollout implementation to expedite their GitOps journey.
About OpsMx
Founded with the vision of “delivering software without human intervention,” OpsMx enables customers to transform and automate their software delivery processes. OpsMx builds on open-source Spinnaker and Argo with services and software that helps DevOps teams SHIP BETTER SOFTWARE FASTER.
0 Comments