mirror of https://github.com/hashicorp/consul
159 lines
8.0 KiB
Markdown
159 lines
8.0 KiB
Markdown
---
|
|
layout: docs
|
|
page_title: Service Mesh Native App Integration - Overview
|
|
description: >-
|
|
When using sidecar proxies is not possible, applications can natively integrate with Consul service mesh, but have reduced access to service mesh features. Learn how "mesh-native" or "connect-native" apps use mTLS to authenticate with Consul and how to add integrations to service registrations.
|
|
---
|
|
|
|
# Service Mesh Native App Integration Overview
|
|
|
|
~> **Note:** The Native App Integration does not support many of the Consul's service
|
|
mesh features, and is not under active development.
|
|
The [Envoy proxy](/consul/docs/connect/proxies/envoy) 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](/consul/docs/connect/proxies). 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](/consul/docs/connect/native/go)
|
|
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](/consul/api-docs/agent/connect#service-leaf-certificate),
|
|
[verifying TLS certificates](/consul/api-docs/agent/connect#certificate-authority-ca-roots),
|
|
and [authorizing inbound connections or requests](/consul/api-docs/connect/intentions#list-matching-intentions).
|
|
|
|
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](/consul/api-docs/agent/connect#authorize).
|
|
|
|
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
|
|
[`<service>.connect`](/consul/docs/services/discovery/dns-static-lookups#service-mesh-enabled-service-lookups)
|
|
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](/consul/api-docs/agent/connect#service-leaf-certificate)
|
|
as the client certificate. Verify the remote certificate against the
|
|
[public CA roots](/consul/api-docs/agent/connect#certificate-authority-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](/consul/api-docs/agent/connect#certificate-authority-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](/consul/api-docs/agent/connect#authorize) 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](/consul/api-docs/connect/intentions#list-matching-intentions). 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](/consul/api-docs/agent/connect#service-leaf-certificate)
|
|
and [reading service mesh CA roots](/consul/api-docs/agent/connect#certificate-authority-ca-roots)
|
|
both support
|
|
[blocking queries](/consul/api-docs/features/blocking). 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](/consul/api-docs/features/blocking). 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](/consul/docs/connect/native/go) 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](/consul/docs/connect/proxies).
|
|
|
|
You can enable native service mesh support directly in the [service definition](/consul/docs/services/configuration/services-configuration-reference#connect) by configuring the `connect` block. In the following example, the `redis` service is configured to support service mesh natively:
|
|
|
|
```json
|
|
{
|
|
"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.
|