Step 1: Create Certificate Signing Request
When you examine the certificate of the database initially, you will see that it is managed by DSM.
We will now create a custom certificate to replace it. We begin by building the Certificate Signing Request (CSR) using the YAML (Yet Another Markup Language) format. This CSR is sent to the Cert Manager to create a certificate for us to use on our database. This results in the creation of a secret that contains the certificate information. The secret will be created in the namespace cormac-ns on the vSphere IaaS Control Plane. This is the same vSphere IaaS environment and namespace that I used to build the provider certificate mentioned earlier, so it already has a cert issuer available called my-ca.
% kubectl get issuer my-ca NAME READY AGE my-ca True 3d21h
I can now go ahead and build out the YAML manifest for the certificate signing request. Note that the ipAddress: entry is unnecessary unless you wish to continue to allow users to access the database via IP address as well as FQDN (Fully Qualified Domain Name).
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: mysql01 namespace: cormac-ns spec: secretName: mysql01-cert-tls secretTemplate: annotations: my-secret-annotation-1: "secret" labels: my-secret-label: squirrel issuerRef: name: my-ca kind: Issuer group: cert-manager.io commonName: mysql01.rainpole.com dnsNames: - mysql01.rainpole.com ipAddresses: - xx.yy.zz.aa
Step 2: Create and tidy up certificate secret
After sending the CSR request to the Cert Manager, a new secret with the certificate information is created. The certificate / secret will be populated populated with a “leaf” Certificate, Private Key and Certificate Authority (CA). Once created, the secret can be exported into a new “secret” YAML manifest that we will use in our DSM environment.
% kubectl apply -f csr-mysql01.yaml certificate.cert-manager.io/mysql01 created % kubectl get secrets mysql01-cert-tls NAME TYPE DATA AGE mysql01-cert-tls kubernetes.io/tls 3 63s % kubectl get secrets mysql01-cert-tls -o yaml > mysql01-cert-tls-secret.yaml
Now we need to tidy up the secret YAML manifest. Edit the secret YAML manifest using using your local editor of your choice and remove the following fields from the YAML manifest:
- creationTimesteamp
- uid
- resourceVersion
- namespace (database secrets go into default namespace)
Now we have a YAML manifest that can be applied in DSM which holds the custom certificates for our database.
Step 3: Switch context to DSM Gateway API
Let’s now switch context to the DSM Gateway API by downloading the kubeconfig as we did in the previous blog post from the DSM UI. In this example, I am not setting the KUBECONFIG environment variable, but rather setting the path to the config in each command using the –kubeconfig option. The path to the downloaded DSM Gateway API is ~/Downloads/kubeconfig-gateway. You can use either method, either command line option or environment variable. Start by creating the certificate secret. Note that there is no reference to namespace in the command or in the YAML manifest as the secret is expected to be placed in the default namespace.
% kubectl apply -f mysql01-cert-tls-secret.yaml --kubeconfig ~/Downloads/kubeconfig-gateway.yaml secret/mysql01-tls-secret created
Verify that the secret has been successfully created.
% kubectl get secrets --kubeconfig ~/Downloads/kubeconfig-gateway.yaml NAME CREATED AT mysql-mysql01 2024-07-22T16:00:49Z mysql01-tls-secret 2024-08-16T11:19:47Z
Step 4: Apply the custom certificate to the database
We can now apply the secret/certificate to the database. Check the state of the database that you wish to add the certificate to. In this example, I am using a MySQL database and the status is READY. We can go ahead and add the secret/certificate.
% kubectl get mysqlclusters --kubeconfig ~/Downloads/kubeconfig-gateway.yaml NAME STATUS STORAGE VERSION AGE mysql01 Ready 60Gi 8.0.34+vmware.v2.1.1-rc.10 24d
Next edit the database to add your secret/certificate. This step updates the spec.tls.secretName field in the database to point to the secret, which in turn contains the certificate information. Your contents might look slightly different in your environment but you can add the spec.tls.secretName following the same format as below. The tls: field is inset by 2 spaces under the spec section, whereas the secretName field is inset by four spaces. See below:
% kubectl edit mysqlclusters mysql01 --kubeconfig ~/Downloads/kubeconfig-gateway.yaml spec: . . dnsNames: - mysql01.rainpole.com infrastructurePolicy: name: infra-policy-01 members: 1 storagePolicyName: vSAN Default Storage Policy storageSpace: 60Gi tls: secretName: mysql01-tls-secret . .
Save the changes made above and within a very short period of time, the database should show up in the DSM UI as using a custom cert.
And that concludes how to add a custom certificate to a DSM provisioned database. Note that this process is supported on MySQL standalone databases and MySQL clustered databases, as well as PostgreSQL standalone databases.