Skip to main content
Version: 1.11.0

Set up and use certificate issuers

Epinio comes with many cert-manager ClusterIssuers for creating certificates. By default, it installs the issuers epinio-ca and selfsigned-issuer. If requested it also installs either letsencrypt-staging or letsencrypt-production, to create certificates issued from Let's Encrypt.

  • epinio-ca (default)
  • selfsigned-issuer (internal)
  • letsencrypt-[staging|production] (optional)

You use the specified issuer for both Epinio API endpoint and workloads (that is, the pushed applications).

Choosing a different issuer​

When installing Epinio with helm, you can choose between those issuers by using the global.tlsIssuer helm variable.

It's also possible to create a cert-manager cluster issuer in the cluster, before installing Epinio, and referencing it by name when installing, using global.customTlsIssuer.

When using either letsencrypt-staging or letsencrypt-production then use the global.tlsIssuerEmail helm variable to set an email address for the reception of the certificate notification e-mails sent by that issuer.

Cluster issuer for ACME DNS challenge​

For an example, to use Let's Encrypt with a DNS challenge, which supports wildcards and private IP addresses, create this cluster issuer after installing cert-manager:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: dns-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: example-issuer-account-key
solvers:
- dns01:
cloudflare:
email: user@example.com
apiKeySecretRef:
name: cloudflare-apikey-secret
key: apikey
selector:
dnsNames:
- 'example.com'
- '*.example.com'

This uses the Let's Encrypt staging endpoint for testing. There's more information in the cert-manager ACME documentation.

You then install Epinio with the global.tlsIssuer pointing to the new cluster issuer:

helm install epinio epinio/epinio --set global.tlsIssuer=dns-staging ...(other values here)

Cluster issuer for an existing private CA​

According to the instructions from cert-manager, follow these steps:

Create secret with CA certificate and key​

If you don't already have a private CA, use a tool like openssl or easy-rsa to create it.

The following one-liner creates a CA:

openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout example.key -out example.crt -subj "/CN=*.yourdomainhere.org"

Make sure the CN field matches the domain you are planning to use with Epinio.

Create a Kubernetes secret from the CA, in the cert-manager namespace.

kubectl create secret -n cert-manager tls private-ca-secret \
--cert=./example.crt --key=./example.key

The cert-manager documentation has more details about this.

Create ClusterIssuer​

Then create the cluster issuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: private-ca
spec:
ca:
secretName: private-ca-secret

Install Epinio​

Use the global.tlsIssuer variable to choose your cluster issuer:

helm install --set global.tlsIssuer=private-ca epinio epinio/epinio --global.domain=epinio.yourdomainhere.org

Background on Cert manager and issuers​

Cert manager watches for a certificate resource and uses the referenced cluster issuer to generate a certificate. The certificate is stored in a secret, in the namespace the certificate resource was created in. An Ingress resource can then use that secret to set up TLS.

Example:

  1. The Epinio installation creates a certificate resource in the Epinio namespace

    apiVersion: cert-manager.io/v1alpha2
    kind: Certificate
    metadata:
    name: epinio
    namespace: epinio
    spec:
    commonName: epinio.172.27.0.2.omg.howdoi.website
    dnsNames:
    - epinio.172.27.0.2.omg.howdoi.website
    issuerRef:
    kind: ClusterIssuer
    name: epinio-ca
    secretName: epinio-tls
  2. cert-manager creates the 'epinio-tls' secret, using the referenced cluster issuer 'epinio-ca'

    apiVersion: v1
    kind: Secret
    type: kubernetes.io/tls
    metadata:
    annotations:
    cert-manager.io/alt-names: epinio.172.27.0.2.omg.howdoi.website
    cert-manager.io/certificate-name: epinio
    cert-manager.io/common-name: epinio.172.27.0.2.omg.howdoi.website
    cert-manager.io/ip-sans: ""
    cert-manager.io/issuer-group: ""
    cert-manager.io/issuer-kind: ClusterIssuer
    cert-manager.io/issuer-name: epinio-ca
    cert-manager.io/uri-sans: ""
    name: epinio-tls
    namespace: epinio
    data:
    ca.crt: ...
    tls.crt: ...
    tls.key: ...
  3. Epinio creates an ingress resource

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
    annotations:
    kubernetes.io/ingress.class: traefik
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
    traefik.ingress.kubernetes.io/router.middlewares: epinio-epinio-api-auth@kubernetescrd
    traefik.ingress.kubernetes.io/router.tls: "true"
    labels:
    app.kubernetes.io/name: epinio
    name: epinio
    namespace: epinio
    spec:
    rules:
    - host: epinio.172.27.0.2.omg.howdoi.website
    http:
    paths:
    - backend:
    service:
    name: epinio-server
    port:
    number: 80
    path: /
    pathType: ImplementationSpecific
    tls:
    - hosts:
    - epinio.172.27.0.2.omg.howdoi.website
    secretName: epinio-tls

Epinio push​

The same is true for applications, epinio push creates a certificate in the app's workspace and cert-manager creates a secret for the app's ingress.