Skip to main content

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

Important Notes​

  • 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.
  • Harness CI Build and Push steps use the kaniko plugin by default. 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.

Workflow Description​

To implement this functionality, do the following:

  1. Create a Kubernetes secret or config map with the required certificates in the same namespace used by the Harness Delegate.
    Here's an example YAML snippet:
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-------
  1. Mount the secret as a volume on the Delegate pod. For details, see Configure a Pod to Use a Volume for Storage in the Kubernetes documentation.
    You need to specify the following environment variables in the Delegate pod:
    ADDITIONAL_CERTS_PATH: the path to the certificates in the Delegate. For example: /tmp/ca.bundle.
    CI_MOUNT_VOLUMES: a comma-separated list of source:destination mappings. The source is the certificate path on the delegate and the 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.crtThis list must include all certificates that your build containers need to interact with external services.Here's an example YAML snippet:
apiVersion: apps/v1  
kind: StatefulSet  
spec:  
  template:  
    spec:  
        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
  1. 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.

Troubleshooting​

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.