Getting Harbor to trust your LDAPS certificate in TKG

In a recent TKG implementation, it was required to configure Harbor with LDAPS rather than LDAP.

I deployed the Harbor package on the TKG shared services cluster and configured LDAP. However, when testing the connection, I received an error message that was not informative at all:

Failed to verify LDAP server with error: error: ldap server network timeout.

Although the error message doesn’t explicitly say there’s a certificate issue and there is nothing in the harbor-core container logs, it immediately made sense to me that the harbor-core container didn’t trust my LDAPS/CA certificate, so I started investigating how the certificate could be injected somehow into Harbor. The Harbor package doesn’t have any input for the LDAPS/CA certificate in its data values file, so I knew I had to create my own YTT overlay.

The overlay mounts the provided LDAPS certificate on the harbor-core pod under /etc/harbor/ssl/ldaps.

Instructions for applying the overlay:

Note: in the following example, the Harbor package is installed in the tkg-packages namespace. If your Harbor package is installed in a different namespace, specify your namespace.

Clone my TKG GitHub repository.

Modify the ytt-overlays/tkg-packages/harbor/ldaps-overlay/overlay-harbor-ldaps-cert.yaml overlay file and set your LDAPS/CA certificate for the ca.crt parameter under the harbor-ldaps-cert secret.

Important note: the overlay file contains an extra empty line at the end. This is part of the ca.crt value, and you must keep this line. Otherwise, Harbor will run into issues reading the certificate.

On your TKG cluster, create a secret from the overlay-harbor-ldaps-cert.yaml file:

kubectl apply -f overlay-harbor-ldaps-cert.yaml -n tkg-packages

Annotate the Harbor PackageInstall resource with the overlay:

kubectl annotate packageinstalls harbor \
ext.packaging.carvel.dev/ytt-paths-from-secret-name.0=overlay-harbor-ldaps-cert -n tkg-packages

Trigger reconciliation for the package and wait for the package to reconcile.

kctrl app kick -a harbor -n tkg-packages -y

Example output:

12:43:42PM: Fetching
            | apiVersion: vendir.k14s.io/v1alpha1
            | directories:
            | - contents:
            |   - imgpkgBundle:
            |       image: projects.registry.vmware.com/tkg/packages/standard/harbor@sha256:e3dd598b9790e1ce24330d69138db21e5b062f457d85e0aeadf619281ec937bc
            |     path: .
            |   path: "0"
            | kind: LockConfig
            |
12:43:42PM: Fetch succeeded
12:43:43PM: Template succeeded
12:43:43PM: Deploy started (2s ago)
12:43:45PM: Deploying
            | Target cluster 'https://100.64.0.1:443' (nodes: it-tkg-wld-cls-control-plane-svtdm, 5+)
12:44:01PM: App reconciled (1s ago)

Succeeded

Confirm that the package has been successfully reconciled.

kubectl get app harbor -n tkg-packages

Example output:

NAME     DESCRIPTION           SINCE-DEPLOY   AGE
harbor   Reconcile succeeded   3m50s          47m

If you run kubectl get pods -n tanzu-system-registry, you should see that the harbor-core pod has been recreated, as the harbor-core deployment has been modified by the overlay.

NAME                                    READY   STATUS    RESTARTS      AGE
harbor-core-6b59c56588-dmgcs            1/1     Running   0             41s
harbor-database-0                       1/1     Running   0             51m
harbor-jobservice-668f7fb46b-8m8pp      1/1     Running   0             51m
harbor-notary-server-86468896df-vb5mv   1/1     Running   1 (51m ago)   51m
harbor-notary-signer-6cfbb6bc48-chvwj   1/1     Running   1 (51m ago)   51m
harbor-portal-5885996b5c-6xtkc          1/1     Running   0             51m
harbor-redis-0                          1/1     Running   0             51m
harbor-registry-df89fccd5-jx4v4         2/2     Running   0             51m
harbor-trivy-0                          1/1     Running   0             51m

You can now access Harbor and test the connection to your LDAP server. As Harbor now trusts your certificate, it should be able to verify the connection via LDAPS.