Adding an SSL certificate to an Applicated hosted on Kubernetes.

There are a number of scenarios, where you have a Pod running in Kubernetes and trying to access a URL which is accessible via a self-signed certificate.

On many a occasions, the application in the Pod could error out with a certificate validation error. At that stage, you would like to include the remote URL’s SSL certificate in the list of trusted certs.

While there are many ways to do it, one of them is to pass the SSL cert of the remote URL as a configmap. Consider a scenario:

• We have a GitLab instance running with self-signed certificate on a remote host and the Devtron instance is running on Kubernetes.
• The Devtron instance needs to be setup for GitOps via GitLab. The Devtron UI does NOT allow of disabling SSL validation while adding GitLab as a GitOps source.
• This means, we have to provide the SSL certificate of the Gitlab host within the trust store of Devtron.
• We will do so by using Kubernetes config map technique.

Let’s see this in action with a video exhibit.

The sequence of implementing the same is provided below. As mentioned earlier, while the application requiring the certificate is Devtron this can be done in any k8s hosted deployment.

helm repo add devtron https://helm.devtron.ai

# Install Devtron

helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd \
--set installer.modules={cicd} \
--set argo-cd.enabled=true

# Check installation status

kubectl -n devtroncd get installers installer-devtron \
-o jsonpath='{.status.sync.status}'

# Do not proceed unless the status shows "applied"

# Get the IP to access Devtron

kubectl get svc -n devtroncd devtron-service \
-o jsonpath='{.status.loadBalancer.ingress}'

# Get the admin password

kubectl -n devtroncd get secret devtron-secret \
-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d

The Devtron instance is created. Login to the Devtron UI and navigate to Global configurations via the left-hand menu. We want to connect Devtron GitOps with our GitLab gitlab.oidc.thecloudgarage.com running on port 10443.

At first this will error out due to SSL validation error.

To ensure that the SSL certificate of our Gitlab instance is trusted by Devtron pod/s, we will use the config map technique.

#Declare a variable named fqdn

fqdn=gitlab.oidc.thecloudgarage.com

# Scan and build the SSL certificate from host URL
# The naming of the SSL file is extremely important as in <FQDN>.crt
# This is taken care by the above variable

echo -n | openssl s_client -connect $fqdn:10443 -servername $fqdn \
    | openssl x509 > $HOME/$fqdn.crt

# Create the Kubernetes configmap that will hold the SSL certificate
kubectl -n devtroncd create configmap gitlab-cert --from-file=$HOME/$fqdn.crt

# A bit of bash always helps
# We will use the configmap as a reference to insert the SSL certificate
# We retrieve the deployment YAML in a temporary hold and then use sed commands
# The sed command will search for line ending with volumeMounts:
# And then insert via echo commands the mountPath and subPath statements
# Note the use of double quotes in echo command to substitue the fqdn variable
# The echo commands within the sed logic will insert the volumeMount and volume statements
# And finally a kubectl replace is executed to replace 
# the existing deployment with a new YAML

kubectl get deployment devtron -n devtroncd -o yaml \
| sed '/volumeMounts:$/r'<(
    echo "        - mountPath: /etc/ssl/certs/$fqdn.crt"
    echo "          name: gitlab-cert"
    echo "          subPath: $fqdn.crt"
) | \
 sed '/volumes:$/r'<(
    echo "      - configMap:"
    echo "          defaultMode: 420"
    echo "          name: gitlab-cert"
    echo "        name: gitlab-cert"
) | kubectl replace -f -

# One can always manually edit the live deployment and insert the 
# volumeMount and volume statements
# Ensure that mountPath and subPath always matches 
# the filename that was used to create the configmap
# Else, the mount comes up as an empty directory
# The above method of export via declaring the fqdn variable always helps
# As it minimizes naming risks

Hope this helps,

cheers,

Ambar@thecloudgarage

#iwork4dell