Certificates

Certificate management in the cluster will be done with Cert Manager , a graduated CNCF project.

Issuers

In order to manage certificates with cert-manager, first an issuer needs to be configured. For exact values to configure please see the Cert Manager documentation. We will use the ACME issuer for the certificates backed by Let's Encrypted as our default issuer. We will also use the DNS01 challenge validation as our default challenge validation.

Azure DNS Issuer with ACME Example

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
  namespace: <example-issuer-namespace>
spec:
  acme:
    email: <email>
    server: <acme-server-url>
    privateKeySecretRef:
      name: issuer-account-key
    solvers:
    - dns01:
        azureDNS:
          hostedZoneName: <hosted-zone-name>
          resourceGroupName: <hosted-zone-resource-group-name>
          subscriptionID: <hosted-zone-subscription-id>
          environment: AzurePublicCloud
          managedIdentity:
            clientID: <managed-identity-client-id>

When the cluster ingress is deployed, we annotate the gateway with the name of the issuer to use for terminating the HTTPS traffic on the gateway. This will use the issuer here to generate certificates for the TLS termination without the need for intervention.

Certificates

It is also possible to create certificates that you can store back in Azure Key vault for other services to consume. This can be done with using the Cert Manager Certificate resource and combining that with secrets pushing.

Example Cert Manager Certificate

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: <example-issuer-namespace>
spec:
  # Secret names are always required.
  secretName: example-com-tls

  # secretTemplate is optional. If set, these annotations and labels will be
  # copied to the Secret named example-com-tls. These labels and annotations will
  # be re-reconciled if the Certificate's secretTemplate changes. secretTemplate
  # is also enforced, so relevant label and annotation changes on the Secret by a
  # third party will be overwriten by cert-manager to match the secretTemplate.
  secretTemplate:
    annotations:
      my-secret-annotation-1: "foo"
      my-secret-annotation-2: "bar"
    labels:
      my-secret-label: foo

  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048

  # keystores allows adding additional output formats. This is an example for reference only.
  keystores:
    pkcs12:
      create: true
      passwordSecretRef:
        name: example-com-tls-keystore
        key: password
      profile: Modern2023

  duration: 2160h # 90d
  renewBefore: 360h # 15d

  isCA: false
  usages:
    - server auth
    - client auth

  subject:
    organizations:
      - cert-manager

  # The literalSubject field is exclusive with subject and commonName. It allows
  # specifying the subject directly as a string. This is useful for when the order
  # of the subject fields is important or when the subject contains special types
  # which can be specified by their OID.
  #
  # literalSubject: "O=jetstack, CN=example.com, 2.5.4.42=John, 2.5.4.4=Doe"

  # At least one of commonName (possibly through literalSubject), dnsNames, uris, emailAddresses, ipAddresses or otherNames is required.
  dnsNames:
    - example.com
    - www.example.com
  emailAddresses:
    - [email protected]
  ipAddresses:
    - 192.168.0.5

  # Issuer references are always required.
  issuerRef:
    name: example-issuer
    kind: Issuer