ArgoCD needs TLS certificates to secure communication between its components and with external clients.
Let’s see ArgoCD in action with TLS configured. Imagine a scenario where your ArgoCD server needs to connect to a Git repository over HTTPS.
# Simulate a Git clone operation initiated by ArgoCD
# In a real scenario, this would be an internal ArgoCD process
git clone https://your-git-server.com/your-repo.git --depth 1
If the your-git-server.com uses a TLS certificate that ArgoCD doesn’t trust, this git clone operation will fail with a certificate verification error.
ArgoCD’s core components, such as the API server, repo-server, and application controller, all communicate over TLS. This ensures that sensitive information, like Git credentials and cluster connection details, are not exposed in plain text. When you install ArgoCD, it can generate self-signed certificates for internal communication, or you can provide your own custom certificates for a more robust security posture.
The primary way you interact with ArgoCD is through its API server, typically via argocd CLI or the ArgoCD UI. Both of these clients establish TLS connections to the API server. If the API server’s certificate is not trusted by your client machine or browser, you’ll encounter connection errors.
Here’s a breakdown of how ArgoCD handles TLS and what you can configure:
- Internal Component Communication: ArgoCD components use TLS to secure their internal RPC (Remote Procedure Call) communication. This is often handled by self-signed certificates generated during installation if you don’t provide your own.
- External Client Connections: The ArgoCD API server exposes a TLS endpoint for the UI and CLI. This is where custom certificate configuration becomes crucial for production environments.
- Git Repository Access: The
repo-servercomponent fetches manifests from Git repositories. If your Git server uses TLS,repo-servermust trust its certificate.
To configure custom TLS certificates for the ArgoCD API server, you typically mount your certificate and key files into the argocd-server pod. This is done via Kubernetes ConfigMaps and Secrets.
-
Create a Kubernetes Secret for your certificate and key:
apiVersion: v1 kind: Secret metadata: name: argocd-custom-certs namespace: argocd # Or your ArgoCD namespace type: kubernetes.io/tls data: tls.crt: | -----BEGIN CERTIFICATE----- MIIDqTCCApGgAwIBAgIJAJgGvR/u+G3rMA0GCSGSIb3DQEBCwUAMCoxGzAZBgNV ... (your certificate content base64 encoded) ... -----END CERTIFICATE----- tls.key: | -----BEGIN PRIVATE KEY----- MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDA/O/P... ... (your private key content base64 encoded) ... -----END PRIVATE KEY-----Important: The certificate provided here should be the full chain certificate, meaning it includes your server certificate, any intermediate certificates, and potentially the root CA certificate if it’s not a publicly trusted one.
-
Mount the Secret into the
argocd-serverDeployment: You’ll need to edit theargocd-serverdeployment to add a volume that references this secret and then mount that volume into the container.apiVersion: apps/v1 kind: Deployment metadata: name: argocd-server namespace: argocd spec: template: spec: containers: - name: argocd-server # ... other container configurations ... volumeMounts: - name: custom-certs mountPath: "/etc/argocd/certs" # This path is important readOnly: true volumes: - name: custom-certs secret: secretName: argocd-custom-certsAfter applying these changes, the
argocd-serverpod will have your certificate and key available at/etc/argocd/certs/tls.crtand/etc/argocd/certs/tls.key. ArgoCD automatically picks these up if they are present in this specific location.
For Git repositories that use custom CAs (Certificate Authorities) or self-signed certificates, you need to configure ArgoCD’s repo-server to trust these certificates. This is done by creating a ConfigMap containing the CA certificates and then mounting it into the argocd-repo-server pods.
-
Create a ConfigMap for custom CA certificates:
apiVersion: v1 kind: ConfigMap metadata: name: argocd-extra-certs namespace: argocd # Or your ArgoCD namespace data: ca-bundle.crt: | -----BEGIN CERTIFICATE----- MIIDqTCCApGgAwIBAgIJAJgGvR/u+G3rMA0GCSGSIb3DQEBCwUAMCoxGzAZBgNV ... (your custom CA certificate content) ... -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDqTCCApGgAwIBAgIJAJgGvR/u+G3rMA0GCSGSIb3DQEBCwUAMCoxGzAZBgNV ... (another custom CA certificate content if needed) ... -----END CERTIFICATE----- -
Mount the ConfigMap into the
argocd-repo-serverDeployment: Similar to theargocd-server, you edit theargocd-repo-serverdeployment.apiVersion: apps/v1 kind: Deployment metadata: name: argocd-repo-server namespace: argocd spec: template: spec: containers: - name: argocd-repo-server # ... other container configurations ... volumeMounts: - name: extra-certs mountPath: /tmp/argocd-repo-certs # This path is important readOnly: true volumes: - name: extra-certs configMap: name: argocd-extra-certsThe
repo-serverwill then trust certificates signed by the CAs provided inca-bundle.crtfor its Git operations.
One of the less obvious aspects of TLS configuration for ArgoCD is how the argocd-server handles its TLS certificate. If you provide a certificate that is not signed by a publicly trusted CA, or if it’s a self-signed certificate for internal testing, you will need to ensure that your clients (browsers, argocd CLI) also trust this certificate. For the argocd CLI, this often means configuring the ARGOCD_TLS_INSECURE environment variable to true (not recommended for production) or, more securely, adding the custom CA certificate to your system’s trusted certificate store. For browsers, you’ll need to import the certificate.
The next logical step after securing your ArgoCD instance with custom TLS is to explore how ArgoCD handles secrets management, specifically how it integrates with external secret providers like HashiCorp Vault or Kubernetes Secrets to avoid storing sensitive data directly within Git.