Application security, especially today, is always top-of-mind. Part of the gamut of processes, tools and practices that go into making an application secure is securing the transport layer - how the application talks to clients, other parts of the application and backend systems.
It has generally been the case that when securing the transport layer that TLS would be used with whatever protocol you are using for communication - say HTTP for REST-style applications, or indeed, just any app exposing a web-page as a frontend or API.
It has also generally been the case that when enabling TLS on HTTP endpoints for internal applications that self-signed certificates are used, mainly because it is easier, quicker (and previously, cheaper) to have an internal Certificate Authority (CA) issue them for your application and manually attach them to the service.
However, it doesn’t have to be the case that this is all manual, nor that you even need to run an internal CA in order to issue certs!
Configuring TAP for Auto-TLS
With TAP 1.4 automatic issuance and provisioning of certificates is now built-in using the upstream cert-manager project, it’s now possible to have any of the supported backends issue certificates on your behalf, in this example, let’s take a look at Let’s Encrypt - a public service providing valid, publicly signed certificates.
The only thing needed from the Operator’s side is to create a
ClusterIssuer object in Kubernetes that specifies the upstream service to use for certificate issuance as well as the email address in your org responsible for certs, in the below example we are using Let’s Encrypt to get publicly signed certs for our services:
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-live spec: acme: email: firstname.lastname@example.org server: https://acme-v02.api.letsencrypt.org/directory preferredChain: "ISRG Root X1" privateKeySecretRef: name: issuer-account-key solvers: - http01: ingress: class: contour
Note: If you are not exposing your TAP instance to the internet - then obviously you can’t use the
http01 solver for domain ownership verification, instead - have a look into
dns01 which works with many of the more “modern” DNS providers, like Cloudflare.
Aside from the possible change to
dns01 if you aren’t publicly exposing your application endpoints, you’ll have to update the email address and it will be ready to go!
Then in your TAP
values.yaml file that you use for install, add a key to the
shared section that points to this
shared: ingress_issuer: letsencrypt-live
At this point we are ready to update our TAP configuration, so roll out the change using
tanzu package installed update tap -p tap.tanzu.vmware.com -v 1.4.0 --values-file values.yml -n tap-install
Issuing Certs with TAP
Now that TAP knows how to request and configure certs on any ingresses - the effects you will see are twofold, firstly, the TAP core components are all now using Let’s Encrypt issued certificates so visiting your TAP Portal you’ll find it to now be using those trusted certs.
Additionally, any workloads you deploy through the platform will also be issued their own certs, below is an application we have deployed to TAP and ran through the Supply Chain.
For more information on what’s new in Tanzu Application Platform 1.4 check out the release blog, for technical getting started and install information check out the documentation or for a higher level overview, check out out the TAP product page.
To ask questions, reach out to @mylesagray on Twitter.