Before we can access the Argo CD Web UI, we must authenticate with the GKE cluster. To do so, run the following command:
$ gcloud container clusters get-credentials \ mdo-cluster-dev –zone us-central1-a –project $PROJECT_ID
To utilize the Argo CD Web UI, you will require the external IP address of the argo-server service.
To get that, run the following command:
$ kubectl get svc argocd-server -n argocd
NAME TYPE EXTERNAL-IP PORTS AGE argocd-server LoadBalaner 34.122.51.25 80/TCP,443/TCP 6m15s
We now know that Argo CD is accessible at https://34.122.51.25/. Upon visiting this link, you’ll notice that username and password are required for authentication:
Figure 12.10 – Argo CD Web UI – login page
Argo CD provides an initial admin user by default, and the password for this user is stored in the argocd-initial-admin-secret Secret resource as plaintext. While you can use this default setup, it’s worth noting that it is generated from the publicly available YAML manifest. Therefore, it’s advisable to update it. To do so, execute the following command:
$ kubectl patch secret argocd-secret -n argocd \
-p ‘{“data”: {“admin.password”: null, “admin.passwordMtime”: null}}’ $ kubectl scale deployment argocd-server –replicas 0 -n argocd $ kubectl scale deployment argocd-server –replicas 1 -n argocd
Now, allow two minutes for the new credentials to be generated. After that, execute the following command to retrieve the password:
$ kubectl -n argocd get secret argocd-initial-admin-secret \ -o jsonpath=”{.data.password}” | base64 -d && echo
Now that you have the necessary credentials, log in and you will see the following page:
Figure 12.11 – Argo CD Web UI – home page
We’ve successfully set up Argo CD. The next step is to deploy our application; however, as we know that our application uses Kubernetes Secrets, which we cannot store on Git, we will have to find a mechanism to store it securely. To solve that problem, we have Bitnami’s SealedSecret resource. We’ll look at that in the next section.
Managing sensitive configurations and Secrets
Sealed Secrets solves the problem of I can manage all my Kubernetes config in Git, except Secrets. Sealed Secrets function as secure containers for your sensitive information. When you require a storage solution for secrets, such as passwords or keys, you place them in these specialized packages. Only the Sealed Secrets controller within Kubernetes can unlock and access the contents. This ensures the utmost security and protection for your valuable secrets. Created by Bitnami Labs and open sourced, they help you encrypt your Kubernetes Secrets into Sealed Secrets using asymmetric cryptography that only the Sealed Secrets controller running on the cluster can decrypt. This means you can store the Sealed Secrets in Git and use GitOps to set up everything, including Secrets.
Sealed Secrets comprises two components:
- A client-side utility called kubeseal helps us generate Sealed Secrets from standard Kubernetes Secret YAML
- A cluster-side Kubernetes controller/operator unseals your secrets and provides the key certificate to the client-side utility
The typical workflow when using Sealed Secrets is illustrated in the following diagram:
Figure 12.12 – Sealed Secrets workflow
Now, let’s go ahead and install the Sealed Secrets operator.
