github.com/KyaXTeam/consul@v1.4.5/website/source/docs/connect/index.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Connect (Service Segmentation)"
     4  sidebar_current: "docs-connect-index"
     5  description: |-
     6    Consul Connect provides service-to-service connection authorization and encryption using mutual TLS.
     7  ---
     8  
     9  # Connect
    10  
    11  Consul Connect provides service-to-service connection authorization
    12  and encryption using mutual TLS. Applications can use
    13  [sidecar proxies](/docs/connect/proxies.html)
    14  to automatically establish TLS connections for inbound and outbound connections
    15  without being aware of Connect at all. Applications may also
    16  [natively integrate with Connect](/docs/connect/native.html)
    17  for optimal performance and security.
    18  
    19  Connect enables deployment best-practices with service-to-service encryption
    20  everywhere and identity-based authorization. Rather than authorizing host-based
    21  access with IP address access rules, Connect uses the registered service
    22  identity to enforce access control with [intentions](/docs/connect/intentions.html).
    23  This makes it much easier to reason about access control and also enables
    24  services to freely move, such as in a scheduled environment with software
    25  such as Kubernetes or Nomad. Additionally, intention enforcement can be done
    26  regardless of the underlying network, so Connect works with physical networks,
    27  cloud networks, software-defined networks, cross-cloud, and more.
    28  
    29  ## How it Works
    30  
    31  The core of Connect is based on [mutual TLS](https://en.wikipedia.org/wiki/Mutual_authentication).
    32  
    33  Connect provides each service with an identity encoded as a TLS certificate.
    34  This certificate is used to establish and accept connections to and from other
    35  services. The identity is encoded in the TLS certificate in compliance with
    36  the [SPIFFE X.509 Identity Document](https://github.com/spiffe/spiffe/blob/master/standards/X509-SVID.md).
    37  This enables Connect services to establish and accept connections with
    38  other SPIFFE-compliant systems.
    39  
    40  The client service verifies the destination service certificate
    41  against the [public CA bundle](/api/connect/ca.html#list-ca-root-certificates).
    42  This is very similar to a typical HTTPS web browser connection. In addition
    43  to this, the client provides its own client certificate to show its
    44  identity to the destination service. If the connection handshake succeeds,
    45  the connection is encrypted and authorized.
    46  
    47  The destination service verifies the client certificate
    48  against the [public CA bundle](/api/connect/ca.html#list-ca-root-certificates).
    49  After verifying the certificate, it must also call the
    50  [authorization API](/api/agent/connect.html#authorize) to authorize
    51  the connection against the configured set of Consul intentions.
    52  If the authorization API responds successfully, the connection is established.
    53  Otherwise, the connection is rejected.
    54  
    55  To generate and distribute certificates, Consul has a built-in CA that
    56  requires no other dependencies, and
    57  also ships with built-in support for [Vault](/docs/connect/ca/vault.html). The PKI system is designed to be pluggable
    58  and can be extended to support any system by adding additional CA providers.
    59  
    60  All APIs required for Connect typically respond in microseconds and impose
    61  minimal overhead to existing services. This is because the Connect-related
    62  APIs are all made to the local Consul agent over a loopback interface, and all
    63  [agent Connect endpoints](/api/agent/connect.html) implement
    64  local caching, background updating, and support blocking queries. As a result,
    65  most API calls operate on purely local in-memory data and can respond
    66  in microseconds.
    67  
    68  ## Getting Started With Connect
    69  
    70  There are several ways to try Connect in different environments.
    71  
    72   * The [Connect introduction](https://learn.hashicorp.com/consul/getting-started/connect) in the
    73     Getting Started guide provides a simple walk through of getting two services
    74     to communicate via Connect using only Consul directly on your local machine.
    75  
    76   * The [Envoy guide](/docs/guides/connect-envoy.html) walks through getting
    77     started with Envoy as a proxy, and uses Docker to run components locally
    78     without installing anything else.
    79  
    80   * The [Kubernetes documentation](/docs/platform/k8s/run.html) shows how to get
    81     from an empty Kubernetes cluster to having Consul installed and Envoy
    82     configured to proxy application traffic automatically using the official helm
    83     chart.
    84  
    85  ## Agent Caching and Performance
    86  
    87  To enable microsecond-speed responses on
    88  [agent Connect API endpoints](/api/agent/connect.html), the Consul agent
    89  locally caches most Connect-related data and sets up background
    90  [blocking queries](/api/index.html#blocking-queries) against the server
    91  to update the cache in the background. This allows most API calls such
    92  as retrieving certificates or authorizing connections to use in-memory
    93  data and respond very quickly.
    94  
    95  All data cached locally by the agent is populated on demand. Therefore,
    96  if Connect is not used at all, the cache does not store any data. On first
    97  request, the data is loaded from the server and cached. The set of data cached
    98  is: public CA root certificates, leaf certificates, and intentions. For
    99  leaf certificates and intentions, only data related to the service requested
   100  is cached, not the full set of data.
   101  
   102  Further, the cache is partitioned by ACL token and datacenters. This is done
   103  to minimize the complexity of the cache and prevent bugs where an ACL token
   104  may see data it shouldn't from the cache. This results in higher memory usage
   105  for cached data since it is duplicated per ACL token, but with the benefit
   106  of simplicity and security.
   107  
   108  With Connect enabled, you'll likely see increased memory usage by the
   109  local Consul agent. The total memory is dependent on the number of intentions
   110  related to the services registered with the agent accepting Connect-based
   111  connections. The other data (leaf certificates and public CA certificates)
   112  is a relatively fixed size per service. In most cases, the overhead per
   113  service should be relatively small: single digit kilobytes at most.
   114  
   115  The cache does not evict entries due to memory pressure. If memory capacity
   116  is reached, the process will attempt to swap. If swap is disabled, the Consul
   117  agent may begin failing and eventually crash. Cache entries do have TTLs
   118  associated with them and will evict their entries if they're not used. Given
   119  a long period of inactivity (3 days by default), the cache will empty itself.
   120  
   121  ## Multi-Datacenter
   122  
   123  Using Connect for service-to-service communications across multiple datacenters 
   124  requires Consul Enterprise. 
   125  
   126  With Open Source Consul, Connect may be enabled on multiple Consul datacenters, 
   127  but only services within the same datacenter can establish Connect-based, 
   128  Authenticated and Authorized connections. In this version, Certificate Authority
   129  configurations and intentions are both local to their respective datacenters; 
   130  they are not replicated across datacenters.
   131  
   132  Full multi-datacenter support for Connect is available in
   133  [Consul Enterprise](/docs/enterprise/connect-multi-datacenter/index.html).
   134