diff --git a/website/source/assets/images/consul-connect/mesh-gateway/gateway_1200.png b/website/source/assets/images/consul-connect/mesh-gateway/gateway_1200.png new file mode 100644 index 0000000000..c9beb9d4b8 Binary files /dev/null and b/website/source/assets/images/consul-connect/mesh-gateway/gateway_1200.png differ diff --git a/website/source/assets/images/consul-connect/mesh-observability/metrics_1200.png b/website/source/assets/images/consul-connect/mesh-observability/metrics_1200.png new file mode 100644 index 0000000000..3560e407d6 Binary files /dev/null and b/website/source/assets/images/consul-connect/mesh-observability/metrics_1200.png differ diff --git a/website/source/assets/images/consul-connect/mesh-observability/metrics_300.png b/website/source/assets/images/consul-connect/mesh-observability/metrics_300.png new file mode 100644 index 0000000000..ef7129063c Binary files /dev/null and b/website/source/assets/images/consul-connect/mesh-observability/metrics_300.png differ diff --git a/website/source/assets/images/consul-connect/mesh-observability/metrics_976.png b/website/source/assets/images/consul-connect/mesh-observability/metrics_976.png new file mode 100644 index 0000000000..0af27fb19f Binary files /dev/null and b/website/source/assets/images/consul-connect/mesh-observability/metrics_976.png differ diff --git a/website/source/docs/agent/options.html.md b/website/source/docs/agent/options.html.md index db5c306f6f..bf4235bd09 100644 --- a/website/source/docs/agent/options.html.md +++ b/website/source/docs/agent/options.html.md @@ -468,7 +468,7 @@ will exit with an error at startup. the Web UI resources for Consul. This will automatically enable the Web UI. The directory must be readable to the agent. Starting with Consul version 0.7.0 and later, the Web UI assets are included in the binary so this flag is no longer necessary; specifying only the `-ui` flag is enough to enable the Web UI. Specifying both the '-ui' and '-ui-dir' flags will result in an error. -* `-ui-content-path` - This flag provides the option to change the path the Consul UI loads from and will be displayed in the browser. By default, the path is `/ui/`, for example `http://localhost:8500/ui/`. Only alphanumerics, `-`, and `_` are allowed in a custom path. `/v1/` is not allowed as it would overwrite the API endpoint. +* `-ui-content-path` - This flag provides the option to change the path the Consul UI loads from and will be displayed in the browser. By default, the path is `/ui/`, for example `http://localhost:8500/ui/`. Only alphanumerics, `-`, and `_` are allowed in a custom path. `/v1/` is not allowed as it would overwrite the API endpoint. ## Configuration Files @@ -638,7 +638,7 @@ default will automatically work with some tooling. ACLs are enabled. This token may be provided later using the [agent token API](/api/agent.html#update-acl-tokens) on each server. This token must have at least "read" permissions on ACL data but if ACL token replication is enabled then it must have "write" permissions. This also enables - Connect replication in Consul Enterprise, for which the token will require both operator + Connect replication, for which the token will require both operator "write" and intention "read" permissions for replicating CA and Intention data. * `acl_datacenter` - **This field is @@ -811,7 +811,7 @@ default will automatically work with some tooling. * `allow_tls` (Defaults to `false`) This option enables `auto_encrypt` on the servers and allows them to automatically distribute certificates from the Connect CA to the clients. If enabled, the server can accept incoming connections from both the built-in CA and the Connect CA, as well as their certificates. Note, the server will only present the built-in CA and certificate, which the client can verify using the CA it received from `auto_encrypt` endpoint. If disabled, a client configured with `auto_encrypt.tls` will be unable to start. - * `tls` (Defaults to `false`) Allows the client to request the Connect CA and certificates from the servers, for encrypting RPC communication. The client will make the request to any servers listed in the `-join` or `-retry-join` option. This requires that every server to have `auto_encrypt.allow_tls` enabled. When both `auto_encrypt` options are used, it allows clients to receive certificates that are generated on the servers. If the `-server-port` is not the default one, it has to be provided to the client as well. Usually this is discovered through LAN gossip, but `auto_encrypt` provision happens before the information can be distributed through gossip. The most secure `auto_encrypt` setup is when the client is provided with the built-in CA, `verify_server_hostname` is turned on, and when an ACL token with `node.write` permissions is setup. It is also possible to use `auto_encrypt` with a CA and ACL, but without `verify_server_hostname`, or only with a ACL enabled, or only with CA and `verify_server_hostname`, or only with a CA, or finally without a CA and without ACL enabled. In any case, the communication to the `auto_encrypt` endpoint is always TLS encrypted. + * `tls` (Defaults to `false`) Allows the client to request the Connect CA and certificates from the servers, for encrypting RPC communication. The client will make the request to any servers listed in the `-join` or `-retry-join` option. This requires that every server to have `auto_encrypt.allow_tls` enabled. When both `auto_encrypt` options are used, it allows clients to receive certificates that are generated on the servers. If the `-server-port` is not the default one, it has to be provided to the client as well. Usually this is discovered through LAN gossip, but `auto_encrypt` provision happens before the information can be distributed through gossip. The most secure `auto_encrypt` setup is when the client is provided with the built-in CA, `verify_server_hostname` is turned on, and when an ACL token with `node.write` permissions is setup. It is also possible to use `auto_encrypt` with a CA and ACL, but without `verify_server_hostname`, or only with a ACL enabled, or only with CA and `verify_server_hostname`, or only with a CA, or finally without a CA and without ACL enabled. In any case, the communication to the `auto_encrypt` endpoint is always TLS encrypted. * `bootstrap` Equivalent to the [`-bootstrap` command-line flag](#_bootstrap). diff --git a/website/source/docs/connect/connect-internals.html.md b/website/source/docs/connect/connect-internals.html.md index 352ac336bc..846f394766 100644 --- a/website/source/docs/connect/connect-internals.html.md +++ b/website/source/docs/connect/connect-internals.html.md @@ -3,7 +3,7 @@ layout: "docs" page_title: "Connect - Architecture" sidebar_current: "docs-connect-internals" description: |- - This page details the internals of Consul Connect: mutual TLS, agent caching and performance, and multi-datacenter Enterprise functionality. + This page details the internals of Consul Connect: mutual TLS, agent caching and performance, intention and certificate authority replication. --- # How Connect Works @@ -87,16 +87,44 @@ agent may begin failing and eventually crash. Cache entries do have TTLs associated with them and will evict their entries if they're not used. Given a long period of inactivity (3 days by default), the cache will empty itself. -## Multi-Datacenter +## Connections Across Datacenters -Using Connect for service-to-service communications across multiple datacenters -requires Consul Enterprise. +Sidecar proxy's [upstream configuration](/docs/connect/registration/service-registration.html#upstream-configuration-reference) +may specify an alternative datacenter or a prepared query that can address services +in multiple datacenters (such as the [geo failover](https://learn.hashicorp.com/consul/developer-discovery/geo-failover) pattern). -With Open Source Consul, Connect may be enabled on multiple Consul datacenters, -but only services within the same datacenter can establish Connect-based, -Authenticated and Authorized connections. In this version, Certificate Authority -configurations and intentions are both local to their respective datacenters; -they are not replicated across datacenters. +[Intentions](/docs/connect/intentions.html) verify connections between services by +source and destination name seamlessly across datacenters. -Full multi-datacenter support for Connect is available in -[Consul Enterprise](/docs/enterprise/connect-multi-datacenter/index.html). +Connections can be made via gateways to enable when communciating across +network topologies allowing connections between services in each datacenter +without externally routable IPs at the service level. + +## Intention Replication + +Intention replication happens automatically but requires the +[`primary_datacenter`](/docs/agent/options.html#primary_datacenter) +configuration to be set to specify a datacenter that is authoritative +for intentions. In production setups with ACLs enabled, the +[replication token](/docs/agent/options.html#acl_tokens_replication) must also +be set in the secondary datacenter server's configuration. + +## Certificate Authority Federation + +The primary datacenter also acts as the root Certificate Authority (CA) for Connect. +The primary datacenter generates a trust-domain UUID and obtains a root certificate +from the configured CA provider which defaults to the built-in one. + +Secondary datacenters fetch the root CA public key and trust-domain ID from the +primary and generate their own key and Certificate Signing Request (CSR) for an +intermediate CA certificate. This CSR is signed by the root in the primary +datacenter and the certificate is returned. The secondary datacenter can now use +this intermediate to sign new Connect certificates in the secondary datacenter +without WAN communication. CA keys are never replicated between datacenters. + +The secondary maintains watches on the root CA certificate in the primary. If the +CA root changes for any reason such as rotation or migration to a new CA, the +secondary automatically generates new keys and has them signed by the primary +datacenter's new root before initiating an automatic rotation of all issued +certificates in use throughout the secondary datacenter. This makes CA root key +rotation fully automatic and with zero downtime across multiple datacenters. diff --git a/website/source/docs/connect/proxies/managed-deprecated.html.md b/website/source/docs/connect/proxies/managed-deprecated.html.md index de3042c40f..cdd3b13d2a 100644 --- a/website/source/docs/connect/proxies/managed-deprecated.html.md +++ b/website/source/docs/connect/proxies/managed-deprecated.html.md @@ -205,12 +205,6 @@ service. } ``` --> **Note:** Connect does not currently support cross-datacenter -service communication. Therefore, prepared queries with Connect should -only be used to discover services within a single datacenter. See -[Multi-Datacenter Connect](/docs/connect/index.html#multi-datacenter) for -more information. - For full details of the additional configurable options available when using the built-in proxy see the [built-in proxy configuration reference](/docs/connect/configuration.html#built-in-proxy-options). diff --git a/website/source/docs/enterprise/connect-multi-datacenter/index.html.md b/website/source/docs/enterprise/connect-multi-datacenter/index.html.md deleted file mode 100644 index eb19d45d22..0000000000 --- a/website/source/docs/enterprise/connect-multi-datacenter/index.html.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -layout: "docs" -page_title: "Consul Enterprise Multi-Datacenter Connect" -sidebar_current: "docs-enterprise-connect-multi-datacenter" -description: |- - Consul Enterprise supports cross datacenter connections using Consul Connect. ---- - -# Consul Connect Multi-Datacenter - -[Consul Enterprise](https://www.hashicorp.com/consul.html) enables service-to-service -connections across multiple Consul datacenters. This includes replication of intentions -and federation of Certificate Authority trust. - -Sidecar proxy's [upstream configuration](/docs/connect/registration/service-registration.html#upstream-configuration-reference) -may specify an alternative datacenter or a prepared query that can address services -in multiple datacenters (such as the [geo failover](https://learn.hashicorp.com/consul/developer-discovery/geo-failover) pattern). - -[Intentions](/docs/connect/intentions.html) verify connections between services by -source and destination name seamlessly across datacenters. Support for constraining Intentions -by source or destination datacenter is planned for the near future. - -It is assumed that workloads can communicate between datacenters via existing network -routes and VPN tunnels, potentially using Consul's -[`translate_wan_addrs`](/docs/agent/options.html#translate_wan_addrs) to ensure remote -workloads discover an externally routable IP. - -# Replication - -Intention replication happens automatically but requires the [`primary_datacenter`](/docs/agent/options.html#primary_datacenter) -configuration to be set to specify a datacenter that is authoritative -for intentions. In production setups with ACLs enabled, the [replication token](/docs/agent/options.html#acl_tokens_replication) -must also be set in secondary datacenter server's configuration. - -# Certificate Authority Federation - -The primary datacenter also acts as the root Certificate Authority (CA) for Connect. -The primary datacenter generates a trust-domain UUID and obtains a root certificate -from the configured CA provider which defaults to the built-in one. - -Secondary datacenters fetch the root CA public key and trust-domain ID from the primary and -generate their own key and Certificate Signing Request (CSR) for an intermediate CA certificate. -This CSR is signed by the root in the primary datacenter and the certificate is returned. -The secondary datacenter can now use this intermediate to sign new Connect certificates -in the secondary datacenter without WAN communication. CA keys are never replicated between -datacenters. - -The secondary maintains watches on the root CA certificate in the primary. If the CA root -changes for any reason such as rotation or migration to a new CA, the secondary automatically -generates new keys and has them signed by the primary datacenter's new root before initiating -an automatic rotation of all issued certificates in use throughout the secondary datacenter. -This makes CA root key rotation fully automatic and with zero downtime across multiple data -centers. diff --git a/website/source/downloads.html.erb b/website/source/downloads.html.erb index 6c79b43e22..caf82094df 100644 --- a/website/source/downloads.html.erb +++ b/website/source/downloads.html.erb @@ -8,6 +8,13 @@ description: |-
1.6.0 beta Available: Read more about the new features coming in 1.6.0 in the + announcement post. Binaries can be accessed on releases.hashicorp.com. +
+Consul is a distributed service mesh to connect, secure, and configure services across any runtime platform and public or private cloud
+Consul is a service networking solution to connect and secure services across any runtime platform and public or private cloud
Consul can be run as a platform to solve a range of use-cases + in service networking.
Service Registry enables services to register and discover each other.
+Use the service registry to address and discover services across multiple runtime platforms, cloud providers and regions.
Secure service-to-service communication with automatic TLS encryption and identity-based authorization.
+ +Service discovery, identity-based authorization, and L7 traffic management abstracted from application code with proxies in the service mesh pattern.
Feature rich Key/Value store to easily configure services.
+Utilize the distributed Key/Value store to dynamically configure services and manage complex availability requirements.
+ Provision clusters on any infrastructure, connect to services over TLS via proxy integrations, and Serve TLS certificates with pluggable Certificate Authorities. +
Secure service-to-service communication with automatic TLS encryption and identity-based authorization
+Service discovery, identity-based authorization, and L7 traffic management abstracted from application code with proxies in the service mesh pattern
Service segmentation is a new approach to secure the service itself - rather than relying on the network. Consul uses service policies to - codify which services are allowed to communicate. These policies - scale across datacenters and large fleets without IP-based rules or - networking middleware.
+Service mesh is a new approach to secure the service itself + rather than relying on the network. Consul uses centrally + managed service policies and configuration to enable + dynamic routing and security based on sevice identity. + These policies scale across datacenters and large fleets + without IP-based rules or networking middleware.
Service-to-service communication policy at Layer 7 can be managed centrally, enabling advanced traffic management patterns such as service failover, path-based routing, and traffic shifting that can be applied across public and private clouds, platforms, and networks.
++ Learn more +
+
+Kind = "service-splitter"
+Name = "billing-api"
+
+Splits = [
+ {
+ Weight = 10
+ ServiceSubset = "v2"
+ },
+ {
+ Weight = 90
+ ServiceSubset = "v1"
+ },
+]
+ Define and enforce service to service communication with a simple Intentions configuration. Service based rules, instead of IP-based rules, make it easy to manage dynamic infrastructure with frequently changing machines and service locations.
+Centrally managed service observability at Layer 7 including detailed metrics on all service-to-service communication such as connections, bytes transferred, retries, timeouts, open circuits, and request rates, response codes.
- Learn more + Learn more
Connect between different cloud regions, VPCs and between overlay and underlay networks without complex network tunnels and NAT. Mesh Gateways solve routing at TLS layer while preserving end-to-end encryption and limiting attack surface area at the edge of each network.
++ Learn more +
+