Skip to content

Routes

The Argo CD Operator offers support for managing OpenShift Routes to access the Argo CD resources.

Once the operator is deployed and running, create a new ArgoCD custom resource. The following example shows the minimal required to create a new ArgoCD environment with the default configuration.

oc create -f examples/argocd-route.yaml

There will be several resources created.

oc get pods
NAME                                                     READY   STATUS    RESTARTS   AGE
example-argocd-application-controller-7c74b5855b-brn7s   1/1     Running   0          29s
example-argocd-dex-server-859bd5458c-78c8k               1/1     Running   0          29s
example-argocd-redis-6986d5fdbd-vzzjp                    1/1     Running   0          29s
example-argocd-repo-server-7bfc477c58-q7d8g              1/1     Running   0          29s
example-argocd-server-7d56c5bf4d-9wxz6                   1/1     Running   0          29s
argocd-operator-758dd86fb-qshll                          1/1     Running   0          51s

The ArgoCD Server should be available via an OpenShift Route.

oc get routes
NAME                        HOST/PORT                                               PATH   SERVICES                 PORT   TERMINATION     WILDCARD
example-argocd-server       example-argocd-server-argocd.apps.test.example.com              example-argocd-server    http   edge/Redirect   None

The Route is example-argocd-server in this example and should be available at the HOST/PORT value listed. The admin password is stored in the argocd-cluster secret in the installation namespace:

To get the password for the admin user:

$ kubectl get secret argocd-cluster -n argocd -ojsonpath='{.data.admin\.password}' | base64 --decode

Setting TLS modes for routes

By default, the operator creates the Argo CD server route with reencrypt termination policy. You can parameterize the route's TLS configuration by setting appropriate values in the .spec.server.route.tls field of the ArgoCD CR.

Warning

It is not recommended to use .route.tls.key & .route.tls.certificate fields to configure custom certificates for Argo CD routes. Use .route.tls.externalCertificate field instead. Refer Custom TLS certificates section for more information.

TLS edge termination mode

In edge termination mode, the route controller terminates the TLS connection and proxies the requests to Argo CD in plain text throughout the cluster.

The edge termination mode requires the Argo CD server to run in insecure mode, so it will accept HTTP requests instead of TLS requests.

To set a route to edge mode, you can use the following configuration:

spec:
  server:
    insecure: true
    route:
      enabled: true
      tls:
        termination: edge
        insecureEdgeTerminationPolicy: Redirect

Keep in mind that the connection will be unencrypted within your cluster.

TLS passthrough mode

Passthrough will terminate TLS not on the route controller, but at the argocd-server service. This means, that Argo CD will need to be configured with a valid TLS certificate, otherwise clients will issue a warning upon trying to connect.

To set a route to passthrough mode, you can use the following configuration:

spec:
  server:
    route:
      enabled: true
      tls:
        termination: passthrough

TLS reencrypt mode

The reencrypt mode works a bit like the edge mode, in that TLS termination of the client will happen at the route controller. However, unlike edge mode, the communication between the route controller and the Argo CD server will be encrypted as well, so the Argo CD server does not need to be set in insecure mode.

For this to work, the route controller needs to be able to validate the Argo CD server's TLS certificate, otherwise the request will fail.

If you enable reencrypt mode in an OCP cluster, the Operator will request a valid TLS certificate for the argocd-server service from OpenShift's Service CA, which is sufficient for satisfying the validation constraints of the route controller. The Service CA will issue this certificate to a secret named argocd-server-tls in the operand's namespace if it does not yet exist.

When you later chose to switch back to another TLS termination policy, you should manually delete the argocd-server-tls secret from the namespace after changing the mode.

To enable reencrypt mode, you can use the following configuration:

spec:
  server:
    route:
      enabled: true
      tls:
        termination: reencrypt
        insecureEdgeTerminationPolicy: Redirect

Custom TLS certificates

Custom TLS certificates can be configured for Argo CD Server Route using .route.tls.externalCertificate.Name field in ArgoCD CR. Use this field to reference a Kubernetes secret of type kubernetes.io/tls. Any modifications to the referenced secret will automatically reflect on the route without the need for manual intervention.

Warning

It is not recommended to use .route.tls.key & .route.tls.certificate fields to configure custom certificates for Argo CD routes, as the sensitive TLS data will be stored as plain text in ArgoCD CR. Use .route.tls.externalCertificate.Name field instead to reference a Kubernetes secret of type kubernetes.io/tls.

To provide custom certificate for route, you can use the following configuration:

spec:
  server:
    route:
      enabled: true
      tls:
        externalCertificate: 
          name: <your-tls-type-secret>

Note

The secret referenced in .tls.externalCertificate.Name should be of type kubernetes.io/tls.

Example TLS secret:

apiVersion: v1
kind: Secret
metadata:
  name: <example-tls-type-secret>
  namespace: <argocd-namespace>
type: kubernetes.io/tls
data:
  tls.crt: <certifcate>
  tls.key: <key>

Host for Route in Argo CD Status

When setting up access to Argo CD via a Route, one can easily retrieve the hostname used for accessing the Argo CD installation through the ArgoCD Operand's status field. To expose the host field, run kubectl edit argocd argocd and then edit the Argo CD instance server to have route enabled as true, like so:

server:
    autoscale:
      enabled: false
    grpc:
      ingress:
        enabled: false
    ingress:
      enabled: false
    route:
      enabled: true
    service:
      type: ""
  tls:
    ca: {}

If a route is found, your hostname can now be accessed by inspecting your Argo CD instance. It will look like the following:

status:
  applicationController: Running
  dex: Running
  host: argocd-server-default.my-cluster-url.openshift.com
  phase: Available
  redis: Running
  repo: Running
  server: Running
  ssoConfig: Unknown

If the status of the Route is pending, this will affect the overall status of the Operand by making it Pending instead of Available. Once the Route is available, the status of the Operand should change to Available.

Note that Routes are specific to OpenShift clusters, so in non-OpenShift clusters enabling Route will yield no results.