External CA and Ingress Controller Example

This section describes how to configure an application to use Ingress Controller to both expose its TLS-based service and to use an External CA for signing CERTIFICATEs.

NOTE that alternatively an Internal CA could be used with an Ingress Controller -based solution as well.

Prerequisites

This example requires that:

• The LetsEncrypt CA in the public internet can send an http01 challenge to the FQDN of the StarlingX’s floating OAM IP Address.

• The StarlingX has access to the kuard demo application at gcr.io/kuar-demo/kuard-amd64:blue.

• Ensure that your StarlingX administrator has shared the local registry’s public repository’s credentials/secret with the namespace where you will create certificates. This will allow you to leverage the registry.local:9001/public/cert-manager-acmesolver image. See Set up a Public Repository in Local Docker Registry.

• Ensure that your StarlingX administrator has enabled use of the cert-manager apiGroups in your RBAC policies.

• Ensure that your StarlingX administrator has opened port 80 and 443 in GlobalNetworkPolicy.

Procedure

1. Create a LetsEncrypt ISSUER in the default namespace by applying the following manifest file.

   apiVersion: cert-manager.io/v1alpha3
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-prod
     namespace: default
   spec:
     acme:
       # The ACME server URL
       server: https://acme-v02.api.letsencrypt.org/directory
       # Email address used for ACME registration
       email: dave.user@hotmail.com
       # Name of a secret used to store the ACME account private key
       privateKeySecretRef:
         name: letsencrypt-prod
       # Enable the HTTP-01 challenge provider
       solvers:
       - http01:
           ingress:
             class: nginx
   

2. Create a deployment of the kuard demo application (https://github.com/kubernetes-up-and-running/kuard) with an INGRESS using cert-manager by applying the following manifest file:

   Where both starlingx.mycompany.com and kuard.starlingx.mycompany.com are FQDNs that map to the OAM Floating IP of StarlingX.

   (You should substitute these for FQDNs for the StarlingX installation.)

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: kuard
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: kuard
     template:
       metadata:
         labels:
           app: kuard
       spec:
         containers:
         - name: kuard
           image: gcr.io/kuar-demo/kuard-amd64:blue
           imagePullPolicy: Always
           ports:
           - containerPort: 8080
             protocol: TCP
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: kuard
     labels:
       app: kuard
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     selector:
       app: kuard
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       cert-manager.io/issuer: "letsencrypt-prod"
     name: kuard
   spec:
     ingressClassName: nginx
     tls:
     - hosts:
       - kuard.starlingx.mycompany.com
       secretName: kuard-ingress-tls
     rules:
       - host: kuard.starlingx.mycompany.com
         http:
           paths:
           - backend:
               service:
                 name: kuard
                 port:
                   number: 80
             path: /
             pathType: Prefix
   

3. Access the kuard demo from your browser to inspect and verify that the certificate is signed by LetsEncrypt CA. For this example, the URL would be https://kuard.starlingx.mycompany.com.