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
.
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.
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:
COMPONENT.DOMAIN-NAME
, such as Tanzu Developer Portaldomain_template
feeding DOMAIN-NAME
, such as cnrs.tanzu.vmware.com
and sso.apps.tanzu.vmware.com