You'll need the root certificate PEM file for your CA.
0. Before you begin
This example uses the ACME dns-01 challenge type, with Google Cloud DNS.
We'll create a service account on Google Cloud that cert-manager will use to solve DNS challenges.
For other DNS providers, or other ACME challenge types, you'll need to change the challenge solver settings below.
1. Create a Kubernetes cluster
For this tutorial, I created a Google Compute Engine VM running a kind cluster.
I'm using kind for testing, but pretty much any Kubernetes cluster will do.
Next, create a ConfigMap that contains your ACME server's CA certificate.
To find your certificate's PEM file, select your CA in the Google Cloud CAS Console, and view your CA certificate under the Actions menu.
Create a file called internal-ca.yaml, replacing the certificate shown here with your own:
[REPLACE with your CA certificate]
-----END CERTIFICATE-----kind: ConfigMap
$ kubectl apply -f internal-ca.yaml
To inject this ConfigMap into cert-manager, we need to patch the cert-manager Deployment to add the CA certificate as a container volume mount.
Create a file called cm-ca-patch.yaml:
configMap:# Provide the name of the ConfigMap containing the files you want# to add to the containername: ca-pemstore
Cert-manager is now configured to trust your ACME CA.
3. Create a GCP service account and import its credentials
Not using Google Cloud Platform? You can skip this step and configure the cert-manager Issuer in step 4 to use a different challenge solver.
See cert-manager's documentation for http-01 and dns-01 solvers.
We're going to have cert-manager solve dns-01 ACME challenges.
So, it will need to be able to manage DNS entries.
Let's create a Google Cloud Platform service account with the roles/dns.admin role. Replace the PROJECT_ID here with your own:
Finally, let's create an cert-manager Issuer to perform dns-01 ACME challenges. Make a new file called acme-issuer.yaml:
solvers:-dns01:cloudDNS:# Your Google Cloud Platform project ID:project: step-cas-test
# Your Google CloudDNS zone name we will use for DNS01 challenges:hostedZoneName: step-cas-internal
Replace the values for email, server URL, project and hostedZoneName with your own. Your Smallstep ACME endpoint will always take the form of https://[your CA hostname]/acme/acme/directory.
$ kubectl apply -f acme-issuer.yaml
You now have an automated ACME certificate manager running inside your Kubernetes cluster.
5. Issue a test certificate
Let's get a test certificate from our ACME CA, using a Certificate object. Create a file called tls-certificate.yaml:
Replace the dnsNames value with a DNS name that's inside your zone.
$ kubectl apply -f tls-certificate.yaml
You can check the status with kubectl get certificaterequest or kubectl describe certificate:
$ kubectl get certificaterequest
NAME READY AGE
k8s-internal-nzbnm True 7s
$ kubectl describe certificate k8s-internal
Creation Timestamp: 2020-11-03T23:06:46Z
Secret Name: k8s-internal-tls
Last Transition Time: 2020-11-03T23:11:01Z
Message: Certificate is up to date and has not expired
Not After: 2020-11-04T23:11:01Z
Not Before: 2020-11-03T23:11:01Z
Renewal Time: 2020-11-04T15:11:01Z
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Issuing 10m cert-manager Issuing certificate as Secret does not exist
Normal Generated 10m cert-manager Stored new private key in temporary Secret resource "k8s-internal-g79jq"
Normal Requested 10m cert-manager Created new CertificateRequest resource "k8s-internal-nzbnm"
Normal Issuing 9m33s cert-manager The certificate has been successfully issued
As you can see, cert-manager will automatically renew the certificate when approximately 2/3 of its lifetime has elapsed.
That's it! You now have automated, short-lived certificates for your Kubernetes cluster. There are many use cases for X.509 certificates issued through cert-manager.