You are on page 1of 4

Cloudflare k8s

0. DNS server to cloudflare

1. Setup ClusterIssuer
Once it's installed you need to create a ClusterIssuer which can then be used when
requesting certificates from let's encrypt.

$ more cert-clusterissuer.yaml
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-stg
namespace: cert-manager
spec:
acme:
email: my_letsencrypt_email@mydom.com
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: le-issuer-acct-key
solvers:
- dns01:
cloudflare:
email: my_cloudflare_email@mydom.com
apiTokenSecretRef:
name: cloudflare-api-token-secret
key: api-token
selector:
dnsZones:
- 'mydomdom.org'
- '*.mydomdom.org'
Deploy that, notice it'll get deployed into the same namespaces as cert-manager:

$ kubectl apply -f cert-clusterissuer.yaml


$ kubectl -n cert-manager get clusterissuers
NAME READY AGE
letsencrypt-stg True 53m
2. Setup Cloudflare API Token Secret
Deploy your Cloudflare API token into a secret, again put it into the cert-manager
namespace:

$ more cloudflare-api-token.yaml
apiVersion: v1
kind: Secret
metadata:
name: cloudflare-api-token-secret
namespace: cert-manager
type: Opaque
stringData:
api-token: <my cloudflare api token key>

$ kubectl -n cert-manager -f cloudflare-api-token.yaml


3. Create a test Certificate
Now attempt to request the generation of a certificate from let's encrypt:

$ more test-certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: le-test-mydomdom-org
namespace: cert-manager
spec:
secretName: le-test-mydomdom-org
issuerRef:
name: letsencrypt-stg
kind: ClusterIssuer
commonName: 'le-test.mydomdom.org'
dnsNames:
- "le-test.mydomdom.org"
$ kubectl -n cert-manager apply -f test-certificate.yaml
4. Debugging Certificate Creation
You can then watch the request as it flows through the various stages. I believe the flow
is certificates -> certificaterequests -> orders -> challenges.

NOTE: Knowing this general flow was hugely helpful for me in terms of understanding
where a request was failing within kubernetes as I was attempting to debug it.

When debugging you'll typically want to do kubectl -n cert-manager <stage> -A to see a list of all
the outstanding resources within that stage. Keep in mind that after a challenge is fulfilled it'll
no longer show up within the output of kubectl -n cert-manager challenges.
Also keep in mind that any DNS entries created to fulfill the challenge stage will typically
have their TTL set to ~2min so if you go looking in your Cloudflare UI and do not see them,
they likely already timed out and rolled off.

For e.g.:

Result:
References:

https://sysadmins.co.za/https-using-letsencrypt-and-traefik-with-k3s/

https://stackoverflow.com/questions/63346728/issuing-certificate-as-secret-does-not-exist

You might also like