Google Cloud Platform (GCP) and finding TLS information for updates

Recently my organization had an need to move from a cantankerous implemenation of cert-manager in GCP for one of our applications.

In the past year the cert-manager application was changed, causing existing implementations to no longer rotate certificates, causing our production environment to crash into cinders. We decided to move our ingress certificates from being issued/updated from LetsEncrypt to something with a more robust duration. However I ran into a new set of challenges that I am hoping might be of a little interest to you.

Finding the Beans

One challenge that was mostly due to my ignorance of the Kubernetes system was finding the important information and configuration on the environments for what needs to be updated. Assuming we are using nginx-ingress to handle our http requests and return responses from internal scope applications, we need to obtain what ingress specifications are in place and what namespace and names they have.

>kubectl get ing --all-namespaces

From the results of this request we can fill out the following command to get the details of the ingress configuration, specifically in what I was interested in is the TLS specification.

>kubectl get ing -n [YOUR_NAMESPACE] ingress -o yaml > ingress_config.yaml

using the secretName’s specified for your ingress controllers you can obtain the existing configuration of the TLS secret with the following command in order to create archives in case you mess up in some way.

  >kubectl get secret [SECRET_NAME] -n=[NAMESPACE] -o yaml > [SECRET_NAME].yaml

Baking the Potato

I’m going to add this as a set of notes to help you out in the actual update process. As I ran into a couple small hiccups on actually applying the certificate update. Specifically an error that looks like the following:

>kubectl apply -f .\some_file_name.yaml

 error: error parsing .\some_file_name.yaml: error converting YAML to JSON: yaml: line 6: mapping values are not allowed in this context

This was happening due to the method in which the TLS content, both crt and key are encoded. Both the key and the crt content for a secret object in Kubernetes must be encoded in Base64. Due to some inherent differences in the implementation of Base64 encoding, specifically around how whitespace characters are handled, if you use a windows system implementation for encoding you will have characters that the validation process of Kubernetes will flag as a conversion issue. In order to address this you need to insure that a linux style implementation of Base64 encode is used. Once applied you should have a successfully updated TLS secret.