There are 4 types of certificates that TSB operator needs to be aware of:
- TSB Internal Certificates - Certificates that are used for TSB internal components to trust each other.
- Application TLS Certificates - Certificates that will be available to the application user web-browser or tools.
- Intermediate Istio CA Certificates - Intermediate CA certificate for issuing Istio workload leaf certificates.
- Workload Leaf Certificates - Certificates issued to every proxy and gateway.
These certificates and their relation to TSB components and your application are shown in the following image
TSB Internal Certificates
TSB's global control plane (XCP) distributes configuration from the management plane to control plane clusters. XCP is composed of XCP central and XCP edge. XCP central is deployed in the management plane where TSB server interact with it through a component called MPC. XCP edge is deployed in each of the onboarded clusters where user applications run. TSB internal certificates (highlighted green in image above) are used for securing communication between XCP central, XCP edge, MPC component.
There are two methods supported for secure communication: mTLS and JWT with TLS. Certificates that you need to create will depend on the authentication method that you use. Details on certificate requirements for these components are available here. You will need to prepare these certificates before deploying TSB.
Application TLS Certificates
Application TLS certificates (highlighted purple in image above) are used by client applications that should trust to access the application.
Every publicly accessible HTTPS service exposed by your application should have TLS certificates mounted as Kubernetes secrets. TLS certificates for your application must be available when the application is published.
While technically not an "application" you will also need to set up the TLS certificates for the command line tools to access the TSB Management Plane, as well as for you to access the TSB UI via a web browser. TSB TLS certificate must be available before TSB deployment.
Intermediate Istio CA Certificates
Intermediate Istio CA certificates (highlighted cyan in image above) is mounted in
cacerts secret on every Control Plane so that Istio workloads leaf certificates can be issued. By default
istiod acts as a leaf certificate issuer by using Intermediate CA certificate to sign leaf certificates.
The certificate should be signed (or verifiable) by the enterprise Root CA for intra-service communication. The cluster specific Intermediate CA should be available during TSB Control Plane deployment.
For a demo example on setting up Intermediate Istio CA in multi clusters setup, refer to Istio documentation.
For a production environment, It is highly recommended to use production ready PKI infrastructure such as the following, and follow the industry best practices:
- Using AWS Private CA as enterprise CA to create Intermediate CAs (not an automated process)
- Integrate existing CA (e.g. AWS Certificate Manager, HashiCorp Vault) with Kubernetes CSR API or Istio CSR. To learn more about how to use Istio CSR to integrate with external CA refer to here.
Usually the enterprise security team is in charge of these types of certificates.
Workload Leaf Certificates
Leaf certificates (highlighted yellow in image above) are issued to every proxy and gateway (or per workload). These are short lived certificates (by default 24 hour and can be changed by setting using
defaultWorkloadCertTTL in Control Plane CR).
It's important to understand that these certificates are automatically rotated and are not managed by TSB. Istiod is responsible for issuing and rotating the certificates using the Enterprise Intermediate certificates.