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:
- 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-------
- 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 ofsource:destination
mappings. Thesource
is the certificate path on the delegate and thedestination
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
This 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
- 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:
- 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
- Double-check that the base image used in the step reads certificates from the same path given in the destination path on the Delegate.