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.