Plan ingress certificates inventory in Tanzu Application Platform

This topic tells you how to plan for TLS certificates in Tanzu Application Platform (commonly known as TAP).

The effective number of ingress endpoints can vary widely, depending on the installation profile, excluded packages, and end-user-facing resources such as Workload and AuthServer. As a result, the number of TLS certificates is not fixed and is a function of the platform’s configuration and tenancy.

Ingress refers to any resource that facilitates ingress, such as core Ingress and Contour’s HTTPProxy.

Wildcards

You can use wildcard certificates, but Tanzu Application Platform does not offer support. Wildcard certificates require component-level configuration.

You can use a mixed approach for configuring TLS for components. For example, you can use a shared ingress issuer, but override TLS configuration for some components while using wildcard certificates for others.

When using wildcard certificates the approach differs between components that have a fixed set of ingress endpoints and those that have a variable set of ingress endpoints.

Components with ingress endpoints can have a fixed number or variable number of ingress endpoints:

  • Components with a fixed set of ingress endpoints can receive a reference to the wildcard certificate’s Secret and an ingress domain, such as Tanzu Developer Portal.

  • Components with a variable set of ingress endpoints usually offer Kubernetes APIs that create ingress resources. These components allow configuration of domain templating so that wildcard certificates can be used. For example, Cloud Native Runtimes and Application Single Sign-On.

Ingress support for components

Use the following table to help with the planning and accounting of TLS certificates. For a full list of components and the profiles supported for each component, see Components and installation profiles for Tanzu Application Platform.

Package name Ingress purpose Supports ingress issuer Supports wildcards Number of ingress SANs
api-portal.tanzu.vmware.com Serves the API portal No Yes 1 api-portal.INGRESS-DOMAIN
cnrs.tanzu.vmware.com Instances of Knative’s Service have ingress Yes Yes Number of Services SANs depend on the component’s domain_template
metadata-store.apps.tanzu.vmware.com Serves the Supply Chain Security Tools store Yes Yes 1 metadata-store.INGRESS-DOMAIN
spring-cloud-gateway.tanzu.vmware.com Instances of SpringCloudGateway have ingress No Yes Number of SpringCloudGateways See Using an Ingress Resource in the Spring Cloud Gateway documentation
sso.apps.tanzu.vmware.com Instances of AuthServer have ingress Yes Yes Number of AuthServers Depends on the component’s domain_template
tap-gui.tanzu.vmware.com Serves the platform-internal developer and service portal Yes Yes 1 tap-gui.INGRESS-DOMAIN

The SANs is configurable for components in the following two ways:

  • Components that install a single ingress resource in the form of COMPONENT.DOMAIN-NAME, such as Tanzu Developer Portal
  • Components that install an ingress resource per API instance that gets templated from a domain_template feeding DOMAIN-NAME, such as cnrs.tanzu.vmware.com and sso.apps.tanzu.vmware.com
check-circle-line exclamation-circle-line close-line
Scroll to top icon