Transport Layer Security (TLS)

The certificate must be stored in ACM in the same Region and AWS account as the mesh endpoint that will use the certificate. The CA's certificate does not need to be in the same AWS account, but it does still need to be in the same Region as the mesh endpoint. If you don't have an AWS Private CA, then you must create one before you can request a certificate from it. For more information about requesting a certificate from an existing AWS Private CA using ACM, see Request a Private Certificate. The certificate cannot be a public certificate.

The private CAs that you use for TLS client policies must be root user CAs.

To configure a virtual node with certificates and CAs from AWS Private CA, the principal (such as a user or role) that you use to call App Mesh must have the following IAM permissions:

You can add these permissions to an existing IAM policy that is attached to a principal or create a new principal and policy and attach the policy to the principal. For more information, see Editing IAM Policies, Creating IAM Policies, and Adding IAM Identity Permissions.

When you enable proxy authorization for the Envoy Proxy that a mesh endpoint represents, the IAM role that you use must be assigned the following IAM permissions:

You can distribute certificates to Envoy using the file system. You can do this by making the certificate chain and the corresponding private key available on the file path. That way, these resources are reachable from the Envoy sidecar proxy.

Envoy fetches secrets like TLS certificates from a specific endpoint through the Secrets Discovery protocol. For more information about this protocol, see Envoy's SDS documentation.

App Mesh configures the Envoy proxy to use a Unix Domain Socket that's local to the proxy to serve as the Secret Discovery Service (SDS) endpoint when SDS serves as the source for your certificates and certificate chains. You can configure the path to this endpoint by using the APPMESH_SDS_SOCKET_PATH environment variable.

You can use any sidecar implementation of the SDS API, including existing toolchains like SPIFFE Runtime Environment (SPIRE). SPIRE is designed to enable the deployment of mutual TLS authentication between multiple workloads in distributed systems. It attests the identity of workloads at runtime. SPIRE also delivers workload-specific, short-lived, and automatically rotating keys and certificates directly to workloads.

You should configure the SPIRE Agent as an SDS provider for Envoy. Allow it to directly supply Envoy with the key material that it needs to provide mutual TLS authentication. Run SPIRE Agents in sidecars next to Envoy proxies. The Agent takes care of re-generating the short-lived keys and certificates as required. The Agent attests Envoy and determines which service identities and CA certificates that it should make available to Envoy when Envoy connects to the SDS server exposed by the SPIRE Agent.

During this process, service identities and CA certificates are rotated, and updates are streamed back to Envoy. Envoy immediately applies them to new connections without any interruptions or downtime and without the private keys ever touching the file system.

When a client policy is enforcing the use of TLS, and one of the ports in the client policy matches the port of the server's policy, the client policy is used to configure the TLS validation context of the client. For example, if a virtual gateway's client policy matches a virtual node's server policy, TLS negotiation will be attempted between the proxies using the settings defined in the virtual gateway's client policy. If the client policy does not match the port of the server's policy, TLS between the proxies may or may not be negotiated, depending on the server policy's TLS settings.

If the client has not configured a client policy, or the client policy does not match the port of the server, App Mesh will use the server to determine whether or not to negotiate TLS from the client, and how. For example, if a virtual gateway has not specified a client policy, and a virtual node has not configured TLS termination, TLS will not be negotiated between the proxies. If a client has not specified a matching client policy, and a server has been configured with TLS modes STRICT or PERMISSIVE, the proxies will be configured to negotiate TLS. Depending on how the certificates have been provided for TLS termination, the following additional behavior applies.

You can optionally specify a list of Subject Alternative Names (SANs) to trust. SANs must be in the FQDN or URI format. If SANs are provided, Envoy verifies that the Subject Alternative Name of the presented certificate matches one of the names on this list.

If you don't specify SANs on the terminating mesh endpoint, the Envoy proxy for that node doesn't verify the SAN on a peer client certificate. If you don't specify SANs on the originating mesh endpoint, the SAN on the certificate provided by the terminating endpoint must match the mesh endpoint service discovery configuration.

For more information, see App Mesh TLS: Certificate requirements.