Using a private certificate authority (CA)
Installations which must serve Testkube endpoints or Git repositories using certificates signed by a private CA should use this guide to make sure Testkube components trust the private CA.
Configurations
To get started we need to create a bundle containing all the CA certificates we would like the installation to trust.
After that you will need to create a secret with the CA bundle under the
ca.crt
key in the namespace(s) with the Helm releases both for the agent and
the enterprise control plane.
kubectl -n <namespace> create secret generic <secret name> --from-file=ca.crt=<path to the file with the ca bundle>
If your CA bundle secret is generated by an external system and you cannot
specify the key name in the secret, you can use customCaSecretKey
to override
the default value of ca.crt
with your key name, but then please make sure to
update the value accordingly in the rest of this guide.
Configure the following value in the testkube-enterprise
chart:
global:
customCaSecretRef: <secret name>
customCaSecretKey: "ca.crt"
certificateProvider: ""
Configure the following values in the testkube
chart:
global:
testWorkflows:
globalTemplate:
enabled: true
spec:
pod:
volumes:
- name: testkube-enterprise-ca
secret:
secretName: <secret name>
defaultMode: 420
container:
env:
- name: SSL_CERT_DIR
value: /etc/testkube/certs/
- name: GIT_SSL_CAINFO
value: /etc/testkube/certs/testkube-custom-ca.pem
volumeMounts:
- name: testkube-enterprise-ca
mountPath: /etc/testkube/certs/testkube-custom-ca.pem
# NOTE: If you overrode the key name using customCaSecretKey,
# then you should also update this subPath value.
subPath: ca.crt
testkube-api:
cloud:
tls:
customCaSecretRef: <secret name>
customCaSecretKey: "ca.crt"
If you create Ingress configurations, add a secret with the certificate that was signed by the CA to each Ingress manifest.
testkube-cloud-api:
api:
tls:
serveHTTPS: false
tlsSecret: <another secret name>
testkube-cloud-ui:
ingress:
tlsSecretName: <another secret name>
dex:
ingress:
- secretName: <another secret name>
hosts:
- <hostname>
minio:
customIngress:
tls:
tlsSecret: <another secret name>
If you create an Istio Gateway, you need to deploy a certificate for all required domains there.
Pulling from Git repositories
If you would like to be able to pull Git data from repositories served both by GitHub (or any other host) and your own Git servers which utilize private CA signed certificates you will need to bundle the root CA certificates for those hosts by concatenating them into one CA bundle.
Prebuilt executors
Should work out of the box with customCaSecretRef
set.
Container executors
Pulling from Git repositories should work with customCaSecretRef
set, but if
the container executing the test must trust your private CA you will need to
bake your CAs certification into the right location inside your image.
Workflows
With the global template specified above you should be able to both mount and trust the CA bundle for pulling from Git and processing the results of the test executions.
However, if the containers specified as part of the workflow require the trust of your private CA then you will need to configure the container/pod in a similar way as shown in the global template to mount the CA bundle to the right location and/or, if necessary, specify an environment variable.