Configure a Kubernetes build farm to use self-signed certificates

CI build infrastructure pods can interact with servers using self-signed certificates. This option is useful for organizations that prefer to use internal certificates instead of certificates generated by a public Certificate Authority (CA).

info

• This topic assumes that you are familiar with how to implement SSL in Kubernetes. General information about implementing SSL is outside the scope of this topic.
• With a Kubernetes cluster build infrastructure, all Build and Push steps use kaniko. Kaniko uses the path /kaniko/ssl/certs/additional-ca-cert-bundle.crt to read certificates.
• Harness uses a UBI image for the Git Clone step. UBI reads certificates from /etc/ssl/certs/ca-bundle.crt.
• Different base images use different paths as their default certificate location. For example, Alpine images use this path to recognize certificates: /etc/ssl/certs/ca-certificates.crt For any other image, make sure you verify the default certificate path.

Enable self-signed certificates

1. Create a Kubernetes secret or config map with the required certificates in the same namespace used by the Harness delegate. For example:

   apiVersion: v1  
   kind: Secret  
   metadata:  
     name: addcerts  
     namespace: harness-delegate-ng  
   type: Opaque  
   stringData:                             
     ca.bundle: |  
       -----BEGIN CERTIFICATE-----  
       XXXXXXXXXXXXXXXXXXXXXXXXXXX  
       -----END CERTIFICATE-------  
       -----BEGIN CERTIFICATE-----  
       XXXXXXXXXXXXXXXXXXXXXXXXXXX  
       -----END CERTIFICATE-------

2. Mount the secret as a volume on the delegate pod.

   For instructions, go to the Kubernetes documentation on Configuring a Pod to Use a Volume for Storage.

   In the delegate pod, you must specify DESTINATION_CA_PATH. Provide a comma-separated list of paths in the build pod where you want the certs to be mounted, and mount your certificate files to opt/harness-delegate/ca-bundle.

          env:
           - name: DESTINATION_CA_PATH
             value: "/etc/ssl/certs/ca-bundle.crt,/kaniko/ssl/certs/additional-ca-cert-bundle.crt"
             volumeMounts:
              - name: certvol
                mountPath: /opt/harness-delegate/ca-bundle/ca.bundle
                subPath:  ca.bundle
          volumes:
           - name: certvol
             secret:
               secretName: addcerts
               items:
                - key: ca.bundle
                  path: ca.bundle

   Both CI build pods and the SCM client on the delegate support this method.

   caution

   Make sure the destination path is not same as the default CA certificate path of the corresponding container image.

   If you want to override the default certificate file, make sure the Kubernetes secret or config map (from step one) includes all certificates required by the pipelines that will use this build infrastructure.

   Legacy: CI_MOUNT_VOLUMES

   Prior to the introduction of DESTINATION_CA_PATH, you used ADDITIONAL_CERTS_PATH and CI_MOUNT_VOLUMES to mount certs.

   The legacy method is still supported, but Harness recommends DESTINATION_CA_PATH. If you include both, DESTINATION_CA_PATH takes precedence. If Harness can't resolve DESTINATION_CA_PATH, it falls back to CI_MOUNT_VOLUMES and ADDITIONAL_CERTS_PATH.

   You must specify both ADDITIONAL_CERTS_PATH and CI_MOUNT_VOLUMES.

   For ADDITIONAL_CERTS_PATH, provide the path to the certificates in the delegate, such as /tmp/ca.bundle.

   For CI_MOUNT_VOLUMES, provide a comma-separated list of source:destination mappings where source is the certificate path on the delegate, and destination is the path where you want to expose the certificates on the build containers. For example:

   /tmp/ca.bundle:/etc/ssl/certs/ca-bundle.crt,/tmp/ca.bundle:/kaniko/ssl/certs/additional-ca-cert-bundle.crt

   The CI_MOUNT_VOLUMES list must include all certificates that your build containers need to interact with external services.

          env:  
           - name: ADDITIONAL_CERTS_PATH  
             value: /tmp/ca.bundle  
           - name: CI_MOUNT_VOLUMES  
             value: /tmp/ca.bundle:/etc/ssl/certs/ca-bundle.crt,/tmp/ca.bundle:/kaniko/ssl/certs/additional-ca-cert-bundle.crt  
             volumeMounts:  
              - name: certvol  
                mountPath: /tmp/ca.bundle  
                subPath:  ca.bundle 
          volumes:  
           - name: certvol  
             secret:  
               secretName: addcerts  
               items:  
                - key: ca.bundle  
                  path: ca.bundle

3. Restart the delegate. Once it is up and running, exec into the container and ensure that the volume exists at the mounted path and contains your certificates.

Additional configuration for pipelines with STO scan steps

If you have STO scan steps in your pipeline, follow the steps to enable self-signed certificates, and complete the additional steps and requirements described in Adding Custom Artifacts to STO Pipelines.

Troubleshooting SCM service connection issues

If your builds fail due to a problem connecting to the scm service, add SCM_SKIP_SSL=true to the environment section of the delegate YAML. For more information about this issue, go to Troubleshoot CI.

If the volumes are not getting mounted to the build containers, or you continue to see certificate errors in your pipeline, try the following:

1. Add a Run step that prints the contents of the destination path. For example, you can include a command such as:

   cat /kaniko/ssl/certs/additional-ca-cert-bundle.crt

2. Double-check that the base image used in the step reads certificates from the same path given in the destination path on the Delegate.