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-server component fetches manifests from Git repositories. If your Git server uses TLS, repo-server must 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.

  1. 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.

  2. Mount the Secret into the argocd-server Deployment: You’ll need to edit the argocd-server deployment 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-certs
    

    After applying these changes, the argocd-server pod will have your certificate and key available at /etc/argocd/certs/tls.crt and /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.

  1. 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-----
    
  2. Mount the ConfigMap into the argocd-repo-server Deployment: Similar to the argocd-server, you edit the argocd-repo-server deployment.

    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-certs
    

    The repo-server will then trust certificates signed by the CAs provided in ca-bundle.crt for 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.

Want structured learning?

Take the full Argocd course →