Trusted certificates are necessary for any web application today. Verifying that communication is encrypted and secure is table stakes. Let’s Encrypt is one of the most popular Certificate Authorities providing TLS certificates to millions of users. Using cert-manager with VMware Tanzu Community Edition makes securing applications a lot easier.
Contour is a Layer 7 application load balancer that comes as a package with Tanzu Community Edition. Getting started is easy, but let’s take the documentation a bit further and use Let’s Encrypt as a cluster issuer with cert-manager.
First, get Contour deployed (make sure to check with the documentation for the latest version). This is a single line experience and once it’s complete you will be presented with an IP Address (or DNS address with AWS ELB) tied to the envoy service.
$ tanzu package install contour \ --package-name contour.community.tanzu.vmware.com \ --version 1.18.1
$ tanzu package install cert-manager --package-name cert-manager.community.tanzu.vmware.com --version 1.5.3
Cert-manager requires a ClusterIssuer to create and supply the TLS certificates. We are going to create two ClusterIssuers: one for Let’s Encypt staging and another for production. Staging has no rate limit enforcements, while production is for using full TLS-encrypted communication. Much of this is documented in Contour’s open source documentation. Be sure that the emails referenced can be contacted.
cat <<EOF | kubectl apply --filename - apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-staging namespace: cert-manager spec: acme: email: email@example.com privateKeySecretRef: name: letsencrypt-staging server: https://acme-staging-v02.api.letsencrypt.org/directory solvers: - http01: ingress: class: contour EOF
kubectl apply -f - <<EOF apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod namespace: cert-manager spec: acme: email: firstname.lastname@example.org privateKeySecretRef: name: letsencrypt-prod server: https://acme-v02.api.letsencrypt.org/directory solvers: - http01: ingress: class: contour EOF
Now, let’s deploy a simple NGINX container:
$ kubectl create deployment my-nginx --image=nginx
At this point, the NGINX server is running, but there is no way to access it since it hasn’t been exposed externally. The next stage is to create a generic Kubernetes service but without specifying a type (such as LoadBalancer). This will create a service that we can tie to the ingress controller:
$ kubectl create deployment nginx --image nginx $ cat <<EOF | kubectl apply --filename - apiVersion: v1 kind: Service metadata: name: my-nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: my-nginx EOF
To do some initial testing, let's use the Let’s Encrypt staging server on an Ingress rule. Notice the annotations section:
$ cat <<EOF | kubectl apply --filename - apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-nginx annotations: cert-manager.io/cluster-issuer: letsencrypt-staging ingress.kubernetes.io/force-ssl-redirect: "true" kubernetes.io/ingress.class: contour kubernetes.io/tls-acme: "true" spec: tls: - secretName: my-nginx-tls hosts: - my-nginx.mydomain.com rules: - host: my-nginx.mydomain.com http: paths: - pathType: Prefix path: "/" backend: service: name: my-nginx port: number: 80 EOF
We’re almost there. To access this by DNS, a record needs to be created in your DNS server that points to the address of the Envoy proxy from the first step. For AWS, you will need to create a CNAME record that points to the ELB resource. vSphere, Azure, and other clouds will have an A record that points to the IP. Anything internal can be done at the DNS server or modified with /etc/hosts on your local machine.
After the DNS record propagation takes effect, we can access our application at https://my-nginx.mydomain.com and we should be presented with a certificate error, which is expected.
After accepting the certificate, we can see “Not Secure” in the browser url bar. This is the expected behavior of using the staging certificate.
When you’re ready to go into production and make the certificate error disappear, edit the Ingress rule and set the cluster-issuer to letsencrypt-prod. This will reissue the certificates using the new issuer. Close the tab and reopen to see the error warning disappear.
About the AuthorMore Content by Kendrick Coleman