Service Mesh Native App Integration Overview

Note

The Connect Native Golang SDK and v1/agent/connect/authorize, v1/agent/connect/ca/leaf, and v1/agent/connect/ca/roots APIs are deprecated and will be removed in a future release. Although Connect Native will still operate as designed, we do not recommend leveraging this feature because it is deprecated and will be removed removed when the long term replacement to native application integration (such as a proxyless gRPC service mesh integration) is delivered. Refer to GH-10339 for additional information and to track progress toward one potential solution that is tracked as replacement functionality.

The Native App Integration does not support many of the Consul’s service mesh features, and is not under active development. The Envoy proxy should be used for most production environments.

Applications can natively integrate with Consul’s service mesh API to support accepting and establishing connections to other mesh services without the overhead of a proxy sidecar. This option is especially useful for applications that may be experiencing performance issues with the proxy sidecar deployment. This page will cover the high-level overview of integration, registering the service, etc. For language-specific examples, see the sidebar navigation to the left. It is also required if your service uses relies on a dynamic set of upstream services.

Service mesh traffic is just basic mutual TLS. This means that almost any application can easily integrate with Consul service mesh. There is no custom protocol in use; any language that supports TLS can accept and establish mesh-based connections.

We currently provide an easy-to-use Go integration to assist with the getting the proper certificates, verifying connections, etc. We plan to add helper libraries for other languages in the future. However, without library support, it is still possible for any major language to integrate with Consul service mesh.

The noun connect is used throughout this documentation to refer to the connect subsystem that provides Consul’s service mesh capabilities.

Overview

The primary work involved in natively integrating with service mesh is acquiring the proper TLS certificate, verifying TLS certificates, and authorizing inbound connections or requests.

All of this is done using the Consul HTTP APIs linked above.

An overview of the sequence is shown below. The diagram and the following details may seem complex, but this is a regular mutual TLS connection with an API call to verify the incoming client certificate.

Note: This diagram depicts the simpler networking layer 4 (e.g. TCP) integration mechanism.

Details on the steps are below:

• Service discovery - This is normal service discovery using Consul, a static IP, or any other mechanism. If you’re using Consul DNS, the .connect syntax to find mesh-capable endpoints for a service. After service discovery, choose one address from the list of service addresses.

• Mutual TLS - As a client, connect to the discovered service address over normal TLS. As part of the TLS connection, provide the service certificate as the client certificate. Verify the remote certificate against the public CA roots. As a client, if the connection is established then you’ve established a mesh-based connection and there are no further steps!

• Authorization - As a server accepting connections, verify the client certificate against the public CA roots. After verifying the certificate, parse some basic fields from it and use those to determine if the connection should be allowed. How this is done is dependent on the level of integration desired:

  • Simple integration (TCP-only) - Call the authorizing API against the local agent. If this returns successfully, complete the TLS handshake and establish the connection. If authorization fails, close the connection.

    NOTE: This API call is expected to be called in the connection path, so if the local Consul agent is down or unresponsive it will effect the success rate of new connections. The agent uses locally cached data to authorize the connection and typically responds in microseconds. Therefore, the impact to the TLS handshake is typically microseconds.

  • Complete integration - Like how the calls to acquire the leaf certificate and CA roots are expected to be done out of band and reused, so should the intention match API. With all of the relevant intentions cached for the destination, all enforcement operations can be done entirely by the service without calling any Consul APIs in the connection or request path. If the service is networking layer 7 (e.g. HTTP) aware it can safely enforce intentions per request instead of the coarser per connection model.

Update certificates and certificate roots

The leaf certificate and CA roots can be updated at any time and the natively integrated application must react to this relatively quickly so that new connections are not disrupted. This can be done through Consul blocking queries (HTTP long polling) or through periodic polling.

The API calls for acquiring a service mesh TLS certificate and reading service mesh CA roots both support blocking queries. By using blocking queries, an application can efficiently wait for an updated value. For example, the leaf certificate API will block until the certificate is near expiration or the signing certificates have changed and will issue and return a new certificate.

In some languages, using blocking queries may not be simple. In that case, we still recommend using the blocking query parameters but with a very short timeout value set. Doing this is documented with blocking queries. The low timeout will ensure the API responds quickly. We recommend that applications poll the certificate endpoints frequently, such as multiple times per minute.

The overhead for the blocking queries (long or periodic polling) is minimal. The API calls are to the local agent and the local agent uses locally cached data multiplexed over a single TCP connection to the Consul leader. Even if a single machine has 1,000 mesh-enabled services all blocking on certificate updates, this translates to only one TCP connection to the Consul server.

Some language libraries such as the Go library automatically handle updating and locally caching the certificates.

Service registration

Mesh-native applications must tell Consul that they support service mesh natively. This enables the service to be returned as part of service discovery for service mesh-capable services used by other mesh-native applications and client proxies.

You can enable native service mesh support directly in the service definition by configuring the connect block. In the following example, the redis service is configured to support service mesh natively:

{
  "service": {
    "name": "redis",
    "port": 8000,
    "connect": {
      "native": true
    }
  }
}

Services that support service mesh natively are still returned through the standard service discovery mechanisms in addition to the mesh-only service discovery mechanisms.