The communication between services is encrypted through sidecar proxies using mutual TLS. Each service is provided an identity through the SPIFFE X.509 certificate (please refer to Chapter 5, Service Mesh Interface and SPIFFE, for a discussion on SPIFFE). Since the services are not tied to fixed IP addresses, the SPIFFE-based identity can be used to connect and accept requests between SPIFFE-compliant services.

Consul has a built-in Certificate Authority, through which it assigns leaf certificates to sidecar proxies. These sidecar proxies can be configured for upstream configuration to specify alternate data centers that services can access for high availability. The CA federation can be enabled between multiple data centers. The CA federation helps the alternate data center to continue issuing leaf SPIFFE X509 certificates in the case of WAN disruptions. The root key rotation and the signing of CSR for an intermediate certificate can be performed by any data center. Mutual TLS provides security in a zero-trust network through in-transit encryption and authorization.

In this section, we will explore the mutual TLS implementation that happens automatically through the Consul Connect service mesh. Developers do not have to write a single line of code to enable encrypted communication between services. This allows services to run securely in a zero-trust network environment without the use of a dedicated VPN. To implement mTLS, follow these steps:

1. Check the log of the sidecar proxy for TLS. By doing this, you will see tls shown against every communication:

$ kubectl -n consul logs counting -c consul-connect-envoy-sidecar | grep tls
[2019-12-23 16:29:53.442][1][info][main] [source/server/server.cc:215] filters.listener: envoy.listener.original_dst,envoy.listener.original_src,envoy.listener.proxy_protocol,envoy.listener.tls_inspector
[2019-12-23 16:29:53.442][1][info][main] [source/server/server.cc:225] transport_sockets.downstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls
[2019-12-23 16:29:53.442][1][info][main] [source/server/server.cc:228] transport_sockets.upstream: envoy.transport_sockets.alts,envoy.transport_sockets.tap,raw_buffer,tls

2. By default, the time to live of the leaf certificates is 72 hours:

$ curl -s http://consul-server.consul.svc.cluster.local:8500/v1/connect/ca/configuration | json_reformat
{
    "Config": {
        "LeafCertTTL": "72h",
        "RotationPeriod": "2160h"
    },
    "CreateIndex": 6,
    "ModifyIndex": 6,
    "Provider": "consul"
}

Consul automatically rotates the root certificate. Please refer to https://www.consul.io/docs/connect/ca.html for more details about root certificate rotations. The /connect/ca REST API endpoints can be used to manage Consul Connect certificate authorities such as updating CA configuration, changing CA provider, and bootstrapping with your own  private CA for key and root certificates.

3. The root certificates can be viewed using the following REST API call:

$ curl -s http://consul-server.consul.svc.cluster.local:8500/v1/connect/ca/roots | json_reformat
{
    "ActiveRootID": "1f:9a:35:33:2f:c0:fe:d3:c1:10:f0:16:2d:88:b6:69:2d:33:9d:4a",
    "Roots": [
        {
            "Active": true,
            "CreateIndex": 9,
            "ExternalTrustDomain": "2e672591-fd0d-2538-9eb5-13763ebaf74a",
            "ID": "1f:9a:35:33:2f:c0:fe:d3:c1:10:f0:16:2d:88:b6:69:2d:33:9d:4a",
            "IntermediateCerts": null,
            "ModifyIndex": 9,
            "Name": "Consul CA Root Cert",
            "NotAfter": "2029-08-27T01:00:28Z",
            "NotBefore": "2019-08-27T01:00:28Z",
            "PrivateKeyBits": 0,
            "PrivateKeyType": "",

...

From this, it should be clear that nothing needs to be done to enable mutual TLS between services in Consul, since the process is fully automated. Consul uses SPIFFE-based X.509 leaf certificates, which makes it simple to connect to a remote service through a strong identity. However, we should be aware that it is the responsibility of the user to enable encryption from the Ingress controller (on the edge of the service mesh) to the first service connected to another service. Also, it is the responsibility of the user to enable TLS termination at the Ingress gateway for the external traffic. The preceding discussion points out the capability of the Consul Connect service mesh to enable mTLS for polyglot microservices using Envoy sidecar proxies. 

Envoy sidecar proxy configuration is not trivial. Service meshes such as Istio and Consul hide this complexity and automatically configure the sidecar proxies for the Kubernetes environments. It is important to note that Consul allows the same for non-Kubernetes workloads. Note that this capability is only available for Go applications at the time of writing this book. 

Next, we will explore the authorization features of Consul and how they are implemented to control access to services.