github.com/outbrain/consul@v1.4.5/website/source/docs/enterprise/connect-multi-datacenter/index.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Consul Enterprise Multi-Datacenter Connect"
     4  sidebar_current: "docs-enterprise-connect-multi-datacenter"
     5  description: |-
     6    Consul Enterprise supports cross datacenter connections using Consul Connect.
     7  ---
     8  
     9  # Consul Connect Multi-Datacenter
    10  
    11  [Consul Enterprise](https://www.hashicorp.com/consul.html) enables service-to-service
    12  connections across multiple Consul datacenters. This includes replication of intentions
    13  and federation of Certificate Authority trust.
    14  
    15  Sidecar proxy's [upstream configuration](/docs/connect/proxies.html#upstream-configuration-reference) 
    16  may specify an alternative datacenter or a prepared query that can address services 
    17  in multiple datacenters (such as the [geo failover](/docs/guides/geo-failover.html) pattern).
    18  
    19  [Intentions](/docs/connect/intentions.html) verify connections between services by 
    20  source and destination name seamlessly across datacenters. Support for constraining Intentions 
    21  by source or destination datacenter is planned for the near future.
    22  
    23  It is assumed that workloads can communicate between datacenters via existing network 
    24  routes and VPN tunnels, potentially using Consul's 
    25  [`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) to ensure remote 
    26  workloads discover an externally routable IP.
    27  
    28  # Replication
    29  
    30  Intention replication happens automatically but requires the [`primary_datacenter`](/docs/agent/options.html#primary_datacenter)
    31  configuration to be set to specify a datacenter that is authorative
    32  for intentions. In production setups with ACLs enabled, the [replication token](/docs/agent/options.html#acl_tokens_replication)
    33  must also be set in secondary datacenter server's configuration.
    34  
    35  # Certificate Authority Federation
    36  
    37  The primary datacenter also acts as the root Certificate Authority (CA) for Connect. 
    38  The primary datacenter generates a trust-domain UUID and obtains a root certificate 
    39  from the configured CA provider which defaults to the built-in one. 
    40  
    41  Secondary datacenters fetch the root CA public key and trust-domain ID from the primary and 
    42  generate their own key and Certificate Signing Request (CSR) for an intermediate CA certificate. 
    43  This CSR is signed by the root in the primary datacenter and the certificate is returned. 
    44  The secondary datacenter can now use this intermediate to sign new Connect certificates 
    45  in the secondary datacenter without WAN communication. CA keys are never replicated between 
    46  datacenters.
    47  
    48  The secondary maintains watches on the root CA certificate in the primary. If the CA root
    49  changes for any reason such as rotation or migration to a new CA, the secondary automatically
    50  generates new keys and has them signed by the primary datacenter's new root before initiating
    51  an automatic rotation of all issued certificates in use throughout the secondary datacenter. 
    52  This makes CA root key rotation fully automatic and with zero downtime across multiple data 
    53  centers.