Here is a description of the different paths through which external clients, internal components, app containers, and app services communicate in VMware Tanzu Application Service for VMs (TAS for VMs), and how the platform uses Transport Layer Security (TLS) protocols to secure these communications.
Types of network communication in TAS for VMs
This section describes the different types of network communication in TAS for VMs and how they are secured with TLS.
Within an TAS for VMs deployment, TLS secures connections between components like the BOSH Director and Service instances. TAS for VMs components also use TLS connections to secure communications with external hardware, such as customer load balancers.
Between an external client and an app
The following diagram illustrates the flow of communication from a client making a request to an app. The Client Request goes to the External Load Balancer, and then through Gorouter to the app.
The following table describes each component involved in receiving a client request and where their certificates for TLS termination originate:
| Component | Certificate Source |
|---|---|
| External Load Balancer | Enterprise root certificate authority (CA). |
| Gorouter | Enterprise root CA. |
| App | Tanzu Operations Manager root CA dedicated to app instance identity. |
For more information, see App Instance Container Identity Credentials. |
Between platform components
The following diagram illustrates communication between platform components, secured with TLS. The BOSH Director, with CredHub, feeds into Loggregator and Cloud Controller, which also communicate with each other. Loggregrator and Cloud Controller feed into Deigo Cell and Gorouter, respectively, and all of the components communicate with each other.
The CredHub instance in BOSH generates certificates for all components in Tanzu Operations Manager. The certificates are self-signed by default. To issue certificates signed by your enterprise, you can add a custom CA to CredHub.
Traffic between the Gorouter and Windows stemcells is not encrypted with TLS.
Component communication details
These topics list the paths, ports, and protocols that subsystems within TAS for VMs use to communicate:
Between apps
The following diagram illustrates TLS communications between apps running on TAS for VMs:
In the example shown, the frontend-blue and frontend-green apps both receive client requests, but only the frontend-green app is allowed to communicate with the backend app.
Apps can communicate with each other over TLS using certificates generated by an Tanzu Operations Manager root CA dedicated to app instance identity. For more information, see App Instance Container Identity Credentials.
Developers specify which apps are allowed to communicate using container networking policies. For more information, see Configuring Container-to-Container Networking.
Between apps and on-platform services
The following diagram illustrates TLS communication between apps and managed, on-platform services. It uses Cloud Cache as an example of a managed service.
BOSH CredHub issues certificates to the VMware Tanzu GemFire components. For the app, the developer must retrieve a copy of this certificate using the CredHub API and place it in the trust store for the app. For more information, see the VMware Tanzu GemFire documentation.
Separately, TAS for VMs Runtime CredHub might store credentials for the app to access a service over the TLS connection, adding a second layer of security. For more information, see Securing Services Instance Credentials with Runtime CredHub.
Between apps and external services
The following diagram illustrates communications between apps and external, brokered services secured with TLS:
The developer must retrieve the certificate from the external service and provide it to their app. One way to do this is by placing the certificate in Runtime CredHub and editing your app to consume the certificate through CredHub Service Broker. For more information, see the CredHub Service Broker documentation.
App instance container identity credentials
Each app instance container in TAS for VMs has its own identity credentials. This section describes how to understand and use these credentials.
About App instance identity credentials
To learn about app instance identity credentials, see the table below:
| Attribute | Description |
|---|---|
| Purpose |
|
| Type |
|
| Location |
|
| Properties of certificate |
|
| Contents of certificate file |
|
| Issuing authority |
|
Using the credentials
If you want to enable secure TLS communications from an app using container instance identity credentials, ensure that you:
-
Add the credentials to your development stack configuration: The credentials must be present in your development stack configuration for your app to use them. You can retrieve the credentials through following environment variables, which Tanzu Operations Manager sets to the locations of key and certificate files.
Where `APP-NAME` is the name of your app.Credential/Keypair Element Environment Variable Command to Retrieve Credential Value Certificate Chain CF_INSTANCE_CERTcf ssh APP-NAME -c 'cat $CF_INSTANCE_CERT'Private Key CF_INSTANCE_KEYcf ssh APP-NAME -c 'cat $CF_INSTANCE_KEY' -
Reload the credential files before they expire: Tanzu Operations Manager rotates the credentials shortly before the current certificate expires. Apps that use these credentials must reload the certificate and key file contents either periodically or in reaction to filesystem watcher events.
-
Configure external clients or servers to trust the root CA: To enable secure TLS communication between an app and a client or server external to Tanzu Operations Manager, you must configure the external client or server to trust the CA that issues app instance container identity credentials. For more information, see the Issuing Authority row of the table in About App Instance Identity Credentials.
Additional information
For more information about instance identity credentials, see Rotating Instance Identity CA Certificates in the diego-release repository on GitHub.
TLS cipher suites
By default, Tanzu Operations Manager uses a limited set of cipher suites to secure its internal communications. However, some components used in Tanzu Operations Manager, like the Gorouter, may support additional TLS cipher suites to accommodate older clients outside of Tanzu Operations Manager.
The AWS Classic load balancer does not support the recommended TLS cipher suites. For details and mitigations, see TLS Cipher Suite Support in Securing Traffic into TAS for VMs.
For components that allow you to configure TLS cipher suites, only specify the TLS cipher suites that you need.
TLS cipher suite recommendations
The default version of TLS is TLS v1.2. VMware recommends using this version.
The TLS cipher suites VMware recommends using within Tanzu Operations Manager are:
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Gorouter configuration
As part of your TAS for VMs networking configuration, you must specify the TLS cipher suites that the Gorouter uses to secure its communications. Only specify the cipher suites that you need.
The TLS cipher suites VMware recommends for the Gorouter are:
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-RSA-AES256-GCM-SHA384
You can specify other cipher suites and a different minimum version of TLS support if your deployment requires it. For a list of other cipher suites and other versions of TLS that are optionally supported by the Gorouter, see TLS Cipher Suite Support in Securing Traffic into TAS for VMs.
For instructions on how to configure the TLS cipher suites for the Gorouter, see Configure Networking in Configuring TAS for VMs.
