In this chapter, we'll explore how to set up user access to Argo CD, with options for connecting to the CLI from a terminal or CI/CD pipeline, and how to enforce role-based access control. We'll be looking at the single sign-on (SSO) option, normally this is a paid feature, but since Argo CD is completely open source and has no commercial offering, you can use it out of the box. The main topics we will cover are:
• Declarative users
• Service accounts
• Single sign-on
skills requirement
In this chapter, we assume that you already have Argo CD installed on your device or in the cloud. We don't need a highly available installation; it could be in a local Kubernetes cluster, but we need one that can manage itself since we'll be making multiple changes to it. For the single sign-on part, we need an installation that can be accessed by an external provider, so we need a domain name or public IP address. We'll be writing some code (YAML code to be more precise), so we'll also need a code editor. I'm using Visual Studio Code (https://code.visualstudio.com). All the changes we will be making can be found in the ch04 folder of https://github.com/PacktPublishing/ArgoCD-inPractice.
declarative user
The Open Web Application Security Project (OWASP) - https://owasp.org - is a non-profit foundation dedicated to work in the field of web application security. Their most famous project is the OWASP Top Ten (https://owasp.org/www-project-top-ten/), a list of the most important risks to web application security. They update this list every few years. Currently, in their latest release, the 2021 edition, we have Broken Access Control at number one (it was fifth on the 2017 list). Since the main goal of the top ten is to raise awareness in the community of the major web security risks, we can understand that Broken Access Control is at the top, which is to make the appropriate settings in terms of our users and the access rights everyone gets. , to avoid violating the principle of least privilege. Our development team usually gets write access to the development environment, and only read access to our production environment, while the SRE has full access. Next, we'll see how to achieve this.
Administrators and local users
After installing Argo CD in the cluster, we only have the admin user. Initially, the password for the admin user is the name of the application server pod (or the first pod started if there are multiple); it looks like this - argocd-server-bfb77d489-wnzjk. However, this is considered bad choice because the first part of most installations (Pods starting with argocd-server-) is fixed, while the second part is generated and should have random characters, but they don't Random (more details can be found at https://argo-cd.readthedocs.io/en/stable/security_considerations/#cve-2020-8828-insecure-default-administrative-password). Also, it's visible to everyone with access to the cluster (this doesn't necessarily mean having Argo CD admin access). Therefore, since the release of version 2.0.0, a new password is generated for the user when the application is installed and saved in a Secret called argocd-initial-admin-secret. We can view the password after installation with the following command:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d
The command output is your password and should look similar to the following (% characters should be removed because the shell inserts this CR/LF so that the prompt starts a new line):
pOLpcl9ah90dViCD%
Now, you can check that it's working using passwords for the UI and CLI. To update your password, you can use the UI by navigating to the User Information section, or you can update it via the CLI using the argocd account update-password command (https://argo-cd.readthedocs.io/en/stable/user-guide /commands/argocd_account_updatepassword/). If you forget your password, there is a way to reset it that involves making some changes directly to the Argo CD master Secret resource where the bcrypt hash is stored - more details can be found at https://argo-cd.readthedocs.io/en/ stable/faq/#i-forgot-theadmin-password-how-do-i-reset-it found.
After we enable the admin user, the next step is to disable it because it's so powerful we want to follow the principle of least privilege, which means we should only use the smallest type of access we need to do our work (can be found in Learn more here: https://en.wikipedia.org/wiki/Principle_of_least_privilege). But in order not to lose access to the system, we need to first create a local user with less privileges that will allow us to perform day-to-day tasks. We named it alina and gave it access to the UI and CLI. The rule of thumb is to always have a dedicated user for each colleague who needs to access Argo CD, rather than using it as a group or team user. This helps if someone leaves the team and loses access to the system, as we can always disable or delete their account. To add a new user, the ConfigMap argocd-cm file should look like this:
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
accounts.alina: apiKey, login
accounts.gitops-ci: apiKey
admin.enabled: "false"
We should create a commit and push this update to the remote so that Argo CD applies our configuration changes (in order to automatically apply this ConfigMap when pushing, you need to install and configure Argo CD as described in Chapter 3, "Running Argo CD") . Assuming the CLI is installed and pointed to our API server instance (logged in with an admin user), we can verify that a new user was created by running the following code:
argocd account list
The output should look like this:
This means we have that user ready, but we still need to set its password. To do this, we can use this command, using the admin password as the current password:
argocd account update-password --account alina --currentpassword pOLpcl9ah90dViCD --new-password k8pL-xzE3WMexWm3cT8tmn
The output should look like this:
Password updated
When running this update-password command, it is possible to skip passing the current-password and new-password parameters; this way, their values are not saved in the shell history. If you don't pass them, you'll be asked to enter them interactively, which is a safer alternative.
To see what's going on, we need to run this command to view the argocd-secret Secret resource. We'll see a new entry for our user there, just like the admin user:
kubectl get secret argocd-secret -n argocd -o yaml
we should get the following result (we'll remove some fields that don't matter to us):
If we look at the token created for this user (in the accounts .alina.tokens field), we will see that it is actually null, which means we are not currently creating any tokens.
echo "bnVsbA==" | base64 –d
The output is as follows:
null%
If you're wondering what permissions this user has, it can't actually do anything right now. We can log in with it, but if we try to list the applications or clusters, we get an empty list. In order to allow it to do something, we have two options: either we will give the user specific permissions, or we set a default policy to which every user will fall back when authenticating in case the specific permissions are not found. strategy. We will now set the default policy to read-only and examine how to add specific permissions when using an access token. To do this, we need to modify a new ConfigMap resource called argocd-rbac-cm.yaml where we will set all the role-based access control (RBAC) rules. Create a new file called argocd-rbac-cm.yaml in the same location as the argocd-cm.yaml ConfigMap and add the following content:
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
data:
policy.default: role:readonly
Don't forget to add entries in the kustomization.yml file. We should now have two entries under patchesStrategicMerge for the two ConfigMaps we modified:
patchesStrategicMerge:
- patches/argocd-cm.yaml
- patches/argocd-rbac-cm.yaml
Create a commit of the two files and push it to the remote so that Argo CD can apply the RBAC default policy. Once the changes are complete, we can use the CLI to use the new user. To do this, first we should log in to the API server (in my case I use port forwarding to use the server https://localhost:8083 from a local installation):
argocd login localhost:8083 --username alina
You may get a warning message that the certificate is from an unknown authority, which is correct since it is self-signed. We can ignore it for now since we are connecting to localhost:
WARNING: server certificate had error: x509: certificate signed by unknown authority. Proceed insecurely (y/n)?
Next, please enter the password of the alina account, you will be successfully logged in and can start executing commands.
We can try listing Argo CD's installed applications to make sure we have read permissions:
argocd app list
The output should look like this (this list will be empty until the default policy is set to read-only):
Now, we can go ahead and disable the admin user, we can use the admin.enabled field in the argocd-cm ConfigMap and set it to set to false. It should look like this:
Commit the changes and push them to the remote so that the admin user can no longer be used. You have taken a step towards securing your Argo CD instance and preparing it for production. We've seen how users are handled in a declarative way, how to create new local users and disable administrators, and how passwords are handled. Next, we'll learn about users for automation, so-called service accounts.