status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

docs: consistently name Consul service mesh (#17222) 

Remove outdated usage of "Consul Connect" instead of Consul service mesh.

The connect subsystem in Consul provides Consul's service mesh capabilities.
However, the term "Consul Connect" should not be used as an alternative to
the name "Consul service mesh".
This commit is contained in:
Jared Kirschner 2023-05-05 13:41:40 -04:00 committed by GitHub
parent 917afcf3c6
commit 166d7a39e8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
93 changed files with 479 additions and 457 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
website/content/api-docs/agent/connect.mdx
View File

@ -2,18 +2,18 @@
layout: api
page_title: Connect - Agent - HTTP API
description: >-
The /agent/connect endpoints interact with Connect with agent-local
The /agent/connect endpoints interact with agent-local service mesh
operations.
---
# Connect - Agent HTTP API
The `/agent/connect` endpoints interact with [Connect](/consul/docs/connect)
with agent-local operations.
The `/agent/connect` endpoints interact with
with agent-local [service mesh](/consul/docs/connect) operations.
These endpoints may mirror the [non-agent Connect endpoints](/consul/api-docs/connect)
in some cases. Almost all agent-local Connect endpoints perform local caching
to optimize performance of Connect without having to make requests to the server.
These endpoints may mirror the [non-agent service mesh endpoints](/consul/api-docs/connect)
in some cases. Almost all agent-local service mesh endpoints perform local caching
to optimize performance of the mesh without having to make requests to the server.
## Authorize
@ -29,7 +29,7 @@ This endpoint tests whether a connection attempt is authorized between
two services. This is the primary API that must be implemented by
[proxies](/consul/docs/connect/proxies) or
[native integrations](/consul/docs/connect/native)
that wish to integrate with Connect. Prior to calling this API, it is expected
that wish to integrate with the service mesh. Prior to calling this API, it is expected
that the client TLS certificate has been properly verified against the
current CA roots.
@ -108,7 +108,7 @@ This is used by [proxies](/consul/docs/connect/proxies) or
[native integrations](/consul/docs/connect/native) to verify served client
or server certificates are valid.
This is equivalent to the [non-Agent Connect endpoint](/consul/api-docs/connect),
This is equivalent to the [non-Agent service mesh endpoint](/consul/api-docs/connect),
but the response of this request is cached locally at the agent. This allows
for very fast response times and for fail open behavior if the server is
unavailable. This endpoint should be used by proxies and native integrations.
@ -248,7 +248,7 @@ $ curl \
## Methods to Specify Namespace <EnterpriseAlert inline />
Local agent connect endpoints
Local agent service mesh endpoints
support several methods for specifying the namespace of resources
with the following order of precedence:
1. `Namespace` field of the JSON request body -

16
website/content/api-docs/agent/service.mdx
View File

@ -130,7 +130,7 @@ following selectors and filter operations being supported:
This endpoint was added in Consul 1.3.0 and returns the full service definition
for a single service instance registered on the local agent. It is used by
[Connect proxies](/consul/docs/connect/proxies) to discover the embedded proxy
[service mesh proxies](/consul/docs/connect/proxies) to discover the embedded proxy
configuration that was registered with the instance.
It is important to note that the services known by the agent may be different
@ -632,18 +632,18 @@ The `/agent/service/register` endpoint supports camel case and _snake case_ for
- `Kind` `(string: "")` - The kind of service. Defaults to "" which is a
typical Consul service. This value may also be "connect-proxy" for
[Connect](/consul/docs/connect) proxies representing another service,
"mesh-gateway" for instances of a [mesh gateway](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration),
[service mesh](/consul/docs/connect) proxies representing another service,
"mesh-gateway" for instances of a [mesh gateway](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration),
"terminating-gateway" for instances of a [terminating gateway](/consul/docs/connect/gateways/terminating-gateway),
or "ingress-gateway" for instances of a [ingress gateway](/consul/docs/connect/gateways/ingress-gateway).
- `Proxy` `(Proxy: nil)` - From 1.2.3 on, specifies the configuration for a
Connect service proxy instance. This is only valid if `Kind` defines a proxy or gateway.
service mesh proxy instance. This is only valid if `Kind` defines a proxy or gateway.
See the [Proxy documentation](/consul/docs/connect/registration/service-registration)
for full details.
- `Connect` `(Connect: nil)` - Specifies the
[configuration for Connect](/consul/docs/connect/configuration). See the
[configuration for service mesh](/consul/docs/connect/configuration). The connect subsystem provides Consul's service mesh capabilities. Refer to the
[Connect Structure](#connect-structure) section below for supported fields.
- `Check` `(Check: nil)` - Specifies a check. Please see the
@ -689,12 +689,12 @@ The `/agent/service/register` endpoint supports camel case and _snake case_ for
For the `Connect` field, the parameters are:
- `Native` `(bool: false)` - Specifies whether this service supports
the [Connect](/consul/docs/connect) protocol [natively](/consul/docs/connect/native).
If this is true, then Connect proxies, DNS queries, etc. will be able to
the [Consul service mesh](/consul/docs/connect) protocol [natively](/consul/docs/connect/native).
If this is true, then service mesh proxies, DNS queries, etc. will be able to
service discover this service.
- `Proxy` `(Proxy: nil)` -
[**Deprecated**](/consul/docs/connect/proxies/managed-deprecated) Specifies that
a managed Connect proxy should be started for this service instance, and
a managed service mesh proxy should be started for this service instance, and
optionally provides configuration for the proxy. The format is as documented
in [Managed Proxy Deprecation](/consul/docs/connect/proxies/managed-deprecated).
- `SidecarService` `(ServiceDefinition: nil)` - Specifies an optional nested

12
website/content/api-docs/catalog.mdx
View File

@ -650,9 +650,9 @@ $ curl \
[service registration API](/consul/api-docs/agent/service#kind) for more information.
- `ServiceProxy` is the proxy config as specified in
[Connect Proxies](/consul/docs/connect/proxies).
[service mesh Proxies](/consul/docs/connect/proxies).
- `ServiceConnect` are the [Connect](/consul/docs/connect) settings. The
- `ServiceConnect` are the [service mesh](/consul/docs/connect) settings. The
value of this struct is equivalent to the `Connect` field for service
registration.
@ -704,13 +704,13 @@ following selectors and filter operations being supported:
| `TaggedAddresses.<any>` | Equal, Not Equal, In, Not In, Matches, Not Matches |
| `TaggedAddresses` | Is Empty, Is Not Empty, In, Not In |
## List Nodes for Connect-capable Service
## List Nodes for Mesh-capable Service
This endpoint returns the nodes providing a
[Connect-capable](/consul/docs/connect) service in a given datacenter.
[mesh-capable](/consul/docs/connect) service in a given datacenter.
This will include both proxies and native integrations. A service may
register both Connect-capable and incapable services at the same time,
so this endpoint may be used to filter only the Connect-capable endpoints.
register both mesh-capable and incapable services at the same time,
so this endpoint may be used to filter only the mesh-capable endpoints.
@include 'http_api_results_filtered_by_acls.mdx'

6
website/content/api-docs/connect/ca.mdx
View File

@ -8,7 +8,7 @@ description: |-
# Certificate Authority (CA) - Connect HTTP API
The `/connect/ca` endpoints provide tools for interacting with Connect's
The `/connect/ca` endpoints provide tools for interacting with the service mesh's
Certificate Authority mechanism.
## List CA Root Certificates
@ -33,7 +33,7 @@ The table below shows this endpoint's support for
### Query Parameters
- `pem` `(boolean: false)` - Specifies that the return body should be a PEM encoded
certificate chain suitable for use by applications needing to trust Connect CA
certificate chain suitable for use by applications needing to trust service mesh CA
signed certificates. The Content-Type will be set to `application/pem-certificate-chain`
to indicate the format of the response.
@ -181,7 +181,7 @@ The corresponding CLI command is [`consul connect ca set-config`](/consul/comman
- `Provider` `(string: <required>)` - Specifies the CA provider type to use.
- `Config` `(map[string]string: <required>)` - The raw configuration to use
for the chosen provider. For more information on configuring the Connect CA
for the chosen provider. For more information on configuring the service mesh CA
providers, see [Provider Config](/consul/docs/connect/ca).
- `ForceWithoutCrossSigning` `(bool: false)` - Indicates that the CA change

13
website/content/api-docs/connect/index.mdx
View File

@ -2,20 +2,25 @@
layout: api
page_title: Connect - HTTP API
description: >-
The `/connect` endpoints provide access to Connect-related operations for
The `/connect` endpoints provide access to service mesh-related operations for
intentions and the certificate authority.
---
# Connect HTTP Endpoint
The `/connect` endpoints provide access to
[Connect-related](/consul/docs/connect) operations for
[service mesh-related](/consul/docs/connect) operations for
intentions and the certificate authority.
There are also Connect-related endpoints in the
There are also service mesh-related endpoints in the
[Agent](/consul/api-docs/agent) and [Catalog](/consul/api-docs/catalog) APIs. For example,
the API for requesting a TLS certificate for a service is part of the agent
APIs. And the catalog API has an endpoint for finding all Connect-capable
APIs. And the catalog API has an endpoint for finding all mesh-capable
services in the catalog.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
Where you encounter the _noun_ connect, it is usually functionality specific to
service mesh.
Please choose a sub-section in the navigation for more information.

2
website/content/api-docs/connect/intentions.mdx
View File

@ -672,7 +672,7 @@ $ curl \
## Methods to Specify Namespace <EnterpriseAlert inline />
Connect intention endpoints
Intention endpoints
support several methods for specifying the namespace of intention resources
with the following order of precedence:
1. `ns` query parameter

4
website/content/api-docs/discovery-chain.mdx
View File

@ -9,7 +9,7 @@ description: The /discovery-chain endpoints are for interacting with the discove
-> **1.6.0+:** The discovery chain API is available in Consul versions 1.6.0 and newer.
~> This is a low-level API primarily targeted at developers building external
[Connect proxy integrations](/consul/docs/connect/proxies/integrate). Future
[service mesh proxy integrations](/consul/docs/connect/proxies/integrate). Future
high-level proxy integration APIs may obviate the need for this API over time.
The `/discovery-chain` endpoint returns the compiled [discovery
@ -17,7 +17,7 @@ chain](/consul/docs/connect/l7-traffic/discovery-chain) for a service.
This will fetch all related [configuration
entries](/consul/docs/agent/config-entries) and render them into a form suitable
for use by a [connect proxy](/consul/docs/connect/proxies) implementation. This
for use by a [service mesh proxy](/consul/docs/connect/proxies) implementation. This
is a key component of [L7 Traffic
Management](/consul/docs/connect/l7-traffic).

8
website/content/api-docs/health.mdx
View File

@ -410,13 +410,13 @@ following selectors and filter operations being supported:
| `Service.Weights.Passing` | Equal, Not Equal |
| `Service.Weights.Warning` | Equal, Not Equal |
## List Service Instances for Connect-enabled Service
## List Service Instances for Mesh-enabled Service
This endpoint returns the service instances providing a
[Connect-capable](/consul/docs/connect) service in a given datacenter.
[mesh-capable](/consul/docs/connect) service in a given datacenter.
This will include both proxies and native integrations. A service may
register both Connect-capable and incapable services at the same time,
so this endpoint may be used to filter only the Connect-capable endpoints.
register both mesh-capable and incapable services at the same time,
so this endpoint may be used to filter only the mesh-capable endpoints.
@include 'http_api_results_filtered_by_acls.mdx'

10
website/content/api-docs/operator/usage.mdx
View File

@ -3,14 +3,14 @@ layout: api
page_title: Usage - Operator - HTTP API
description: |-
The /operator/usage endpoint returns usage information about the number of
services, service instances and Connect-enabled service instances by
services, service instances and mesh-enabled service instances by
datacenter.
---
# Usage Operator HTTP API
The `/operator/usage` endpoint returns usage information about the number of
services, service instances and Connect-enabled service instances by datacenter.
services, service instances and mesh-enabled service instances by datacenter.
| Method | Path | Produces |
| ------ | ----------------- | ------------------ |
@ -142,12 +142,12 @@ $ curl \
- `ServiceInstances` is the total number of service instances registered in
the datacenter.
- `ConnectServiceInstances` is the total number of Connect service instances
- `ConnectServiceInstances` is the total number of mesh service instances
registered in the datacenter.
- `BillableServiceInstances` is the total number of billable service instances
registered in the datacenter. This is only relevant in Consul Enterprise
and is the total service instance count, not including any Connect service
and is the total service instance count, not including any mesh service
instances or any Consul server instances.
- `PartitionNamespaceServices` <EnterpriseAlert inline /> is the total number
@ -163,5 +163,5 @@ $ curl \
by partition and namespace.
- `PartitionNamespaceConnectServiceInstances` <EnterpriseAlert inline /> is
the total number of Connect service instances registered in the datacenter,
the total number of mesh service instances registered in the datacenter,
by partition and namespace.

10
website/content/api-docs/query.mdx
View File

@ -266,12 +266,12 @@ The table below shows this endpoint's support for
key/value pairs that will be used for filtering the query results to services
with the given metadata values present.
* `Connect` `(bool: false)` - If true, only [Connect-capable](/consul/docs/connect) services
* `Connect` `(bool: false)` - If true, only [mesh-capable](/consul/docs/connect) services
for the specified service name will be returned. This includes both
natively integrated services and proxies. For proxies, the proxy name
may not match `Service`, because the proxy destination will. Any
constrains beyond the service name such as `Near`, `Tags`, and `NodeMeta`
are applied to Connect-capable service.
constraints beyond the service name such as `Near`, `Tags`, and `NodeMeta`
are applied to mesh-capable service.
* `DNS` `(DNS: nil)` - Specifies DNS configuration
@ -550,8 +550,8 @@ be used.
This is applied after any sorting or shuffling.
- `connect` `(bool: false)` - If true, limit results to nodes that are
Connect-capable only. This parameter can also be specified directly on the template
itself to force all executions of a query to be Connect-only. See the
mesh-capable only. This parameter can also be specified directly on the template
itself to force all executions of a query to be mesh-only. See the
template documentation for more information.
### Sample Request

29
website/content/commands/config/write.mdx
View File

@ -79,8 +79,9 @@ supported config entries.
#### Service defaults
Service defaults control default global values for a service, such as the
protocol and Connect fields.
Service defaults control default global values for a service in the service mesh.
For example, the following configuration defines that all instances of the `web`
service use the `http` protocol.
```json
{
@ -90,33 +91,23 @@ protocol and Connect fields.
}
```
- `Name` - Sets the name of the config entry. For service defaults, this must be
the name of the service being configured.
- `Protocol` - Sets the protocol of the service. This is used by Connect proxies
for things like observability features.
- `Connect` - This block contains Connect-related fields for the service.
- `SidecarProxy` - Sets whether or not instances of this service should get a
sidecar proxy by default.
For more information, refer to the [service defaults configuration reference](/consul/docs/connect/config-entries/service-defaults).
#### Proxy defaults
Proxy defaults allow for configuring global config defaults across all services
for Connect proxy config. Currently, only one global entry is supported.
Proxy defaults lets you configure global config defaults across all proxies
in the service mesh. Currently, it supports only one global entry.
For example, the following configuration overrides a default timeout for all
Envoy proxies.
```json
{
"Kind": "proxy-defaults",
"Name": "global",
"Config": {
"foo": 1
"local_idle_timeout_ms": 20000
}
}
```
- `Name` - Sets the name of the config entry. Currently, only a single `proxy-defaults`
entry with the name `global` is supported.
* `Config` - An arbitrary map of configuration values used by Connect proxies.
For more information, refer to the [proxy defaults configuration reference](/consul/docs/connect/config-entries/proxy-defaults).

13
website/content/commands/connect/ca.mdx
View File

@ -10,14 +10,15 @@ description: >
Command: `consul connect ca`
The CA connect command is used to interact with Consul Connect's Certificate Authority
subsystem. The command can be used to view or modify the current CA configuration. See the
[Connect CA documentation](/consul/docs/connect/ca) for more information.
This command is used to interact with Consul service mesh's Certificate Authority
managed by the connect subsystem.
It can be used to view or modify the current CA configuration. Refer to the
[service mesh CA documentation](/consul/docs/connect/ca) for more information.
```text
Usage: consul connect ca <subcommand> [options] [args]
This command has subcommands for interacting with Consul Connect's
This command has subcommands for interacting with Consul service mesh's
Certificate Authority (CA).
Here are some simple examples, and more detailed examples are available
@ -34,8 +35,8 @@ Usage: consul connect ca <subcommand> [options] [args]
For more examples, ask for subcommand help or view the documentation.
Subcommands:
get-config Display the current Connect Certificate Authority (CA) configuration
set-config Modify the current Connect CA configuration
get-config Display the current service mesh Certificate Authority (CA) configuration
set-config Modify the current service mesh CA configuration
```
## get-config

2
website/content/commands/connect/envoy.mdx
View File

@ -11,7 +11,7 @@ Command: `consul connect envoy`
The connect Envoy command is used to generate a bootstrap configuration for
[Envoy proxy](https://envoyproxy.io) for use with [Consul
Connect](/consul/docs/connect/).
service mesh](/consul/docs/connect/).
Refer to the [examples](#examples) for guidance on common use cases,
such as [launching a service instance's sidecar proxy

6
website/content/commands/connect/expose.mdx
View File

@ -2,7 +2,7 @@
layout: commands
page_title: 'Commands: Connect Expose'
description: >
The connect expose subcommand is used to expose a Connect-enabled service
The connect expose subcommand is used to expose a mesh-enabled service
through an Ingress gateway by modifying the gateway's configuration and adding
an intention to allow traffic from the gateway to the service.
---
@ -11,7 +11,7 @@ description: >
Command: `consul connect expose`
The connect expose subcommand is used to expose a Connect-enabled service
The connect expose subcommand is used to expose a mesh-enabled service
through an Ingress gateway by modifying the gateway's configuration and adding
an intention to allow traffic from the gateway to the service. See the
[Ingress gateway documentation](/consul/docs/connect/gateways/ingress-gateway) for more information
@ -20,7 +20,7 @@ about Ingress gateways.
```text
Usage: consul connect expose [options]
Exposes a Connect-enabled service through the given ingress gateway, using the
Exposes a mesh-enabled service through the given ingress gateway, using the
given protocol and port.
```

22
website/content/commands/connect/index.mdx
View File

@ -9,10 +9,10 @@ description: >-
Command: `consul connect`
The `connect` command is used to interact with Consul
[service mesh](/consul/docs/connect) subsystems. It exposes commands for
running the built-in mTLS proxy and viewing/updating the Certificate Authority
(CA) configuration. This command is available in Consul 1.2 and later.
The `connect` command is used to interact with the connect subsystem
that provides Consul's [service mesh](/consul/docs/connect) capabilities.
It exposes commands for running service mesh proxies and
for viewing/updating the service mesh Certificate Authority (CA) configuration.
## Usage
@ -24,22 +24,22 @@ the complete list of subcommands.
```text
Usage: consul connect <subcommand> [options] [args]
This command has subcommands for interacting with Consul Connect.
This command has subcommands for interacting with Consul service mesh.
Here are some simple examples, and more detailed examples are available
in the subcommands or the documentation.
Run the built-in Connect mTLS proxy
Run the production service mesh proxy
$ consul connect proxy
$ consul connect envoy
For more examples, ask for subcommand help or view the documentation.
Subcommands:
ca Interact with the Consul Connect Certificate Authority (CA)
envoy Runs or Configures Envoy as a Connect proxy
expose Expose a Connect-enabled service through an Ingress gateway
proxy Runs a Consul Connect proxy
ca Interact with the Consul service mesh Certificate Authority (CA)
envoy Runs or configures Envoy as a service mesh proxy
expose Expose a mesh-enabled service through an Ingress gateway
proxy Runs a non-production, built-in service mesh sidecar proxy
redirect-traffic Applies iptables rules for traffic redirection
```

12
website/content/commands/connect/proxy.mdx
View File

@ -3,7 +3,7 @@ layout: commands
page_title: 'Commands: Connect Proxy'
description: >
The connect proxy subcommand is used to run the built-in mTLS proxy for
Connect.
Consul service mesh.
---
# Consul Connect Proxy
@ -11,9 +11,9 @@ description: >
Command: `consul connect proxy`
The connect proxy command is used to run Consul's built-in mTLS proxy for
use with Connect. This can be used in production to enable a Connect-unaware
application to accept and establish Connect-based connections. This proxy
can also be used in development to connect to Connect-enabled services.
use with Consul service mesh. This can be used in production to enable a mesh-unaware
application to accept and establish mesh-based connections. This proxy
can also be used in development to connect to mesh-enabled services.
## Usage
@ -49,7 +49,7 @@ Usage: `consul connect proxy [options]`
- `-upstream` - Upstream service to support connecting to. The format should be
'name:addr', such as 'db:8181'. This will make 'db' available on port 8181.
When a regular TCP connection is made to port 8181, the proxy will service
discover "db" and establish a Connect mTLS connection identifying as
discover "db" and establish a Consul service mesh mTLS connection identifying as
the `-service` value. This flag can be repeated multiple times.
- `-listen` - Address to listen for inbound connections to the proxied service.
@ -60,7 +60,7 @@ Usage: `consul connect proxy [options]`
`-listen`.
- `-register` - Self-register with the local Consul agent, making this
proxy available as Connect-capable service in the catalog. This is only
proxy available as mesh-capable service in the catalog. This is only
useful with `-listen`.
- `-register-id` - Optional ID suffix for the service when `-register` is set to

2
website/content/commands/connect/redirect-traffic.mdx
View File

@ -13,7 +13,7 @@ Command: `consul connect redirect-traffic`
The connect redirect-traffic command is used to apply traffic redirection rules to enforce
all traffic to go through the [Envoy proxy](https://envoyproxy.io) when using [Consul
Service Mesh](/consul/docs/connect/) in the Transparent Proxy mode.
service mesh](/consul/docs/connect/) in the Transparent Proxy mode.
This command requires `iptables` command line utility to be installed,
and as a result, this command can currently only run on linux.

4
website/content/commands/index.mdx
View File

@ -31,13 +31,13 @@ Available commands are:
acl Interact with Consul's ACLs
agent Runs a Consul agent
catalog Interact with the catalog
connect Interact with Consul Connect
connect Interact with service mesh functionality
debug Records a debugging archive for operators
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the "left" state
info Provides debugging information for operators.
intention Interact with Connect service intentions
intention Interact with service mesh intentions
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys

2
website/content/commands/intention/index.mdx
View File

@ -9,7 +9,7 @@ description: >-
Command: `consul intention`
The `intention` command is used to interact with Connect
The `intention` command is used to interact with service mesh
[intentions](/consul/docs/connect/intentions). It exposes commands for
creating, updating, reading, deleting, checking, and managing intentions.
This command is available in Consul 1.2 and later.

2
website/content/commands/operator/usage.mdx
View File

@ -97,4 +97,4 @@ Total 3
- `-billable` - Display only billable service information. Default is `false`.
- `-connect` - Display only Connect service information. Default is `false`.
- `-connect` - Display only Consul service mesh component information. Default is `false`.

2
website/content/docs/agent/config/cli-flags.mdx
View File

@ -82,7 +82,7 @@ information.
- `-dev` ((#\_dev)) - Enable development server mode. This is useful for
quickly starting a Consul agent with all persistence options turned off, enabling
an in-memory server which can be used for rapid prototyping or developing against
the API. In this mode, [Connect is enabled](/consul/docs/connect/configuration) and
the API. In this mode, [service mesh is enabled](/consul/docs/connect/configuration) and
will by default create a new root CA certificate on startup. This mode is **not**
intended for production use as it does not write any data to disk. The gRPC port
is also defaulted to `8502` in this mode.

29
website/content/docs/agent/config/config-files.mdx
View File

@ -245,8 +245,8 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
The initial RPC uses a JWT specified with either `intro_token`,
`intro_token_file` or the `CONSUL_INTRO_TOKEN` environment variable to authorize
the request. How the JWT token is verified is controlled by the `auto_config.authorizer`
object available for use on Consul servers. Enabling this option also turns
on Connect because it is vital for `auto_config`, more specifically the CA
object available for use on Consul servers. Enabling this option also enables
service mesh because it is vital for `auto_config`, more specifically the service mesh CA
and certificates infrastructure.
~> **Warning:** Enabling `auto_config` conflicts with the [`auto_encrypt.tls`](#tls) feature.
@ -651,7 +651,7 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `primary_datacenter` - This designates the datacenter
which is authoritative for ACL information, intentions and is the root Certificate
Authority for Connect. It must be provided to enable ACLs. All servers and datacenters
Authority for service mesh. It must be provided to enable ACLs. All servers and datacenters
must agree on the primary datacenter. Setting it on the servers is all you need
for cluster-level enforcement, but for the APIs to forward properly from the clients,
it must be set on them too. In Consul 0.8 and later, this also enables agent-level
@ -946,7 +946,7 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `replication` ((#acl_tokens_replication)) - The ACL token used to
authorize secondary datacenters with the primary datacenter for replication
operations. This token is required for servers outside the [`primary_datacenter`](#primary_datacenter) when ACLs are enabled. This token may be provided later using the [agent token API](/consul/api-docs/agent#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, for which the token will require both operator "write" and intention "read" permissions for replicating CA and Intention data.
operations. This token is required for servers outside the [`primary_datacenter`](#primary_datacenter) when ACLs are enabled. This token may be provided later using the [agent token API](/consul/api-docs/agent#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 service mesh data replication, for which the token will require both operator "write" and intention "read" permissions for replicating CA and Intention data.
~> **Warning:** When enabling ACL token replication on the secondary datacenter,
policies and roles already present in the secondary datacenter will be lost. For
@ -1088,7 +1088,10 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `bootstrap_expect` Equivalent to the [`-bootstrap-expect` command-line flag](/consul/docs/agent/config/cli-flags#_bootstrap_expect).
## Connect Parameters
## Service Mesh Parameters ((#connect-parameters))
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
- `connect` This object allows setting options for the Connect feature.
@ -1096,14 +1099,14 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `enabled` ((#connect_enabled)) (Defaults to `true`) Controls whether Connect features are
enabled on this agent. Should be enabled on all servers in the cluster
in order for Connect to function properly.
in order for service mesh to function properly.
Will be set to `true` automatically if `auto_config.enabled` or `auto_encrypt.allow_tls` is `true`.
- `enable_mesh_gateway_wan_federation` ((#connect_enable_mesh_gateway_wan_federation)) (Defaults to `false`) Controls whether cross-datacenter federation traffic between servers is funneled
through mesh gateways. This was added in Consul 1.8.0.
- `ca_provider` ((#connect_ca_provider)) Controls which CA provider to
use for Connect's CA. Currently only the `aws-pca`, `consul`, and `vault` providers are supported.
use for the service mesh's CA. Currently only the `aws-pca`, `consul`, and `vault` providers are supported.
This is only used when initially bootstrapping the cluster. For an existing cluster,
use the [Update CA Configuration Endpoint](/consul/api-docs/connect/ca#update-ca-configuration).
@ -1140,13 +1143,13 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `root_pki_path` ((#vault_ca_root_pki)) The path to use for the root
CA pki backend in Vault. This can be an existing backend with a CA already
configured, or a blank/unmounted backend in which case Connect will automatically
configured, or a blank/unmounted backend in which case Consul will automatically
mount/generate the CA. The Vault token given above must have `sudo` access
to this backend, as well as permission to mount the backend at this path if
it is not already mounted.
- `intermediate_pki_path` ((#vault_ca_intermediate_pki))
The path to use for the temporary intermediate CA pki backend in Vault. **Connect
The path to use for the temporary intermediate CA pki backend in Vault. **Consul
will overwrite any data at this path in order to generate a temporary intermediate
CA**. The Vault token given above must have `write` access to this backend,
as well as permission to mount the backend at this path if it is not already
@ -1391,14 +1394,14 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati
- `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.
from the service mesh CA to the clients. If enabled, the server can accept incoming
connections from both the built-in CA and the service mesh 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.
service mesh CA and certificates from the servers, for encrypting RPC communication.
The client will make the request to any servers listed in the `-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
@ -2186,7 +2189,7 @@ specially crafted certificate signed by the CA can be used to gain full access t
~> **Security Note:** `verify_server_hostname` *must* be set to true to prevent a
compromised client from gaining full read and write access to all cluster
data *including all ACL tokens and Connect CA root keys*.
data *including all ACL tokens and service mesh CA root keys*.
- `server_name` When provided, this overrides the [`node_name`](#_node)
for the TLS certificate. It can be used to ensure that the certificate name matches

2
website/content/docs/agent/index.mdx
View File

@ -201,7 +201,7 @@ The following settings are commonly used in the configuration file (also called
### Server node in a service mesh
The following example configuration is for a server agent named "`consul-server`". The server is [bootstrapped](/consul/docs/agent/config/cli-flags#_bootstrap) and the Consul GUI is enabled.
The reason this server agent is configured for a service mesh is that the `connect` configuration is enabled. Connect is Consul's service mesh component that provides service-to-service connection authorization and encryption using mutual Transport Layer Security (TLS). Applications can use sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without being aware of Connect at all. See [Connect](/consul/docs/connect) for details.
The reason this server agent is configured for a service mesh is that the `connect` configuration is enabled. The connect subsystem provides Consul's service mesh capabilities, including service-to-service connection authorization and encryption using mutual Transport Layer Security (TLS). Applications can use sidecar proxies in a service mesh configuration to establish TLS connections for inbound and outbound connections without being aware of Consul service mesh at all. Refer to [Consul Service Mesh](/consul/docs/connect) for details.
<CodeTabs>

14
website/content/docs/agent/telemetry.mdx
View File

@ -413,7 +413,7 @@ This is a full list of metrics emitted by Consul.
| `consul.state.services` | Measures the current number of unique services registered with Consul, based on service name. It is only emitted by Consul servers. Added in v1.9.0. | number of objects | gauge |
| `consul.state.service_instances` | Measures the current number of unique service instances registered with Consul. It is only emitted by Consul servers. Added in v1.9.0. | number of objects | gauge |
| `consul.state.kv_entries` | Measures the current number of entries in the Consul KV store. It is only emitted by Consul servers. Added in v1.10.3. | number of objects | gauge |
| `consul.state.connect_instances` | Measures the current number of unique connect service instances registered with Consul labeled by Kind (e.g. connect-proxy, connect-native, etc). Added in v1.10.4 | number of objects | gauge |
| `consul.state.connect_instances` | Measures the current number of unique mesh service instances registered with Consul labeled by Kind (e.g. connect-proxy, connect-native, etc). Added in v1.10.4 | number of objects | gauge |
| `consul.state.config_entries` | Measures the current number of configuration entries registered with Consul labeled by Kind (e.g. service-defaults, proxy-defaults, etc). See [Configuration Entries](/consul/docs/connect/config-entries) for more information. Added in v1.10.4 | number of objects | gauge |
| `consul.members.clients` | Measures the current number of client agents registered with Consul. It is only emitted by Consul servers. Added in v1.9.6. | number of clients | gauge |
| `consul.members.servers` | Measures the current number of server agents registered with Consul. It is only emitted by Consul servers. Added in v1.9.6. | number of servers | gauge |
@ -687,14 +687,14 @@ are allowed for <EnterpriseAlert inline />.
| `consul.catalog.service.query-tag` | Increments for each catalog query for the given service with the given tag. | queries | counter |
| `consul.catalog.service.query-tags` | Increments for each catalog query for the given service with the given tags. | queries | counter |
| `consul.catalog.service.not-found` | Increments for each catalog query where the given service could not be found. | queries | counter |
| `consul.catalog.connect.query` | Increments for each connect-based catalog query for the given service. | queries | counter |
| `consul.catalog.connect.query-tag` | Increments for each connect-based catalog query for the given service with the given tag. | queries | counter |
| `consul.catalog.connect.query-tags` | Increments for each connect-based catalog query for the given service with the given tags. | queries | counter |
| `consul.catalog.connect.not-found` | Increments for each connect-based catalog query where the given service could not be found. | queries | counter |
| `consul.catalog.connect.query` | Increments for each mesh-based catalog query for the given service. | queries | counter |
| `consul.catalog.connect.query-tag` | Increments for each mesh-based catalog query for the given service with the given tag. | queries | counter |
| `consul.catalog.connect.query-tags` | Increments for each mesh-based catalog query for the given service with the given tags. | queries | counter |
| `consul.catalog.connect.not-found` | Increments for each mesh-based catalog query where the given service could not be found. | queries | counter |
## Connect Built-in Proxy Metrics
## Service Mesh Built-in Proxy Metrics
Consul Connect's built-in proxy is by default configured to log metrics to the
Consul service mesh's built-in proxy is by default configured to log metrics to the
same sink as the agent that starts it.
When running in this mode it emits some basic metrics. These will be expanded

2
website/content/docs/architecture/scale.mdx
View File

@ -257,7 +257,7 @@ Consul ESM enables health checks and monitoring for external services. When usin
Because Consul’s service mesh uses service discovery subsystems, service mesh performance is also optimized by deploying multiple small clusters with consistent numbers of service instances and watches. Service mesh performance is influenced by the following additional factors:
- The [transparent proxy](/consul/docs/connect/transparent-proxy) feature causes client agents to listen for service instance updates across all services instead of a subset. To prevent performance issues, we recommend that you do not use the permissive intention, `default: allow`, with the transparent proxy feature. When combined, every service instance update propagates to every proxy, which causes additional server load.
- When you use the [built in CA provider](/consul/docs/connect/ca/consul#built-in-ca), Consul leaders are responsible for signing certificates used for mTLS across the service mesh. The impact on CPU utilization depends on the total number of service instances and configured certificate TTLs. You can use the [CA provider configuration options](/consul/docs/agent/config/config-files#common-ca-config-options) to control the number of requests a server processes. We recommend adjusting [`csr_max_concurrent`](/consul/docs/agent/config/config-files#ca_csr_max_concurrent) and [`csr_max_per_second`](/consul/docs/agent/config/config-files#ca_csr_max_concurrent) to suit your environment.
- When you use the [built-in service mesh CA provider](/consul/docs/connect/ca/consul#built-in-ca), Consul leaders are responsible for signing certificates used for mTLS across the service mesh. The impact on CPU utilization depends on the total number of service instances and configured certificate TTLs. You can use the [CA provider configuration options](/consul/docs/agent/config/config-files#common-ca-config-options) to control the number of requests a server processes. We recommend adjusting [`csr_max_concurrent`](/consul/docs/agent/config/config-files#ca_csr_max_concurrent) and [`csr_max_per_second`](/consul/docs/agent/config/config-files#ca_csr_max_concurrent) to suit your environment.
### K/V store

6
website/content/docs/connect/ca/aws.mdx
View File

@ -49,7 +49,7 @@ optional configuration value.
Example configurations are shown below:
<CodeTabs heading="Connect CA configuration" tabs={["Agent configuration", "API"]}>
<CodeTabs heading="Service mesh CA configuration" tabs={["Agent configuration", "API"]}>
<CodeBlockConfig filename="/etc/consul.d/config.hcl" highlight="4,6">
@ -116,7 +116,7 @@ ACM Private CA has several
that restrict how fast certificates can be issued. This may impact how quickly
large clusters can rotate all issued certificates.
Currently, the ACM Private CA provider for Connect has some additional
Currently, the ACM Private CA provider for service mesh has some additional
limitations described below.
### Unable to Cross-sign Other CAs
@ -150,7 +150,7 @@ CA](https://aws.amazon.com/certificate-manager/pricing/) for actual cost
information.
Assume the following Consul datacenters exist and are configured to use ACM
Private CA as their Connect CA with the default leaf certificate lifetime of
Private CA as their service mesh CA with the default leaf certificate lifetime of
72 hours:
| Datacenter | Primary | CA Resource Created | Number of service instances |

10
website/content/docs/connect/ca/consul.mdx
View File

@ -7,12 +7,12 @@ description: >-
# Built-In Certificate Authority for Service Mesh
Consul ships with a built-in CA system so that Connect can be
Consul ships with a built-in CA system so that service mesh can be
easily enabled out of the box. The built-in CA generates and stores the
root certificate and private key on Consul servers. It can also be
configured with a custom certificate and private key if needed.
If Connect is enabled and no CA provider is specified, the built-in
If service mesh is enabled and no CA provider is specified, the built-in
CA is the default provider used. The provider can be
[updated and rotated](/consul/docs/connect/ca#root-certificate-rotation)
at any point to migrate to a new provider.
@ -24,7 +24,7 @@ CA providers.
## Configuration
The built-in CA provider has no required configuration. Enabling Connect
The built-in CA provider has no required configuration. Enabling service mesh
alone will configure the built-in CA provider, and will automatically generate
a root certificate and private key:
@ -84,8 +84,8 @@ $ curl localhost:8500/v1/connect/ca/configuration
}
```
This is the default Connect CA configuration if nothing is explicitly set when
Connect is enabled - the PrivateKey and RootCert fields have not been set, so those have
This is the default service mesh CA configuration if nothing is explicitly set when
service mesh is enabled - the PrivateKey and RootCert fields have not been set, so those have
been generated (as seen above in the roots list).
There are two ways to have the Consul CA use a custom private key and root certificate:

10
website/content/docs/connect/ca/index.mdx
View File

@ -7,8 +7,8 @@ description: >-
# Service Mesh Certificate Authority Overview
Certificate management in Connect is done centrally through the Consul
servers using the configured CA (Certificate Authority) provider. A CA provider
Service mesh certificate management is done centrally through the Consul
servers using the configured service mesh CA (Certificate Authority) provider. A CA provider
manages root and intermediate certificates and performs certificate signing
operations. The Consul leader orchestrates CA provider operations as necessary,
such as when a service needs a new certificate or during CA rotation events.
@ -42,7 +42,7 @@ datacenter.
CA initialization happens automatically when a new Consul leader is elected
as long as
[Connect is enabled](/consul/docs/connect/configuration#agent-configuration),
[service mesh is enabled](/consul/docs/connect/configuration#agent-configuration),
and the CA system has not already been initialized. This initialization process
will generate the initial root certificates and setup the internal Consul server
state.
@ -55,7 +55,7 @@ If a CA is already initialized, any changes to the CA configuration in the
agent configuration file (including removing the configuration completely)
will have no effect.
If no specific provider is configured when Connect is enabled, the built-in
If no specific provider is configured when service mesh is enabled, the built-in
Consul CA provider will be used and a private key and root certificate will
be generated automatically.
@ -133,7 +133,7 @@ Cross-Signing](#forced-rotation-without-cross-signing).
This also automatically occurs when a completely different CA provider is
configured (since this changes the root key). Therefore, this automatic rotation
process can also be used to cleanly transition between CA providers. For example,
updating Connect to use Vault instead of the built-in CA.
updating the service mesh to use Vault instead of the built-in CA.
During rotation, an intermediate CA certificate is requested from the new root,
which is then cross-signed by the old root. This cross-signed certificate is

4
website/content/docs/connect/ca/vault.mdx
View File

@ -19,7 +19,7 @@ This page describes how configure the Vault CA provider.
- Vault 0.10.3 to 1.10.x.
~> **Compatibility note:** If you use Vault 1.11.0+ as Consul's Connect CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
~> **Compatibility note:** If you use Vault 1.11.0+ as Consul's service mesh CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
## Enable Vault as the CA
@ -32,7 +32,7 @@ Refer to the [Configuration Reference](#configuration-reference) for details abo
The following example shows the required configurations for a default implementation:
<CodeTabs heading="Connect CA configuration" tabs={["Agent configuration", "API"]}>
<CodeTabs heading="Service mesh CA configuration" tabs={["Agent configuration", "API"]}>
<CodeBlockConfig filename="/etc/consul.d/config.hcl" highlight="4,6-9">

2
website/content/docs/connect/config-entries/index.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Configuration Entry Overview
Configuration entries can be used to configure the behavior of Consul Connect.
Configuration entries can be used to configure the behavior of Consul service mesh.
The following configuration entries are supported:

2
website/content/docs/connect/config-entries/mesh.mdx
View File

@ -333,7 +333,7 @@ Note that the Kubernetes example does not include a `partition` field. Configura
type: 'bool: false',
description: `Determines whether sidecar proxies operating in transparent mode can
proxy traffic to IP addresses not registered in Consul's mesh. If enabled, traffic will only be proxied
to upstream proxies or Connect-native services. If disabled, requests will be proxied as-is to the
to upstream proxies or mesh-native services. If disabled, requests will be proxied as-is to the
original destination IP address. Consul will not encrypt the connection.`,
},
],

8
website/content/docs/connect/config-entries/proxy-defaults.mdx
View File

@ -342,8 +342,8 @@ spec:
{
name: 'Config',
type: 'map[string]arbitrary',
description: `An arbitrary map of configuration values used by Connect proxies.
The available configurations depend on the Connect proxy you use.
description: `An arbitrary map of configuration values used by service mesh proxies.
The available configurations depend on the mesh proxy you use.
Any values that your proxy allows can be configured globally here. To explore these options please see the documentation for your chosen proxy.
<ul><li>[Envoy](/consul/docs/connect/proxies/envoy#proxy-config-options)</li>
<li>[Consul's built-in proxy](/consul/docs/connect/proxies/built-in#proxy-config-key-reference)</li></ul>`,
@ -409,7 +409,7 @@ spec:
name: 'MeshGateway',
type: 'MeshGatewayConfig: <optional>',
description: `Controls the default
[mesh gateway configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
[mesh gateway configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration)
for all proxies. Added in v1.6.0.`,
children: [
{
@ -426,7 +426,7 @@ spec:
[expose path configuration](/consul/docs/connect/registration/service-registration#expose-paths-configuration-reference)
for Envoy. Added in v1.6.2.<br><br>
Exposing paths through Envoy enables a service to protect itself by only listening on localhost, while still allowing
non-Connect-enabled applications to contact an HTTP endpoint.
non-mesh-enabled applications to contact an HTTP endpoint.
Some examples include: exposing a \`/metrics\` path for Prometheus or \`/healthz\` for kubelet liveness checks.`,
children: [
{

16
website/content/docs/connect/config-entries/service-defaults.mdx
View File

@ -570,7 +570,7 @@ We recommend configuring the upstream timeout in the [`connection_timeout`](/con
### `UpstreamConfig.Overrides[].MeshGateway`
Map that contains the default mesh gateway `mode` field for the upstream. Refer to [Connect Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) in the mesh gateway documentation for additional information.
Map that contains the default mesh gateway `mode` field for the upstream. Refer to [Service Mesh Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration) in the mesh gateway documentation for additional information.
#### Values
@ -651,7 +651,7 @@ For non-Kubernetes environments, we recommend configuring the upstream timeout i
### `UpstreamConfig.Defaults.MeshGateway`
Specifies the default mesh gateway `mode` field for all upstreams. Refer to [Connect Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) in the mesh gateway documentation for additional information.
Specifies the default mesh gateway `mode` field for all upstreams. Refer to [Service Mesh Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration) in the mesh gateway documentation for additional information.
You can specify the following string values for the `mode` field:
@ -743,7 +743,7 @@ Specifies the timeout for HTTP requests to the local application instance. Appli
### `MeshGateway`
Specifies the default mesh gateway `mode` field for the service. Refer to [Connect Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) in the mesh gateway documentation for additional information.
Specifies the default mesh gateway `mode` field for the service. Refer to [Service Mesh Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration) in the mesh gateway documentation for additional information.
You can specify the following string values for the `mode` field:
@ -1030,7 +1030,7 @@ We recommend configuring the upstream timeout in the [`connectTimeout`](/consul/
### `spec.upstreamConfig.defaults.meshGateway.mode`
Specifies the default mesh gateway `mode` field for all upstreams. Refer to [Connect Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) in the mesh gateway documentation for additional information.
Specifies the default mesh gateway `mode` field for all upstreams. Refer to [Service Mesh Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration) in the mesh gateway documentation for additional information.
#### Values
@ -1144,7 +1144,7 @@ Specifies the timeout for HTTP requests to the local application instance. Appli
- Data type: string
### `spec.meshGateway.mode`
Specifies the default mesh gateway `mode` field for the service. Refer to [Connect Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration) in the mesh gateway documentation for additional information.
Specifies the default mesh gateway `mode` field for the service. Refer to [Service Mesh Proxy Configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration) in the mesh gateway documentation for additional information.
#### Values
@ -1532,7 +1532,7 @@ represents a location outside the Consul cluster. Services can dial destinations
name: 'Protocol',
type: `string: "tcp"`,
description: `Sets the protocol of the service. This is used
by Connect proxies for things like observability features and to unlock usage
by service mesh proxies for things like observability features and to unlock usage
of the [\`service-splitter\`](/consul/docs/connect/config-entries/service-splitter) and
[\`service-router\`](/consul/docs/connect/config-entries/service-router) config entries
for a service. It also unlocks the ability to define L7 intentions via
@ -2012,7 +2012,7 @@ represents a location outside the Consul cluster. Services can dial destinations
type: 'string: ""',
description: `This is an optional setting that allows for
the TLS [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) value to
be changed to a non-connect value when federating with an external system.
be changed to a non-mesh value when federating with an external system.
Added in v1.6.0.`,
},
{
@ -2022,7 +2022,7 @@ represents a location outside the Consul cluster. Services can dial destinations
[expose path configuration](/consul/docs/connect/registration/service-registration#expose-paths-configuration-reference)
for Envoy. Added in v1.6.2.<br><br>
Exposing paths through Envoy enables a service to protect itself by only listening on localhost, while still allowing
non-Connect-enabled applications to contact an HTTP endpoint.
non-mesh-enabled applications to contact an HTTP endpoint.
Some examples include: exposing a \`/metrics\` path for Prometheus or \`/healthz\` for kubelet liveness checks.`,
children: [
{

2
website/content/docs/connect/config-entries/service-resolver.mdx
View File

@ -11,7 +11,7 @@ description: >-
**v1.6.0+:** On other platforms, this config entry is supported in Consul versions 1.6.0+.
The `service-resolver` config entry kind (`ServiceResolver` on Kubernetes) controls which service instances
should satisfy Connect upstream discovery requests for a given service name.
should satisfy service mesh upstream discovery requests for a given service name.
If no resolver config is defined the chain assumes 100% of traffic goes to the
healthy instances of the default service in the current datacenter+namespace

4
website/content/docs/connect/config-entries/service-router.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Service Router Configuration Entry
The `service-router` config entry kind (`ServiceRouter` on Kubernetes) controls Connect traffic routing and
The `service-router` config entry kind (`ServiceRouter` on Kubernetes) controls service mesh traffic routing and
manipulation at networking layer 7 (e.g. HTTP).
If a router is not explicitly configured or is configured with no routes then
@ -16,7 +16,7 @@ service of the same name.
## Requirements
- Consul [service mesh connect](/consul/docs/connect/configuration) enabled services
- Consul [service mesh](/consul/docs/connect/configuration) enabled services
- Service to service communication over the protocol `http`
## Interaction with other Config Entries

4
website/content/docs/connect/config-entries/terminating-gateway.mdx
View File

@ -12,7 +12,7 @@ description: >-
The `terminating-gateway` config entry kind (`TerminatingGateway` on Kubernetes) allows you to configure terminating gateways
to proxy traffic from services in the Consul service mesh to services registered with Consul that do not have a
[Connect service sidecar proxy](/consul/docs/connect/proxies). The configuration is associated with the name of a gateway service
[service mesh sidecar proxy](/consul/docs/connect/proxies). The configuration is associated with the name of a gateway service
and will apply to all instances of the gateway with that name.
~> [Configuration entries](/consul/docs/agent/config-entries) are global in scope. A configuration entry for a gateway name applies
@ -41,7 +41,7 @@ Terminating gateways can optionally target all services within a Consul namespac
as the service name. Configuration options set on the wildcard act as defaults that can be overridden
by options set on a specific service name.
Note that if the wildcard specifier is used, and some services in that namespace have a Connect sidecar proxy,
Note that if the wildcard specifier is used, and some services in that namespace have a service mesh sidecar proxy,
traffic from the mesh to those services will be evenly load-balanced between the gateway and their sidecars.
## Sample Config Entries

43
website/content/docs/connect/configuration.mdx
View File

@ -2,7 +2,7 @@
layout: docs
page_title: Service Mesh Configuration - Overview
description: >-
Learn how to enable and configure Consul's service mesh capabilities in agent configurations, and how to integrate with schedulers like Kubernetes and Nomad. ""Connect"" is the subsystem that provides Consul’s service mesh capabilities.
Learn how to enable and configure Consul's service mesh capabilities in agent configurations, and how to integrate with schedulers like Kubernetes and Nomad. Consul's service mesh capabilities are provided by the ""connect"" subsystem.
---
# Service Mesh Configuration Overview
@ -11,14 +11,17 @@ There are many configuration options exposed for Consul service mesh. The only o
that must be set is the `connect.enabled` option on Consul servers to enable Consul service mesh.
All other configurations are optional and have defaults suitable for many environments.
The terms _Consul Connect_ and _Consul service mesh_ are used interchangeably throughout this documentation.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
Where you encounter the _noun_ connect, it is usually functionality specific to
service mesh.
## Agent configuration
Begin by enabling Connect for your Consul
cluster. By default, Connect is disabled. Enabling Connect requires changing
Begin by enabling service mesh for your Consul
cluster. By default, service is disabled. Enabling service mesh requires changing
the configuration of only your Consul _servers_ (not client agents). To enable
Connect, add the following to a new or existing
service mesh, add the following to a new or existing
[server configuration file](/consul/docs/agent/config/config-files). In an existing cluster, this configuration change requires a Consul server restart, which you can perform one server at a time to maintain availability. In HCL:
@ -37,17 +40,17 @@ connect {
```
</CodeTabs>
This will enable Connect and configure your Consul cluster to use the
This will enable service mesh and configure your Consul cluster to use the
built-in certificate authority for creating and managing certificates.
You may also configure Consul to use an external
[certificate management system](/consul/docs/connect/ca), such as
[Vault](https://www.vaultproject.io/).
Services and proxies may always register with Connect settings, but they will
fail to retrieve or verify any TLS certificates. This causes all Connect-based
connection attempts to fail until Connect is enabled on the server agents.
Services and proxies may always register with service mesh settings, but unless
service mesh is enabled on the server agents, their attempts to communicate will fail
because they have no means to obtain or verify service mesh TLS certificates.
Other optional Connect configurations that you can set in the server
Other optional service mesh configurations that you can set in the server
configuration file include:
- [certificate authority settings](/consul/docs/agent/config/config-files#connect)
@ -55,10 +58,10 @@ configuration file include:
- [dev mode](/consul/docs/agent/config/cli-flags#_dev)
- [server host name verification](/consul/docs/agent/config/config-files#tls_internal_rpc_verify_server_hostname)
If you would like to use Envoy as your Connect proxy you will need to [enable
If you would like to use Envoy as your service mesh proxy you will need to [enable
gRPC](/consul/docs/agent/config/config-files#grpc_port).
Additionally if you plan on using the observability features of Connect, it can
Additionally if you plan on using the observability features of Consul service mesh, it can
be convenient to configure your proxies and services using [configuration
entries](/consul/docs/agent/config-entries) which you can interact with using the
CLI or API, or by creating configuration entry files. You will want to enable
@ -67,8 +70,8 @@ configuration](/consul/docs/agent/config/config-files#enable_central_service_con
clients, which allows each service's proxy configuration to be managed centrally
via API.
!> **Security note:** Enabling Connect is enough to try the feature but doesn't
automatically ensure complete security. Please read the [Connect production
!> **Security note:** Enabling service mesh is enough to try the feature but doesn't
automatically ensure complete security. Please read the [service mesh production
tutorial](/consul/tutorials/developer-mesh/service-mesh-production-checklist) to understand the additional steps
needed for a secure deployment.
@ -81,7 +84,7 @@ definitions](/consul/docs/services/usage/define-services).
## Schedulers
Consul Connect is especially useful if you are using an orchestrator like Nomad
Consul service mesh is especially useful if you are using an orchestrator like Nomad
or Kubernetes, because these orchestrators can deploy thousands of service instances
which frequently move hosts. Sidecars for each service can be configured through
these schedulers, and in some cases they can automate Consul configuration,
@ -89,16 +92,16 @@ sidecar deployment, and service registration.
### Nomad
Connect can be used with Nomad to provide secure service-to-service
Consul service mesh can be used with Nomad to provide secure service-to-service
communication between Nomad jobs and task groups. The ability to use the dynamic
port feature of Nomad makes Connect particularly easy to use. Learn about how to
configure Connect on Nomad by reading the
port feature of Nomad makes Consul service mesh particularly easy to use. Learn about how to
configure Consul service mesh on Nomad by reading the
[integration documentation](/consul/docs/connect/nomad).
### Kubernetes
The Consul Helm chart can automate much of Consul Connect's configuration, and
The Consul Helm chart can automate much of Consul's service mesh configuration, and
makes it easy to automatically inject Envoy sidecars into new pods when they are
deployed. Learn about the [Helm chart](/consul/docs/k8s/helm) in general,
or if you are already familiar with it, check out its
[connect specific configurations](/consul/docs/k8s/connect).
[service mesh specific configurations](/consul/docs/k8s/connect).

7
website/content/docs/connect/connect-internals.mdx
View File

@ -11,7 +11,10 @@ This topic describes how many of the core features of Consul's service mesh func
It is not a prerequisite,
but this information will help you understand how Consul service mesh behaves in more complex scenarios.
Consul Connect is the component shipped with Consul that enables service mesh functionality. The terms _Consul Connect_ and _Consul service mesh_ are used interchangeably throughout this documentation.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
Where you encounter the _noun_ connect, it is usually functionality specific to
service mesh.
To try service mesh locally, complete the [Getting Started with Consul service
mesh](/consul/tutorials/kubernetes-deploy/service-mesh?utm_source=docs)
@ -59,7 +62,7 @@ in-memory data.
## Agent Caching and Performance
To enable fast responses on endpoints such as the [agent Connect
To enable fast responses on endpoints such as the [agent connect
API](/consul/api-docs/agent/connect), the Consul agent locally caches most Consul service mesh-related
data and sets up background [blocking queries](/consul/api-docs/features/blocking) against
the server to update the cache in the background. This allows most API calls

2
website/content/docs/connect/connectivity-tasks.mdx
View File

@ -59,7 +59,7 @@ Services outside the mesh do not have sidecar proxies or are not [integrated nat
These may be services running on legacy infrastructure or managed cloud services running on
infrastructure you do not control.
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate Connect
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate service mesh
mTLS connections, enforce Consul intentions, and forward requests to the appropriate destination.
These gateways also simplify authorization from dynamic service addresses. Consul's intentions determine whether

6
website/content/docs/connect/dev.mdx
View File

@ -8,17 +8,17 @@ description: >-
# Service Mesh Debugging
It is often necessary to connect to a service for development or debugging.
If a service only exposes a Connect listener, then we need a way to establish
If a service only exposes a service mesh listener, then we need a way to establish
a mutual TLS connection to the service. The
[`consul connect proxy` command](/consul/commands/connect/proxy) can be used
for this task on any machine with access to a Consul agent (local or remote).
Restricting access to services only via Connect ensures that the only way to
Restricting access to services only via servoce ,esj ensures that the only way to
connect to a service is through valid authorization of the
[intentions](/consul/docs/connect/intentions). This can extend to developers
and operators, too.
## Connecting to Connect-only Services
## Connecting to Mesh-only Services
As an example, let's assume that we have a PostgreSQL database running that
we want to connect to via `psql`, but the only non-loopback listener is

2
website/content/docs/connect/gateways/api-gateway/usage.mdx
View File

@ -12,7 +12,7 @@ in a Kubernetes environment, refer to [API Gateway for Kubernetes](/consul/docs/
## Introduction
Consul API gateways provide a configurable ingress points for requests into a Consul network. Usethe following configuration entries to set up API gateways:
Consul API gateways provide a configurable ingress points for requests into a Consul network. Use the following configuration entries to set up API gateways:
- [API gateway](/consul/docs/connect/gateways/api-gateway/configuration/api-gateway): Provides an endpoint for requests to enter the network. Define listeners that expose ports on the endpoint for ingress.
- [HTTP routes](/consul/docs/connect/gateways/api-gateway/configuration/http-route) and [TCP routes](/consul/docs/connect/gateways/api-gateway/configuration/tcp-route): The routes attach to listeners defined in the gateway and control how requests route to services in the network.

2
website/content/docs/connect/gateways/index.mdx
View File

@ -64,7 +64,7 @@ Services outside the mesh do not have sidecar proxies or are not [integrated nat
These may be services running on legacy infrastructure or managed cloud services running on
infrastructure you do not control.
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate Connect
Terminating gateways effectively act as egress proxies that can represent one or more services. They terminate service mesh
mTLS connections, enforce Consul intentions, and forward requests to the appropriate destination.
These gateways also simplify authorization from dynamic service addresses. Consul's intentions determine whether

6
website/content/docs/connect/gateways/ingress-gateway.mdx
View File

@ -39,7 +39,7 @@ the [hosts](/consul/docs/connect/config-entries/ingress-gateway#hosts) field.
Ingress gateways also require that your Consul datacenters are configured correctly:
- You'll need to use Consul version 1.8.0 or newer.
- Consul [Connect](/consul/docs/agent/config/config-files#connect) must be enabled on the datacenter's Consul servers.
- Consul [service mesh](/consul/docs/agent/config/config-files#connect) must be enabled on the datacenter's Consul servers.
- [gRPC](/consul/docs/agent/config/config-files#grpc_port) must be enabled on all client agents.
Currently, [Envoy](https://www.envoyproxy.io/) is the only proxy with ingress gateway capabilities in Consul.
@ -54,13 +54,13 @@ review the [ingress gateway tutorial](/consul/tutorials/developer-mesh/service-m
Ingress gateways are configured in service definitions and registered with Consul like other services, with two exceptions.
The first is that the [kind](/consul/api-docs/agent/service#kind) must be "ingress-gateway". Second,
the ingress gateway service definition may contain a `Proxy.Config` entry just like a
Connect proxy service, to define opaque configuration parameters useful for the actual proxy software.
service mesh proxy service, to define opaque configuration parameters useful for the actual proxy software.
For Envoy there are some supported [gateway options](/consul/docs/connect/proxies/envoy#gateway-options) as well as
[escape-hatch overrides](/consul/docs/connect/proxies/envoy#escape-hatch-overrides).
-> **Note:** If ACLs are enabled, ingress gateways must be registered with a token granting `service:write` for the ingress gateway's service name,
`service:read` for all services in the ingress gateway's configuration entry, and `node:read` for all nodes of the services
in the ingress gateway's configuration entry. These privileges authorize the token to route communications to other Connect services.
in the ingress gateway's configuration entry. These privileges authorize the token to route communications to other mesh services.
If the Consul client agent on the gateway's node is not configured to use the default gRPC port, 8502, then the gateway's token
must also provide `agent:read` for its node's name in order to discover the agent's gRPC port. gRPC is used to expose Envoy's xDS API to Envoy proxies.

12
website/content/docs/connect/gateways/mesh-gateway/index.mdx
View File

@ -57,17 +57,17 @@ Configure the following settings to register the mesh gateway as a service in Co
Each upstream associated with a service mesh proxy can be configured so that it is routed through a mesh gateway.
Depending on your network, the proxy's connection to the gateway can operate in one of the following modes:
* `none` - No gateway is used and a service mesh connect proxy makes its outbound connections directly
* `none` - No gateway is used and a service mesh sidecar proxy makes its outbound connections directly
to the destination services. This is the default for WAN federation. This setting is invalid for peered clusters
and will be treated as remote instead.
* `local` - The service mesh connect proxy makes an outbound connection to a gateway running in the
* `local` - The service mesh sidecar proxy makes an outbound connection to a gateway running in the
same datacenter. That gateway is responsible for ensuring that the data is forwarded to gateways in the destination datacenter.
* `remote` - The service mesh proxy makes an outbound connection to a gateway running in the destination datacenter.
* `remote` - The service mesh sidecar proxy makes an outbound connection to a gateway running in the destination datacenter.
The gateway forwards the data to the final destination service. This is the default for peered clusters.
### Connect Proxy Configuration
### Service Mesh Proxy Configuration
Set the proxy to the preferred [mode](#modes) to configure the service mesh proxy. You can specify the mode globally or within child configurations to control proxy behaviors at a lower level. Consul recognizes the following order of precedence if the gateway mode is configured in multiple locations the order of precedence:
@ -82,7 +82,7 @@ Use the following example configurations to help you understand some of the comm
### Enabling Gateways Globally
The following `proxy-defaults` configuration will enable gateways for all Connect services in the `local` mode.
The following `proxy-defaults` configuration will enable gateways for all mesh services in the `local` mode.
<CodeTabs heading="Example: Enabling gateways globally.">
@ -104,7 +104,7 @@ Name: global
### Enabling Gateways Per Service
The following `service-defaults` configuration will enable gateways for all Connect services with the name `web`.
The following `service-defaults` configuration will enable gateways for all mesh services with the name `web`.
<CodeTabs heading="Example: Enabling gateways per service.">

8
website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-partitions.mdx
View File

@ -36,7 +36,7 @@ Consul can only translate mesh gateway registration information into Envoy confi
Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration.
Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a Connect sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway.
Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a service mesh sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway.
## Configuration
@ -61,7 +61,7 @@ Depending on your network, the proxy's connection to the gateway can operate in
* `remote` - The service mesh connect proxy makes an outbound connection to a gateway running in the destination datacenter.
The gateway forwards the data to the final destination service.
### Connect Proxy Configuration
### Service Mesh Proxy Configuration
Set the proxy to the preferred [mode](#modes) to configure the service mesh proxy. You can specify the mode globally or within child configurations to control proxy behaviors at a lower level. Consul recognizes the following order of precedence if the gateway mode is configured in multiple locations the order of precedence:
@ -76,7 +76,7 @@ Use the following example configurations to help you understand some of the comm
### Enabling Gateways Globally
The following `proxy-defaults` configuration will enable gateways for all Connect services in the `local` mode.
The following `proxy-defaults` configuration will enable gateways for all mesh services in the `local` mode.
<CodeTabs heading="Example: Enabling gateways globally.">
@ -99,7 +99,7 @@ Name: global
### Enabling Gateways Per Service
The following `service-defaults` configuration will enable gateways for all Connect services with the name `web`.
The following `service-defaults` configuration will enable gateways for all mesh services with the name `web`.
<CodeTabs heading="Example: Enabling gateways per service.">

18
website/content/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters.mdx
View File

@ -29,10 +29,10 @@ Ensure that your Consul environment meets the following requirements.
* Consul version 1.6.0 or newer.
* A local Consul agent is required to manage its configuration.
* Consul [Connect](/consul/docs/agent/config/config-files#connect) must be enabled in both datacenters.
* Consul [service mesh](/consul/docs/agent/config/config-files#connect) must be enabled in both datacenters.
* Each [datacenter](/consul/docs/agent/config/config-files#datacenter) must have a unique name.
* Each datacenters must be [WAN joined](/consul/tutorials/networking/federation-gossip-wan).
* The [primary datacenter](/consul/docs/agent/config/config-files#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for Connect certificates and is required for services in all datacenters to establish mutual TLS with each other.
* The [primary datacenter](/consul/docs/agent/config/config-files#primary_datacenter) must be set to the same value in both datacenters. This specifies which datacenter is the authority for service mesh certificates and is required for services in all datacenters to establish mutual TLS with each other.
* [gRPC](/consul/docs/agent/config/config-files#grpc_port) must be enabled.
* If you want to [enable gateways globally](/consul/docs/connect/gateways/mesh-gateway/service-to-service-traffic-wan-datacenters#enabling-gateways-globally) you must enable [centralized configuration](/consul/docs/agent/config/config-files#enable_central_service_config).
@ -50,7 +50,7 @@ Consul can only translate mesh gateway registration information into Envoy confi
Sidecar proxies that send traffic to an upstream service through a gateway need to know the location of that gateway. They discover the gateway based on their sidecar proxy registrations. Consul can only translate the gateway registration information into Envoy configuration.
Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a Connect sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway.
Sidecar proxies that do not send upstream traffic through a gateway are not affected when you deploy gateways. If you are using Consul's built-in proxy as a service mesh sidecar it will continue to work for intra-datacenter traffic and will receive incoming traffic even if that traffic has passed through a gateway.
## Configuration
@ -66,18 +66,18 @@ Configure the following settings to register the mesh gateway as a service in Co
Each upstream associated with a service mesh proxy can be configured so that it is routed through a mesh gateway.
Depending on your network, the proxy's connection to the gateway can operate in one of the following modes (refer to the [mesh-architecture-diagram](#mesh-architecture-diagram)):
* `none` - (Default) No gateway is used and a service mesh connect proxy makes its outbound connections directly
* `none` - (Default) No gateway is used and a service mesh sidecar proxy makes its outbound connections directly
to the destination services.
* `local` - The service mesh connect proxy makes an outbound connection to a gateway running in the
* `local` - The service mesh sidecar proxy makes an outbound connection to a gateway running in the
same datacenter. That gateway is responsible for ensuring that the data is forwarded to gateways in the destination datacenter.
Refer to the flow labeled `local` in the [mesh-architecture-diagram](#mesh-architecture-diagram).
* `remote` - The service mesh proxy makes an outbound connection to a gateway running in the destination datacenter.
* `remote` - The service mesh sidecar proxy makes an outbound connection to a gateway running in the destination datacenter.
The gateway forwards the data to the final destination service.
Refer to the flow labeled `remote` in the [mesh-architecture-diagram](#mesh-architecture-diagram).
### Connect Proxy Configuration
### Service Mesh Proxy Configuration
Set the proxy to the preferred [mode](#modes) to configure the service mesh proxy. You can specify the mode globally or within child configurations to control proxy behaviors at a lower level. Consul recognizes the following order of precedence if the gateway mode is configured in multiple locations the order of precedence:
@ -92,7 +92,7 @@ Use the following example configurations to help you understand some of the comm
### Enabling Gateways Globally
The following `proxy-defaults` configuration will enable gateways for all Connect services in the `local` mode.
The following `proxy-defaults` configuration will enable gateways for all mesh services in the `local` mode.
<CodeTabs heading="Example: Enabling gateways globally.">
@ -114,7 +114,7 @@ Name: global
### Enabling Gateways Per Service
The following `service-defaults` configuration will enable gateways for all Connect services with the name `web`.
The following `service-defaults` configuration will enable gateways for all mesh services with the name `web`.
<CodeTabs heading="Example: Enabling gateways per service.">

14
website/content/docs/connect/gateways/terminating-gateway.mdx
View File

@ -10,8 +10,8 @@ description: >-
-> **1.8.0+:** This feature is available in Consul versions 1.8.0 and newer.
Terminating gateways enable connectivity within your organizational network from services in the Consul service mesh to
services and [destinations](/consul/docs/connect/config-entries/service-defaults#terminating-gateway-destination) outside the mesh. These gateways effectively act as Connect proxies that can
represent more than one service. They terminate Connect mTLS connections, enforce intentions,
services and [destinations](/consul/docs/connect/config-entries/service-defaults#terminating-gateway-destination) outside the mesh. These gateways effectively act as service mesh proxies that can
represent more than one service. They terminate service mesh mTLS connections, enforce intentions,
and forward requests to the appropriate destination.
![Terminating Gateway Architecture](/img/terminating-gateways.png)
@ -26,7 +26,7 @@ for filtering by instance.
## Security Considerations
~> We recommend that terminating gateways are not exposed to the WAN or open internet. This is because terminating gateways
hold certificates to decrypt Consul Connect traffic directed at them and may be configured with credentials to connect
hold certificates to decrypt Consul service mesh traffic directed at them and may be configured with credentials to connect
to linked services. Connections over the WAN or open internet should flow through [mesh gateways](/consul/docs/connect/gateways/mesh-gateway)
whenever possible since they are not capable of decrypting traffic or connecting directly to services.
@ -58,7 +58,7 @@ Each terminating gateway needs:
Terminating gateways also require that your Consul datacenters are configured correctly:
- You'll need to use Consul version 1.8.0 or newer.
- Consul [Connect](/consul/docs/agent/config/config-files#connect) must be enabled on the datacenter's Consul servers.
- Consul [service mesh](/consul/docs/agent/config/config-files#connect) must be enabled on the datacenter's Consul servers.
- [gRPC](/consul/docs/agent/config/config-files#grpc_port) must be enabled on all client agents.
Currently, [Envoy](https://www.envoyproxy.io/) is the only proxy with terminating gateway capabilities in Consul.
@ -68,9 +68,9 @@ Currently, [Envoy](https://www.envoyproxy.io/) is the only proxy with terminatin
can only translate terminating gateway registration information into Envoy
configuration, therefore the proxies acting as terminating gateways must be Envoy.
Connect proxies that send upstream traffic through a gateway aren't
Service mesh proxies that send upstream traffic through a gateway aren't
affected when you deploy terminating gateways. If you are using non-Envoy proxies as
Connect proxies they will continue to work for traffic directed at services linked to
Service mesh proxies they will continue to work for traffic directed at services linked to
a terminating gateway as long as they discover upstreams with the
[/health/connect](/consul/api-docs/health#list-nodes-for-connect-capable-service) endpoint.
@ -84,7 +84,7 @@ services outside the mesh, review the [terminating gateway tutorial](/consul/tut
Terminating gateways are configured in service definitions and registered with Consul like other services, with two exceptions.
The first is that the [kind](/consul/api-docs/agent/service#kind) must be "terminating-gateway". Second,
the terminating gateway service definition may contain a `Proxy.Config` entry just like a
Connect proxy service, to define opaque configuration parameters useful for the actual proxy software.
service mesh proxy service, to define opaque configuration parameters useful for the actual proxy software.
For Envoy there are some supported [gateway options](/consul/docs/connect/proxies/envoy#gateway-options) as well as
[escape-hatch overrides](/consul/docs/connect/proxies/envoy#escape-hatch-overrides).

26
website/content/docs/connect/index.mdx
View File

@ -7,15 +7,20 @@ description: >-
# Consul service mesh
Consul Service Mesh provides service-to-service connection authorization and
encryption using mutual Transport Layer Security (TLS). Consul Connect is used interchangeably
with the name Consul Service Mesh and is what this document will use to refer to for Service Mesh functionality within Consul.
Applications can use [sidecar proxies](/consul/docs/connect/proxies) in a service mesh configuration to
establish TLS connections for inbound and outbound connections without being aware of Connect at all.
Applications may also [natively integrate with Connect](/consul/docs/connect/native) for optimal performance and security.
Connect can help you secure your services and provide data about service-to-service communications.
Consul service mesh provides service-to-service connection authorization and
encryption using mutual Transport Layer Security (TLS).
Review the video below to learn more about Consul Connect from HashiCorp's co-founder Armon.
Applications can use [sidecar proxies](/consul/docs/connect/proxies) in a service mesh configuration to
establish TLS connections for inbound and outbound connections without being aware of the service mesh at all.
Applications may also [natively integrate with Consul service mesh](/consul/docs/connect/native) for optimal performance and security.
Consul service mesh can help you secure your services and provide data about service-to-service communications.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
Where you encounter the _noun_ connect, it is usually functionality specific to
service mesh.
Review the video below to learn more about Consul service mesh from HashiCorp's co-founder Armon.
<iframe
src="https://www.youtube.com/embed/8T8t4-hQY74"
@ -59,11 +64,10 @@ Complete the following tutorials try Consul service mesh in different environmen
- The [Secure Service-to-Service Communication tutorial](/consul/tutorials/developer-mesh/service-mesh-with-envoy-proxy?utm_source=docs)
is a simple walk through of connecting two services on your local machine
using Consul Connect's built-in proxy and configuring your first intention. The guide also includes an introduction to
using Envoy as the Connect sidecar proxy.
and configuring your first intention.
- The [Kubernetes tutorial](/consul/tutorials/kubernetes/kubernetes-minikube?utm_source=docs)
walks you through configuring Consul Connect in Kubernetes using the Helm
walks you through configuring Consul service mesh in Kubernetes using the Helm
chart, and using intentions. You can run the guide on Minikube or an existing
Kubernetes cluster.

2
website/content/docs/connect/intentions/index.mdx
View File

@ -87,5 +87,5 @@ intentions should be consulted for each incoming connection/request to
determine if it should be accepted or rejected.
The default intention behavior is defined by the [`default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) configuration.
If the configuration is set `allow`, then all service mesh Connect connections will be allowed by default.
If the configuration is set `allow`, then all service-to-service connections in the mesh will be allowed by default.
If is set to `deny`, then all connections or requests will be denied by default.

13
website/content/docs/connect/intentions/legacy.mdx
View File

@ -10,8 +10,7 @@ description: >-
~> **1.8.x and earlier:** This document only applies in Consul versions 1.8.x
and before. If you are using version 1.9.0 or later, refer to the [current intentions documentation](/consul/docs/connect/intentions).
Intentions define access control for services via Connect and are used
to control which services may establish connections. Intentions can be
Intentions define access control for service-to-service connections in the service mesh. Intentions can be
managed via the API, CLI, or UI.
Intentions are enforced by the [proxy](/consul/docs/connect/proxies)
@ -23,8 +22,8 @@ connection must be terminated.
The default intention behavior is defined by the default [ACL
policy](/consul/docs/agent/config/config-files#acl_default_policy). If the default ACL policy is
"allow all", then all Connect connections are allowed by default. If the
default ACL policy is "deny all", then all Connect connections are denied by
"allow all", then all service-to-service connections in the mesh are allowed by default. If the
default ACL policy is "deny all", then all service-to-service connections are denied by
default.
## Intention Basics
@ -130,7 +129,7 @@ of the intention, not the source.
Intention permissions are by default implicitly granted at `read` level
when granting `service:read` or `service:write`. This is because a
service registered that wants to use Connect needs `intentions:read`
service registered that wants to use service mesh needs `intentions:read`
for its own service name in order to know whether or not to authorize
connections. The following ACL policy will implicitly grant `intentions:read`
(note _read_) for service `web`.
@ -152,7 +151,7 @@ service "web" {
}
```
Note that `intentions:read` is required for a token that a Connect-enabled
Note that `intentions:read` is required for a token that a mesh-enabled
service uses to register itself or its proxy. If the token used does not
have `intentions:read` then the agent will be unable to resolve intentions
for the service and so will not be able to authorize any incoming connections.
@ -173,7 +172,7 @@ The intentions for services registered with a Consul agent are cached
locally on that agent. They are then updated via a background blocking query
against the Consul servers.
Connect connection attempts require only local agent
Service mesh connection attempts require only local agent
communication for authorization and generally only impose microseconds
of latency to the connection. All actions in the data path of connections
require only local data to ensure minimal performance overhead.

10
website/content/docs/connect/l7-traffic/discovery-chain.mdx
View File

@ -10,7 +10,7 @@ description: >-
-> **1.6.0+:** This feature is available in Consul versions 1.6.0 and newer.
~> This topic is part of a [low-level API](/consul/api-docs/discovery-chain)
primarily targeted at developers building external [Connect proxy
primarily targeted at developers building external [Consul service mesh proxy
integrations](/consul/docs/connect/proxies/integrate).
The service discovery process can be modeled as a "discovery chain" which
@ -21,7 +21,7 @@ the discovery chain a user can control how proxy upstreams are ultimately
resolved to specific instances for load balancing.
-> **Note:** The discovery chain is currently only used to discover
[Connect](/consul/docs/connect) proxy upstreams.
[service mesh](/consul/docs/connect) proxy upstreams.
## Configuration
@ -69,7 +69,7 @@ various configuration entries interact in more complex ways. For example:
To correctly interpret a collection of configuration entries as a valid
discovery chain, we first compile them into a form more directly usable by the
layers responsible for configuring Connect sidecar proxies.
layers responsible for configuring service mesh sidecar proxies.
You can interact with the compiler directly using the [discovery-chain
API](/consul/api-docs/discovery-chain).
@ -100,7 +100,7 @@ The response is a single wrapped `CompiledDiscoveryChain` field:
The chain encodes a digraph of [nodes](#discoverygraphnode) and
[targets](#discoverytarget). Nodes are the compiled representation of various
discovery chain stages and targets are instructions on how to use the [health
API](/consul/api-docs/health#list-nodes-for-connect-capable-service) to retrieve
API](/consul/api-docs/health#list-nodes-for-mesh-capable-service) to retrieve
relevant service instance lists.
You should traverse the nodes starting with [`StartNode`](#startnode). The
@ -228,7 +228,7 @@ A single node in the compiled discovery chain.
be considered healthy.
- `MeshGateway` `(MeshGatewayConfig)` - The [mesh gateway
configuration](/consul/docs/connect/gateways/mesh-gateway#connect-proxy-configuration)
configuration](/consul/docs/connect/gateways/mesh-gateway#service-mesh-proxy-configuration)
to use when connecting to this target's service instances.
- `Mode` `(string: "")` - One of `none`, `local`, or `remote`.

4
website/content/docs/connect/l7-traffic/index.mdx
View File

@ -12,7 +12,7 @@ description: >-
Layer 7 traffic management allows operators to divide L7 traffic between
different
[subsets](/consul/docs/connect/config-entries/service-resolver#service-subsets) of
service instances when using Connect.
service instances when using service mesh.
There are many ways you may wish to carve up a single datacenter's pool of
services beyond simply returning all healthy instances for load balancing.
@ -28,7 +28,7 @@ and some [Envoy proxy escape hatches](/consul/docs/connect/proxies/envoy#escape-
## Stages
Connect proxy upstreams are discovered using a series of stages: routing,
Service mesh proxy upstreams are discovered using a series of stages: routing,
splitting, and resolution. These stages represent different ways of managing L7
traffic.

45
website/content/docs/connect/native/go.mdx
View File

@ -7,26 +7,29 @@ description: >-
# Service Mesh Native Integration for Go Applications
We provide a library that makes it drop-in simple to integrate Consul service mesh
with most [Go](https://golang.org/) applications. This page shows examples
of integrating this library for accepting or establishing mesh-based
connections. For most Go applications, Consul service mesh can be natively integrated
in just a single line of code excluding imports and struct initialization.
In addition to this, please read and understand the
[overview of service mesh native integrations](/consul/docs/connect/native).
In particular, after natively integrating applications with Consul service mesh,
they must declare that they accept mesh-based connections via their service definitions.
The noun _connect_ is used throughout this documentation and the Go API
to refer to the connect subsystem that provides Consul's service mesh capabilities.
## Accepting Connections
-> **Note:** When calling `ConnectAuthorize()` on incoming connections this library
will return _deny_ if `Permissions` are defined on the matching intention.
The method is currently only suited for networking layer 4 (e.g. TCP) integration.
We provide a library that makes it drop-in simple to integrate Connect
with most [Go](https://golang.org/) applications. This page shows examples
of integrating this library for accepting or establishing Connect-based
connections. For most Go applications, Connect can be natively integrated
in just a single line of code excluding imports and struct initialization.
In addition to this, please read and understand the
[overview of Connect-Native integrations](/consul/docs/connect/native).
In particular, after integrating applications with Connect, they must declare
that they accept Connect-based connections via their service definitions.
## Accepting Connections
Any server that supports TLS (HTTP, gRPC, net/rpc, etc.) can begin
accepting Connect-based connections in just a few lines of code. For most
existing applications, converting the server to accept Connect-based
accepting mesh-based connections in just a few lines of code. For most
existing applications, converting the server to accept mesh-based
connections will require only a one-line change excluding imports and
structure initialization.
@ -55,7 +58,7 @@ func main() {
svc, _ := connect.NewService("my-service", client)
defer svc.Close()
// Creating an HTTP server that serves via Connect
// Creating an HTTP server that serves via service mesh
server := &http.Server{
Addr: ":8080",
TLSConfig: svc.ServerTLSConfig(),
@ -106,7 +109,7 @@ func main() {
svc, _ := connect.NewService("my-service", client)
defer svc.Close()
// Creating an HTTP server that serves via Connect
// Creating an HTTP server that serves via service mesh
listener, _ := tls.Listen("tcp", ":8080", svc.ServerTLSConfig())
defer listener.Close()
@ -117,9 +120,9 @@ func main() {
## HTTP Clients
For Go applications that need to Connect to HTTP-based upstream dependencies,
For Go applications that need to connect to HTTP-based upstream dependencies,
the Go library can construct an `*http.Client` that automatically establishes
Connect-based connections as long as Consul-based service discovery is used.
mesh-based connections as long as Consul-based service discovery is used.
Example, followed by more details:
@ -152,7 +155,7 @@ section above. If your application is both a client and server, both the
API client and service structure can be shared and reused.
Next, we call `svc.HTTPClient()` to return a specially configured
`*http.Client`. This client will automatically established Connect-based
`*http.Client`. This client will automatically established mesh-based
connections using Consul service discovery.
Finally, we perform an HTTP `GET` request to a hypothetical userinfo service.
@ -189,7 +192,7 @@ the following specific limitations:
## Raw TLS Connection
For a raw `net.Conn` TLS connection, the `svc.Dial` function can be used.
This will establish a connection to the desired service via Connect and
This will establish a connection to the desired service via the service mesh and
return the `net.Conn`. This connection can then be used as desired.
Example:

39
website/content/docs/connect/native/index.mdx
View File

@ -2,18 +2,18 @@
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 “Connect-Native” apps use mTLS to authenticate with Consul and how to add integrations to service registrations.
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 Connect service
~> **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 the Connect API to support accepting
and establishing connections to other Connect services without the overhead of a
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
@ -21,20 +21,23 @@ 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.
Connect is just basic mutual TLS. This means that almost any application
can easily integrate with Connect. There is no custom protocol in use;
any language that supports TLS can accept and establish Connect-based
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 Connect.
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 Connect is
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).
@ -55,7 +58,7 @@ 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 Connect-capable endpoints for a service. After service
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
@ -64,7 +67,7 @@ Details on the steps are below:
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 Connect-based connection and there are no further steps!
a mesh-based connection and there are no further steps!
- **Authorization** - As a server accepting connections, verify the client
certificate against the [public CA
@ -102,8 +105,8 @@ 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 leaf TLS certificate](/consul/api-docs/agent/connect#service-leaf-certificate)
and [reading CA roots](/consul/api-docs/agent/connect#certificate-authority-ca-roots)
[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,
@ -121,7 +124,7 @@ 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 Connect-enabled services all blocking
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.
@ -131,9 +134,9 @@ and locally caching the certificates.
## Service registration
Connect-native applications must tell Consul that they support Connect
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 Connect-native applications
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:
@ -150,6 +153,6 @@ You can enable native service mesh support directly in the [service definition](
}
```
Services that support Connect natively are still returned through the standard
service discovery mechanisms in addition to the Connect-only service discovery
Services that support service mesh natively are still returned through the standard
service discovery mechanisms in addition to the mesh-only service discovery
mechanisms.

12
website/content/docs/connect/nomad.mdx
View File

@ -7,20 +7,20 @@ description: >-
# Consul and Nomad Integration
Consul Connect can be used with [Nomad](https://www.nomadproject.io/) to provide
Consul service mesh can be used with [Nomad](https://www.nomadproject.io/) to provide
secure service-to-service communication between Nomad jobs and task groups.
Nomad is a simple, flexible scheduler and workload orchestrator. The ability to
use the [dynamic port](/nomad/docs/job-specification/network#dynamic-ports)
feature of Nomad makes Connect reduces operational complexity.
feature of Nomad with Consul service mesh reduces operational complexity.
For more information
about using Consul Connect with Nomad, select one of the following resources.
about using Consul service mesh with Nomad, select one of the following resources.
For a step-by-step guide on using Consul Connect with Nomad:
For a step-by-step guide on using Consul service mesh with Nomad:
- [Nomad Consul Connect Guide](/nomad/docs/integrations/consul-connect)
- [Nomad with Consul service mesh Guide](/nomad/docs/integrations/consul-connect)
For reference information about configuring Nomad jobs to use Consul Connect:
For reference information about configuring Nomad jobs to use Consul service mesh:
- [Nomad Job Specification - `connect`](/nomad/docs/job-specification/connect)
- [Nomad Job Specification - `sidecar_service`](/nomad/docs/job-specification/sidecar_service)

4
website/content/docs/connect/observability/index.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Service Mesh Observability Overview
In order to take advantage of Connect's L7 observability features you will need
In order to take advantage of the service mesh's L7 observability features you will need
to:
- Deploy sidecar proxies that are capable of emitting metrics with each of your
@ -39,7 +39,7 @@ config {
}
```
Find other possible metrics syncs in the [Connect Envoy documentation](/consul/docs/connect/proxies/envoy#bootstrap-configuration).
Find other possible metrics syncs in the [Envoy documentation](/consul/docs/connect/proxies/envoy#bootstrap-configuration).
### Service protocol

5
website/content/docs/connect/observability/ui-visualization.mdx
View File

@ -14,8 +14,7 @@ show a service's immediate connectivity at a glance. It is not intended as a
replacement for dedicated monitoring solutions, but rather as a quick overview
of the state of a service and its connections within the Service Mesh.
The topology visualization requires services to be using [Consul
Connect](/consul/docs/connect) via [side-car proxies](/consul/docs/connect/proxies).
The topology visualization requires services to be using [service mesh](/consul/docs/connect) via [sidecar proxies](/consul/docs/connect/proxies).
The visualization may optionally be configured to include a link to an external
per-service dashboard. This is designed to provide convenient deep links to your
@ -718,7 +717,7 @@ Currently there are some limitations to this feature.
access likely only has metrics for the local datacenter and a full solution
would need additional proxying or exposing remote Prometheus servers on the
network in remote datacenters. Later we may support an easy way to set this up
via Consul Connect but initially we don't attempt to fetch metrics in the UI
via Consul service mesh but initially we don't attempt to fetch metrics in the UI
if you are browsing a remote datacenter.
- **Built-in provider requires metrics proxy** Initially the built-in

6
website/content/docs/connect/proxies/built-in.mdx
View File

@ -8,11 +8,11 @@ description: >-
# Built-in Proxy Configuration for Service Mesh
~> **Note:** The built-in proxy is not supported for production deployments. It does not
support many of the Connect service mesh features, and is not under active development.
support many of Consul's service mesh features, and is not under active development.
The [Envoy proxy](/consul/docs/connect/proxies/envoy) should be used for production deployments.
Consul comes with a built-in L4 proxy for testing and development with Consul
Connect service mesh.
service mesh.
## Proxy Config Key Reference
@ -61,7 +61,7 @@ All fields are optional with a reasonable default.
that the proxy should use to connect to the local application instance. By default
it assumes `127.0.0.1` as the address and takes the port from the service definition's
`port` field. Note that allowing the application to listen on any non-loopback
address may expose it externally and bypass Connect's access enforcement. It may
address may expose it externally and bypass the service mesh's access enforcement. It may
be useful though to allow non-standard loopback addresses or where an alternative
known-private IP is available for example when using internal networking between
containers.

28
website/content/docs/connect/proxies/envoy.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Envoy Proxy Configuration for Service Mesh
Consul Connect has first class support for using
Consul service mesh has first class support for using
[Envoy](https://www.envoyproxy.io) as a proxy. Consul configures Envoy by
optionally exposing a gRPC service on the local agent that serves [Envoy's xDS
configuration
@ -55,7 +55,7 @@ The Consul dataplane component was introduced in Consul v1.14 as a way to manage
## Getting Started
To get started with Envoy and see a working example you can follow the [Using
Envoy with Connect](/consul/tutorials/developer-mesh/service-mesh-with-envoy-proxy?utm_source=docs) tutorial.
Envoy with Consul service mesh](/consul/tutorials/developer-mesh/service-mesh-with-envoy-proxy?utm_source=docs) tutorial.
## Configuration
@ -68,7 +68,7 @@ identity (node id) and the location of its local Consul agent from which it
discovers all of its dynamic configuration. See [Bootstrap
Configuration](#bootstrap-configuration) for more details.
The dynamic configuration Consul Connect provides to each Envoy instance includes:
The dynamic configuration Consul service mesh provides to each Envoy instance includes:
- TLS certificates and keys to enable mutual authentication and keep certificates
rotating.
@ -79,11 +79,11 @@ The dynamic configuration Consul Connect provides to each Envoy instance include
- Configuration to [expose specific HTTP paths](/consul/docs/connect/registration/service-registration#expose-paths-configuration-reference).
For more information on the parts of the Envoy proxy runtime configuration
that are currently controllable via Consul Connect see [Dynamic
that are currently controllable via Consul service mesh, refer to [Dynamic
Configuration](#dynamic-configuration).
We plan to enable more and more of Envoy's features through
Connect's first-class configuration over time, however some advanced users will
Consul service mesh's first-class configuration over time, however some advanced users will
need additional control to configure Envoy in specific ways. To enable this, we
provide several ["escape hatch"](#advanced-configuration) options that allow
users to provide low-level raw Envoy config syntax for some sub-components in each
@ -287,11 +287,11 @@ the [global `proxy-defaults` configuration
entry](/consul/docs/connect/config-entries/proxy-defaults) to act as
defaults that are inherited by all services.
- `protocol` - The protocol the service speaks. Connect's Envoy integration
- `protocol` - The protocol the service speaks. Consul service mesh's Envoy integration
currently supports the following `protocol` values:
- `tcp` - Unless otherwise specified this is the default, which causes Envoy
to proxy at L4. This provides all the security benefits of Connect's mTLS
to proxy at L4. This provides all the security benefits of the service mesh's mTLS
and works for any TCP-based protocol. Load-balancing and metrics are
available at the connection level.
- `http` - This specifies that the service speaks HTTP/1.x. Envoy will setup an
@ -504,13 +504,13 @@ manually code the entire configuration in protobuf JSON.
~> **Advanced Topic!** This section covers options that allow users to take almost
complete control of Envoy's configuration. We provide these options so users can
experiment or take advantage of features not yet fully supported in Consul Connect. We
experiment or take advantage of features not yet fully supported in Consul service mesh. We
plan to retain this ability in the future, but it should still be considered
experimental because it requires in-depth knowledge of Envoy's configuration format.
Users should consider Envoy version compatibility when using these features because they can configure Envoy in ways that
are outside of Consul's control. Incorrect configuration could prevent all
proxies in your mesh from functioning correctly, or bypass the security
guarantees Connect is designed to enforce.
guarantees Consul service mesh is designed to enforce.
### Configuration Formatting
@ -648,7 +648,7 @@ definition](/consul/docs/connect/registration/service-registration) or
- `envoy_extra_static_listeners_json` - Similar to
`envoy_extra_static_clusters_json` but appends one or more [Envoy listeners](https://www.envoyproxy.io/docs/envoy/v1.17.2/api-v3/config/listener/v3/listener.proto) to the array of [static
listener](https://www.envoyproxy.io/docs/envoy/v1.17.2/api-v3/config/bootstrap/v3/bootstrap.proto#envoy-v3-api-field-config-bootstrap-v3-bootstrap-staticresources-listeners) definitions.
Can be used to setup limited access that bypasses Connect mTLS or
Can be used to setup limited access that bypasses the service mesh's mTLS or
authorization for health checks or metrics.
<CodeBlockConfig heading="Example envoy_extra_static_listeners_json">
@ -807,11 +807,11 @@ definition](/consul/docs/connect/registration/service-registration) or
- Every `FilterChain` added to the listener will have its `TlsContext`
overridden by the Connect TLS certificates and validation context. This
means there is no way to override Connect's mutual TLS for the public
means there is no way to override the service mesh's mutual TLS for the public
listener.
- Every `FilterChain` will have the `envoy.filters.{network|http}.rbac` filter
prepended to the filters array to ensure that all inbound connections are
authorized by Connect. Before Consul 1.9.0 `envoy.ext_authz` was inserted instead.
authorized by the service mesh. Before Consul 1.9.0 `envoy.ext_authz` was inserted instead.
<CodeTabs heading="Example envoy_public_listener_json" tabs={[ "HTTP", "TCP" ]}>
@ -999,8 +999,8 @@ warning.
following exceptions:
- Every `FilterChain` added to the listener will have its `TlsContext`
overridden by the Connect TLS certificates and validation context. This
means there is no way to override Connect's mutual TLS for the public
overridden by the service mesh TLS certificates and validation context. This
means there is no way to override the service mesh's mutual TLS for the public
listener.
<CodeTabs heading="Example upstream envoy_listener_json">

2
website/content/docs/connect/proxies/index.mdx
View File

@ -12,7 +12,7 @@ per-service proxy sidecar transparently handles inbound and outbound service
connections, automatically wrapping and verifying TLS connections. Consul
ships with a built-in L4 proxy and has first class support for Envoy. You
can plug other proxies into your environment as well. This section describes how to
configure Envoy or the built-in proxy using Connect, and how to integrate the
configure Envoy or the built-in proxy using Consul service mesh, and how to integrate the
proxy of your choice.
To ensure that services only allow external connections established through

15
website/content/docs/connect/proxies/integrate.mdx
View File

@ -11,17 +11,20 @@ This topic describes the process and API endpoints you can use to extend proxies
## Overview
You can extend any proxy to support Connect. Consul ships with a built-in
You can extend any proxy to support Consul service mesh. Consul ships with a built-in
proxy suitable for an out-of-the-box development experience, but you may require a more robust proxy solution for production environments.
The proxy you integrate must be able to accept inbound connections and/or establish outbound connections identified as a particular service. In some cases, either ability may be acceptable, but both are generally required to support for full sidecar functionality.
Sidecar proxies may support L4 or L7 network functionality. L4 integration is simpler and adequate for securing all traffic. L4 treats all traffic as TCP, however, so advanced routing or metrics features are not supported.
Full L7 support is built on top of L4 support. An L7 proxy integration supports most or all of the L7 traffic routing features in Connect by dynamically configuring routing, retries, and other L7 features. The built-in proxy only supports L4, while [Envoy](/consul/docs/connect/proxies/envoy) supports the full L7 feature set.
Full L7 support is built on top of L4 support. An L7 proxy integration supports most or all of the L7 traffic routing features in Consul service mesh by dynamically configuring routing, retries, and other L7 features. The built-in proxy only supports L4, while [Envoy](/consul/docs/connect/proxies/envoy) supports the full L7 feature set.
Areas where the integration approach differs between L4 and L7 are identified in this topic.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
## Accepting Inbound Connections
The proxy must accept TLS connections on some port to accept inbound connections.
@ -38,7 +41,7 @@ $ curl http://<host-ip>:8500/v1/agent/connect/ca/leaf/<service-name>
</CodeBlockConfig>
The client certificate from the inbound connection must be validated against the Connect CA root certificates. Call the [`/v1/agent/connect/ca/roots`] endpoint to obtain the root certificates from the Connect CA, e.g.:
The client certificate from the inbound connection must be validated against the service mesh CA root certificates. Call the [`/v1/agent/connect/ca/roots`] endpoint to obtain the root certificates from the service mesh CA, e.g.:
<CodeBlockConfig language="shell-session">
@ -103,7 +106,7 @@ leaf certificate.
## Establishing Outbound Connections
For outbound connections, the proxy should communicate with a Connect-capable
For outbound connections, the proxy should communicate with a mesh-capable
endpoint for a service and provide a client certificate from the
[`/v1/agent/connect/ca/leaf/`] API endpoint. The proxy must use the root certificate obtained from the [`/v1/agent/connect/ca/roots`] endpoint to verify the certificate served from the destination endpoint.
@ -126,7 +129,7 @@ fetching the discovery chain so that L7 features, such as HTTP routing rules, ar
not returned.
For each [target](/consul/docs/connect/l7-traffic/discovery-chain#targets) in the resulting
discovery chain, a list of healthy, Connect-capable endpoints may be fetched
discovery chain, a list of healthy, mesh-capable endpoints may be fetched
from the [`/v1/health/connect/:service_id`] API endpoint as described in the [Service
Discovery](#service-discovery) section.
@ -138,7 +141,7 @@ documentation for details about supported configuration parameters.
### Service Discovery
Proxies can use Consul's [service discovery API](/consul/api-docs/health#list-service-instances-for-connect-enabled-service) to return all available, Connect-capable endpoints for a given service. This endpoint supports a `cached` query parameter, which uses [agent caching](/consul/api-docs/features/caching) to improve
Proxies can use Consul's [service discovery API](/consul/api-docs/health#list-service-instances-for-mesh-enabled-service) to return all available, mesh-capable endpoints for a given service. This endpoint supports a `cached` query parameter, which uses [agent caching](/consul/api-docs/features/caching) to improve
performance. The API package provides a [`UseCache`] query option to leverage caching.
In addition to performance improvements, using the cache makes the mesh more resilient to Consul server outages. This is because the mesh "fails static" with the last known set of service instances still used, rather than errors on new connections.

6
website/content/docs/connect/registration/service-registration.mdx
View File

@ -7,7 +7,7 @@ description: >-
# Register a Service Mesh Proxy Outside of a Service Registration
This topic describes how to declare a proxy as a `connect-proxy` in service definitions. The `kind` must be declared and information about the service they represent must be provided to function as a Consul service mesh proxy.
This topic describes how to declare a service mesh proxy in a service definition. The `kind` must be declared and information about the service they represent must be provided to function as a Consul service mesh proxy.
## Configuration
@ -53,7 +53,7 @@ You can specify several additional parameters to configure the proxy to meet you
### Example
In the following example, a proxy named `redis-proxy` is registered as a service mesh proxy. It proxies to the `redis` service and is available at port `8181`. As a result, any service mesh clients searching for a Connect-capable endpoint for `redis` will find this proxy.
In the following example, a proxy named `redis-proxy` is registered as a service mesh proxy. It proxies to the `redis` service and is available at port `8181`. As a result, any service mesh clients searching for a mesh-capable endpoint for `redis` will find this proxy.
<CodeTabs heading="Minimal example of a service mesh proxy">
@ -378,7 +378,7 @@ The following examples show all possible mesh gateway configurations.
The following examples show possible configurations to expose HTTP paths through Envoy.
Exposing paths through Envoy enables a service to protect itself by only listening on localhost, while still allowing
non-Connect-enabled applications to contact an HTTP endpoint.
non-mesh-enabled applications to contact an HTTP endpoint.
Some examples include: exposing a `/metrics` path for Prometheus or `/healthz` for kubelet liveness checks.
Note that the examples in this topic use snake case, which is a convention that separates words with underscores, because the format is supported in configuration files and API registrations.

2
website/content/docs/connect/registration/sidecar-service.mdx
View File

@ -149,7 +149,7 @@ The following fields are not supported in the `connect.sidecar_service` block:
service.
- `connect.sidecar_service` - Service definitions can't be nested recursively.
- `connect.native` - Currently the `kind` is fixed to `connect-proxy` and it's
an error to register a `connect-proxy` that is also Connect-native.
an error to register a `connect-proxy` that is also service mesh-native.
## Lifecycle

20
website/content/docs/connect/security.mdx
View File

@ -7,15 +7,15 @@ description: >-
# Best Practices for Service Mesh Security
Connect enables secure service-to-service communication over mutual TLS. This
Consul service mesh enables secure service-to-service communication over mutual TLS. This
provides both in-transit data encryption as well as authorization. This page
will document how to secure Connect. To try Connect locally, complete the
will document how to secure the service mesh. To try service mesh locally, complete the
[Getting Started guide](/consul/tutorials/kubernetes-deploy/service-mesh?utm_source=docs) or for a full security model reference,
see the dedicated [Consul security model](/consul/docs/security) page. When
setting up Connect in production, review this [tutorial](/consul/tutorials/developer-mesh/service-mesh-production-checklist?utm_source=consul.io&utm_medium=docs).
setting up service mesh in production, review this [tutorial](/consul/tutorials/developer-mesh/service-mesh-production-checklist?utm_source=consul.io&utm_medium=docs).
Connect will function in any Consul configuration. However, unless the checklist
below is satisfied, Connect is not providing the security guarantees it was
Consul service mesh will function in any Consul configuration. However, unless the checklist
below is satisfied, the service mesh is not providing the security guarantees it was
built for. The checklist below can be incrementally adopted towards full
security if you prefer to operate in less secure models initially.
@ -49,7 +49,7 @@ TCP and UDP encryption must be enabled to prevent plaintext communication
between Consul agents. At a minimum, `verify_outgoing` should be enabled
to verify server authenticity with each server having a unique TLS certificate.
`verify_incoming` provides additional agent verification, but doesn't directly
affect Connect since requests must also always contain a valid ACL token.
affect service mesh since requests must also always contain a valid ACL token.
Clients calling Consul APIs should be forced over encrypted connections.
See the [Consul agent encryption page](/consul/docs/security/encryption) to
@ -72,7 +72,7 @@ general, the blast radius of unauthorized access for client agent directories
is much smaller than servers. However, both must be protected against
unauthorized access.
### Prevent Non-Connect Traffic to Services
### Prevent Non-Mesh Traffic to Services
For services that are using
[proxies](/consul/docs/connect/proxies)
@ -85,16 +85,16 @@ network namespacing techniques provided by the underlying operating system.
For scenarios where multiple services are running on the same machine
without isolation, these services must all be trusted. We call this the
**trusted multi-tenancy** deployment model. Any service could theoretically
connect to any other service via the loopback listener, bypassing Connect
connect to any other service via the loopback listener, bypassing the service mesh
completely. In this scenario, all services must be trusted _or_ isolation
mechanisms must be used.
For developer or operator access to a service, we recommend
using a local Connect proxy. This is documented in the
using a local service mesh proxy. This is documented in the
[development and debugging guide](/consul/docs/connect/dev).
**If non-proxy traffic can communicate with the service**, this traffic
will not be encrypted or authorized via Connect.
will not be encrypted or authorized via service mesh.
### Restrict Access to Envoy's Administration Interface

2
website/content/docs/connect/transparent-proxy.mdx
View File

@ -276,7 +276,7 @@ spec:
Additional services can query the [KubeDNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/) at `sample-app.default.svc.cluster.local` to reach `sample-app`. If ACLs are enabled and configured with default `deny` policies, the configuration also requires a [`ServiceIntention`](/consul/docs/connect/config-entries/service-intentions) to allow it to talk to `sample-app`.
### Headless Services
For services that are not addressed using a virtual cluster IP, you must configure the upstream service using the [DialedDirectly](/consul/docs/connect/config-entries/service-defaults#dialeddirectly) option. Then, use DNS to discover individual instance addresses and dial them through the transparent proxy. When this mode is enabled on the upstream, services present connect certificates for mTLS and intentions are enforced at the destination.
For services that are not addressed using a virtual cluster IP, you must configure the upstream service using the [DialedDirectly](/consul/docs/connect/config-entries/service-defaults#dialeddirectly) option. Then, use DNS to discover individual instance addresses and dial them through the transparent proxy. When this mode is enabled on the upstream, services present service mesh certificates for mTLS and intentions are enforced at the destination.
Note that when dialing individual instances, Consul ignores the HTTP routing rules configured with configuration entries. The transparent proxy acts as a TCP proxy to the original destination IP address.

2
website/content/docs/ecs/index.mdx
View File

@ -22,7 +22,7 @@ traffic policy, and more. You can also connect service meshes so that services d
Consul on ECS follows an [architecture](/consul/docs/architecture) similar to other platforms, but each ECS task is a
Consul node. An ECS task runs the user application container(s), as well as a Consul client container for control plane
communication and an [Envoy](https://envoyproxy.io/) sidecar proxy container to facilitate data plane communication for
[Consul Connect](/consul/docs/connect).
[Consul service mesh](/consul/docs/connect).
For a detailed architecture overview, see the [Architecture](/consul/docs/ecs/architecture) page.

2
website/content/docs/ecs/manual/install.mdx
View File

@ -127,7 +127,7 @@ See the [ECS Task Definition](https://docs.aws.amazon.com/AmazonECS/latest/devel
## `sidecar-proxy` container
The `sidecar-proxy` container runs [Envoy proxy](/consul/docs/connect/proxies/envoy) for Consul Connect. In most cases, the container should contain the following parameters and values.
The `sidecar-proxy` container runs [Envoy proxy](/consul/docs/connect/proxies/envoy) for Consul service mesh. In most cases, the container should contain the following parameters and values.
The `mountPoints` list must be set as shown in the following example. This will mount the shared `consul_data` volume into the
`sidecar-proxy` container at the path `/consul`. This volume is where the `consul-ecs-mesh-init` container copies the `envoy-bootstrap.json`

2
website/content/docs/guides/index.mdx
View File

@ -33,6 +33,6 @@ Tracks include:
- Day 1: Kubernetes Production Deployment
- Maintenance and Monitoring Operations
- Service Discovery and Consul DNS
- Service Segmentation and Consul Connect
- Service Segmentation and Consul Service Mesh
- Service Configuration and Consul KV
- Cloud and Load Balancer Integrations

8
website/content/docs/install/performance.mdx
View File

@ -172,9 +172,9 @@ To prevent any CPU spikes from a misconfigured client, RPC requests to the serve
In addition, two [performance indicators](/consul/docs/agent/telemetry) &mdash; `consul.runtime.alloc_bytes` and `consul.runtime.heap_objects` &mdash; can help diagnose if the current sizing is not adequately meeting the load.
## Connect Certificate Signing CPU Limits
## Service Mesh Certificate Signing CPU Limits
If you enable [Connect](/consul/docs/connect), the leader server will need
If you enable [service mesh](/consul/docs/connect), the leader server will need
to perform public key signing operations for every service instance in the
cluster. Typically these operations are fast on modern hardware, however when
the CA is changed or its key rotated, the leader will face an influx of
@ -194,11 +194,11 @@ operations could impact the server's normal work. To limit that, Consul since
By default we set a limit of 50 per second which is reasonable on modest
hardware but may be too low and impact rotation times if more than 1500 service
instances are using Connect in the cluster. `csr_max_per_second` is likely best
instances are using service mesh in the cluster. `csr_max_per_second` is likely best
if you have fewer than four cores available since a whole core being used by
signing is likely to impact the server stability if it's all or a large portion
of the cores available. The downside is that you need to capacity plan: how many
service instances will need Connect certificates? What CSR rate can your server
service instances will need service mesh certificates? What CSR rate can your server
tolerate without impacting stability? How fast do you want CA rotations to
process?

2
website/content/docs/integrate/download-tools.mdx
View File

@ -47,7 +47,7 @@ These Consul tools are created and managed by the amazing members of the Consul
- [fabio](https://github.com/eBay/fabio) - Fast, zero-conf, consul-aware load-balancing HTTP/HTTPS router
- [files-to-consul-kv](https://github.com/bitsofinfo/files-to-consul-kv) - Ultra simple, configuration free CLI tool for syncing a directory structure of key-value files to Consul KV using the transactions API. Docker image available. Integrates easily into any CI/CD workflow.
- [file2consul](https://github.com/joeatbayes/file2consul) - Update Consul values from git or files. Config loader with support for multiple environments. Provides variable expansion, interpolation, inheritance with overrides and ability to update multiple consul servers. Reduces cost of maintaining larger configuration sets between environments by reducing restatement and manual editing of similar or predictably changing config properties. MIT license, Written in GO.
- [Flightpath](https://docs.flightpath.xyz/) - An xDS server that can configure Envoy to act as an Edge proxy for Consul Connect enabled services
- [Flightpath](https://docs.flightpath.xyz/) - An xDS server that can configure Envoy to act as an Edge proxy for Consul service mesh enabled services
- [git2consul](https://github.com/ryanbreen/git2consul) - Mirror the contents of a Git repository into Consul KVs
- [gobetween](https://github.com/yyyar/gobetween) - Modern & minimalistic load balancer and reverse-proxy for the ☁️ Cloud era.
- [Gonsul](https://github.com/miniclip/gonsul) - A Git to Consul standalone tool made in Go. Updates Consul KV from a repo with multiple strategies.

2
website/content/docs/integrate/partnerships.mdx
View File

@ -27,7 +27,7 @@ By leveraging Consul's RESTful HTTP API system, prospective partners are able to
</ImageConfig>
**Data Plane**: These integrations extend Consul's certificate management, secure ACL configuration, observability metrics and logging, and service discovery that allows for dynamic service mapping APM and logging tools, extend sidecar proxies to support Consul connect, and extend API gateways to allow Consul to route incoming traffic to the proxies for Connect-enabled services.
**Data Plane**: These integrations extend Consul's certificate management, secure ACL configuration, observability metrics and logging, and service discovery that allows for dynamic service mapping APM and logging tools, extend sidecar proxies to support Consul service mesh, and extend API gateways to allow Consul to route incoming traffic to the proxies for mesh-enabled services.
**Control Plane**: Consul has a client-server architecture and is the control plane for the service mesh.

11
website/content/docs/k8s/annotations-and-labels.mdx
View File

@ -2,7 +2,7 @@
layout: docs
page_title: Annotations and Labels
description: >-
Annotations and labels configure Consul sidecar properties and injection behavior when scheduling Kubernetes clusters. Learn about the annotations and labels that enable Consul’s service mesh and secure upstream communication on k8s in this reference guide.
Annotations and labels configure service mesh sidecar properties and injection behavior when scheduling Kubernetes clusters. Learn about the annotations and labels that enable Consul’s service mesh and secure upstream communication on k8s in this reference guide.
---
# Annotations and Labels
@ -15,6 +15,9 @@ This allows the user to configure natively configure Consul on select Kubernetes
- [Annotations](#annotations)
- [Labels](#labels)
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
## Annotations
The following Kubernetes resource annotations could be used on a pod to control connect-inject behavior:
@ -69,7 +72,7 @@ The following Kubernetes resource annotations could be used on a pod to control
public listener will listen on a dynamic port.
- `consul.hashicorp.com/connect-service-upstreams` - The list of upstream
services that this pod needs to connect to via Connect along with a static
services that this pod needs to connect to via the service mesh along with a static
local port to listen for those connections. When transparent proxy is enabled,
this annotation is optional. There are a few formats this annotation can take:
@ -236,8 +239,8 @@ The following Kubernetes resource annotations could be used on a pod to control
- `consul.hashicorp.com/prometheus-key-file` - Local filesystem path to a private key file for Envoy to use
when serving TLS on the Prometheus metrics endpoint. Only applicable when `envoy_prometheus_bind_addr`
is set in proxy config.
- `consul.hashicorp.com/service-metrics-port` - Set the port where the Connect service exposes metrics.
- `consul.hashicorp.com/service-metrics-path` - Set the path where the Connect service exposes metrics.
- `consul.hashicorp.com/service-metrics-port` - Set the port where the mesh service exposes metrics.
- `consul.hashicorp.com/service-metrics-path` - Set the path where the mesh service exposes metrics.
- `consul.hashicorp.com/connect-inject-mount-volume` - Comma separated list of container names to mount the connect-inject volume into. The volume will be mounted at `/consul/connect-inject`. The connect-inject volume contains Consul internals data needed by the other sidecar containers, for example the `consul` binary, and the Pod's Consul ACL token. This data can be valuable for advanced use-cases, such as making requests to the Consul API from within application containers.
- `consul.hashicorp.com/consul-sidecar-user-volume` - JSON objects as specified by the [Volume pod spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.24/#volume-v1-core), that define volumes to add to the Envoy sidecar.
```yaml

20
website/content/docs/k8s/connect/connect-ca-provider.mdx
View File

@ -1,13 +1,13 @@
---
layout: docs
page_title: Configure Certificate Authority (CA) for Consul on Kubernetes
page_title: Configure Service Mesh Certificate Authority (CA) for Consul on Kubernetes
description: >-
Consul includes a built-in CA, but when bootstrapping a cluster on k8s, you can configure your service mesh to use a custom certificate provider instead. Learn how to configure Vault as an external CA in primary and secondary datacenters and manually rotate Vault tokens.
---
# Configure Certificate Authority for Consul on Kubernetes
# Configure Service Mesh Certificate Authority for Consul on Kubernetes
If `connect` is enabled, the built-in Consul certificate authority (CA) is automatically enabled for the service mesh CA. You can use different CA providers with Consul service mesh. Refer to [Connect Certificate Management](/consul/docs/connect/ca) for supported providers.
If `connect` is enabled, the built-in Consul CA provider is automatically enabled for the service mesh certificate authority (CA). You can use different CA providers with Consul service mesh. Refer to [Service Mesh Certificate Management](/consul/docs/connect/ca) for supported providers.
## Overview
@ -21,20 +21,20 @@ To configure an external CA provider using the Consul Helm chart, complete the f
To configure the Vault service mesh provider, refer to [Vault as the Service Mesh Certificate Provider on Kubernetes](/consul/docs/k8s/deployment-configurations/vault/data-integration/connect-ca).
## Configuring Vault as a Connect CA (Consul K8s 0.37.0 and earlier)
## Configuring Vault as a Service Mesh CA (Consul K8s 0.37.0 and earlier)
If you use Vault 1.11.0+ as Consul's Connect CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
If you use Vault 1.11.0+ as Consul's service mesh CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
The following instructions are only valid for Consul K8s CLI 0.37.0 and prior. It describes how to configure Vault as the Connect CA. You can configure other providers during initial bootstrap of the cluster by providing the appropriate [`ca_config`] and [`ca_provider`] values for your provider.
The following instructions are only valid for Consul K8s CLI 0.37.0 and prior. It describes how to configure Vault as the service mesh CA. You can configure other providers during initial bootstrap of the cluster by providing the appropriate [`ca_config`] and [`ca_provider`] values for your provider.
-> **Auto-renewal:** If using Vault as your Connect CA, we strongly recommend Consul 1.8.5 or later, which includes support for token auto-renewal. If the Vault token is [renewable](/vault/api-docs/auth/token#renewable), then Consul automatically renews the token periodically. Otherwise, you must [manually rotate](#manually-rotating-vault-tokens) the Vault token before it expires.
-> **Auto-renewal:** If using Vault as your service mesh CA, we strongly recommend Consul 1.8.5 or later, which includes support for token auto-renewal. If the Vault token is [renewable](/vault/api-docs/auth/token#renewable), then Consul automatically renews the token periodically. Otherwise, you must [manually rotate](#manually-rotating-vault-tokens) the Vault token before it expires.
### Primary Datacenter
To configure Vault as a CA provider for Consul Connect,
To configure Vault as a CA provider for Consul service mesh,
first, create a provider configuration JSON file.
Please refer to [Vault as a Connect CA](/consul/docs/connect/ca/vault) for the configuration options.
Please refer to [Vault as a service mesh CA](/consul/docs/connect/ca/vault) for the configuration options.
You will need to provide a Vault token to the `token` property.
Please refer to [these docs](/consul/docs/connect/ca/vault#token) for the permissions that the token needs to have.
This token should be [renewable](/vault/api-docs/auth/token#renewable).
@ -142,7 +142,7 @@ $ kubectl exec consul-server-0 -- curl --silent http://localhost:8500/v1/connect
### Secondary Datacenters
To configure Vault as the Connect CA in secondary datacenters, you need to make sure that the Root CA is the same,
To configure Vault as the service mesh CA in secondary datacenters, you need to make sure that the Root CA is the same,
but the intermediate is different for each datacenter. In the `connect` configuration for a secondary datacenter,
you can specify a `intermediate_pki_path` that is, for example, prefixed with the datacenter
for which this configuration is intended.

33
website/content/docs/k8s/connect/index.mdx
View File

@ -7,10 +7,15 @@ description: >-
# How does Consul Service Mesh Work on Kubernetes?
[Consul Service Mesh](/consul/docs/connect) is a feature built into to Consul that enables
[Consul service mesh](/consul/docs/connect) is a feature built into to Consul that enables
automatic service-to-service authorization and connection encryption across
your Consul services. Consul Service Mesh can be used with Kubernetes to secure pod
communication with other pods and external Kubernetes services. _Consul Connect_ refers to the component in Consul that enables service mesh functionality. We sometimes use Connect to mean Consul service mesh throughout the documentation.
communication with other pods and external Kubernetes services.
The noun _connect_ is used throughout this documentation to refer to the connect
subsystem that provides Consul's service mesh capabilities.
Where you encounter the _noun_ connect, it is usually functionality specific to
service mesh.
Consul can automatically inject the sidecar running Envoy into pods in
your cluster, making configuration for Kubernetes automatic.
@ -76,7 +81,7 @@ spec:
serviceAccountName: static-server
```
The only change for Connect is the addition of the
The only change for service mesh is the addition of the
`consul.hashicorp.com/connect-inject` annotation. This enables injection
for the Pod in this Deployment. The injector can also be
[configured](/consul/docs/k8s/connect#installation-and-configuration)
@ -89,12 +94,12 @@ the _pod specification template_ as shown above.
This will start a sidecar proxy that listens on port `20000` registered
with Consul and proxies valid inbound connections to port 8080 in the pod.
To establish a connection to the pod using Connect, a client must use another Connect
proxy. The client Connect proxy will use Consul service discovery to find
To establish a connection to the pod using service mesh, a client must use another mesh
proxy. The client mesh proxy will use Consul service discovery to find
all available upstream proxies and their public ports.
In the example above, the server is listening on `:8080`.
By default, the Consul Service Mesh runs in [transparent proxy](/consul/docs/connect/transparent-proxy) mode.
By default, the Consul service mesh runs in [transparent proxy](/consul/docs/connect/transparent-proxy) mode.
This means that even though the server binds to all interfaces,
the inbound and outbound connections will automatically go through to the sidecar proxy.
It also allows you to use Kubernetes DNS like you normally would without the
@ -108,12 +113,12 @@ The service name registered in Consul will be set to the name of the Kubernetes
associated with the Pod. This can be customized with the `consul.hashicorp.com/connect-service`
annotation. If using ACLs, this name must be the same as the Pod's `ServiceAccount` name.
### Connecting to Connect-Enabled Services
### Connecting to Mesh-Enabled Services
The example Deployment specification below configures a Deployment that is capable
of establishing connections to our previous example "static-server" service. The
connection to this static text service happens over an authorized and encrypted
connection via Connect.
connection via service mesh.
-> **Note:** As of consul-k8s `v0.26.0` and Consul Helm `v0.32.0`, having a Kubernetes
Service is **required** to run services on the Consul Service Mesh.
@ -173,7 +178,7 @@ the injector will also set environment variables `<NAME>_CONNECT_SERVICE_HOST`
and `<NAME>_CONNECT_SERVICE_PORT` in every container in the Pod for every defined
upstream. This is analogous to the standard Kubernetes service environment variables, but
point instead to the correct local proxy port to establish connections via
Connect.
service mesh.
You can verify access to the static text server using `kubectl exec`.
Because transparent proxy is enabled by default,
@ -327,7 +332,7 @@ spec:
```
After deploying the `web` application, you can test service mesh connections by deploying the `static-client`
application with the configuration in the [previous section](#connecting-to-connect-enabled-services) and add the
application with the configuration in the [previous section](#connecting-to-mesh-enabled-services) and add the
following annotation to the pod template on `static-client`:
```yaml
consul.hashicorp.com/connect-service-upstreams: "web:1234,web-admin:2234"
@ -366,15 +371,15 @@ the Pod. So the upstream configuration can use the individual service names to r
## Installation and Configuration
The Connect sidecar proxy is injected via a
The service mesh sidecar proxy is injected via a
[mutating admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
provided by the
call the connect injector provided by the
[consul-k8s project](https://github.com/hashicorp/consul-k8s).
This enables the automatic pod mutation shown in the usage section above.
Installation of the mutating admission webhook is automated using the
[Helm chart](/consul/docs/k8s/installation/install).
To install the Connect injector, enable the Connect injection feature using
To install the connect injector, enable the connect injection feature using
[Helm values](/consul/docs/k8s/helm#configuration-values) and
upgrade the installation using `helm upgrade` for existing installs or
`helm install` for a fresh install.
@ -395,7 +400,7 @@ To verify the installation, run the
["Accepting Inbound Connections"](/consul/docs/k8s/connect#accepting-inbound-connections)
example from the "Usage" section above. After running this example, run
`kubectl get pod static-server --output yaml`. In the raw YAML output, you should
see injected Connect containers and an annotation
see connect injected containers and an annotation
`consul.hashicorp.com/connect-inject-status` set to `injected`. This
confirms that injection is working properly.

2
website/content/docs/k8s/connect/ingress-gateways.mdx
View File

@ -11,7 +11,7 @@ description: >-
~> This topic requires familiarity with [Ingress Gateways](/consul/docs/connect/gateways/ingress-gateway).
This page describes how to enable external access to Connect Service Mesh services running inside Kubernetes using Consul ingress gateways.
This page describes how to enable external access through Consul ingress gateways to mesh services running inside Kubernetes.
See [Ingress Gateways](/consul/docs/connect/gateways/ingress-gateway) for more information on use-cases and how it works.
Adding an ingress gateway is a multi-step process that consists of the following steps:

8
website/content/docs/k8s/connect/observability/metrics.mdx
View File

@ -10,14 +10,14 @@ description: >-
Consul on Kubernetes integrates with Prometheus and Grafana to provide metrics for Consul service mesh. The metrics
available are:
- Connect service metrics
- Sidecar proxy metrics
- Mesh service metrics
- Mesh sidecar proxy metrics
- Consul agent metrics
- Ingress, terminating, and mesh gateway metrics
Specific sidecar proxy metrics can also be seen in the Consul UI Topology Visualization view. This section documents how to enable each of these.
## Connect Service and Sidecar Metrics with Metrics Merging
## Mesh Service and Sidecar Metrics with Metrics Merging
Prometheus annotations are used to instruct Prometheus to scrape metrics from Pods. Prometheus annotations only support
scraping from one endpoint on a Pod, so Consul on Kubernetes supports metrics merging whereby service metrics and
@ -30,7 +30,7 @@ The diagram below illustrates how the metrics integration works when merging is
[![Metrics Merging Architecture](/img/metrics-arch.png)](/img/metrics-arch.png)
-->
Connect service metrics can be configured with the Helm values nested under [`connectInject.metrics`](/consul/docs/k8s/helm#v-connectinject-metrics).
Metrics for services in the mesh can be configured with the Helm values nested under [`connectInject.metrics`](/consul/docs/k8s/helm#v-connectinject-metrics).
Metrics and metrics merging can be enabled by default for all connect-injected Pods with the following Helm values:

4
website/content/docs/k8s/crds/upgrade-to-crds.mdx
View File

@ -14,7 +14,7 @@ you utilize the following:
- [`connectInject.centralConfig.defaultProtocol`](#default-protocol)
- [`connectInject.centralConfig.proxyDefaults`](#proxy-defaults)
- [`meshGateway.globalMode`](#mesh-gateway-mode)
- [Connect annotation `consul.hashicorp.com/connect-service-protocol`](#connect-service-protocol-annotation)
- [connect annotation `consul.hashicorp.com/connect-service-protocol`](#connect-service-protocol-annotation)
## Central Config Enabled
@ -133,7 +133,7 @@ installation.
## connect-service-protocol Annotation
If any of your Connect services had the `consul.hashicorp.com/connect-service-protocol`
If any of your mesh services had the `consul.hashicorp.com/connect-service-protocol`
annotation set, e.g.
```yaml

2
website/content/docs/k8s/deployment-configurations/multi-cluster/kubernetes.mdx
View File

@ -22,7 +22,7 @@ Consul treats each Kubernetes cluster as a separate Consul datacenter.
In order to federate clusters, one cluster must be designated the
primary datacenter. This datacenter will be
responsible for creating the certificate authority that signs the TLS certificates
Connect uses to encrypt and authorize traffic. It also handles validating global ACL tokens. All other clusters
that Consul service mesh uses to encrypt and authorize traffic. It also handles validating global ACL tokens. All other clusters
that are federated are considered secondaries.
#### First Time Installation

2
website/content/docs/k8s/deployment-configurations/servers-outside-kubernetes.mdx
View File

@ -109,7 +109,7 @@ The bootstrap token requires the following minimal permissions:
- `agent:read` if using WAN federation over mesh gateways
Next, configure external servers. The Helm chart will use this configuration to talk to the Consul server's API
to create policies, tokens, and an auth method. If you are [enabling Consul Connect](/consul/docs/k8s/connect),
to create policies, tokens, and an auth method. If you are [enabling Consul service mesh](/consul/docs/k8s/connect),
`k8sAuthMethodHost` should be set to the address of your Kubernetes API server
so that the Consul servers can validate a Kubernetes service account token when using the [Kubernetes auth method](/consul/docs/security/acl/auth-methods/kubernetes)
with `consul login`.

12
website/content/docs/k8s/deployment-configurations/vault/data-integration/connect-ca.mdx
View File

@ -10,10 +10,10 @@ description: >-
This topic describes how to configure the Consul Helm chart to use TLS certificates issued by Vault for Consul service mesh communication.
-> **Note:** This feature requires Consul 1.11 or higher. As of v1.11,
Consul allows using Kubernetes auth methods to configure Connect CA.
Consul allows using Kubernetes auth methods to configure the service mesh CA.
This allows for automatic token rotation once the renewal is no longer possible.
~> **Compatibility note:** If you use Vault 1.11.0+ as Consul's Connect CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
~> **Compatibility note:** If you use Vault 1.11.0+ as Consul's service mesh CA, versions of Consul released before Dec 13, 2022 will develop an issue with Consul control plane or service mesh communication ([GH-15525](https://github.com/hashicorp/consul/pull/15525)). Use or upgrade to a [Consul version that includes the fix](https://support.hashicorp.com/hc/en-us/articles/11308460105491#01GMC24E6PPGXMRX8DMT4HZYTW) to avoid this problem.
## Overview
@ -46,7 +46,7 @@ Next, you will create Kubernetes auth roles for the Consul servers:
$ vault write auth/kubernetes/role/consul-server \
bound_service_account_names=<Consul server service account> \
bound_service_account_namespaces=<Consul installation namespace> \
policies=<Connect CA policy> \
policies=<service mesh CA policy> \
ttl=1h
```
@ -58,7 +58,7 @@ $ helm template --release-name ${RELEASE_NAME} --show-only templates/server-serv
```
## Update Consul on Kubernetes Helm chart
Now you can configure the Consul Helm chart to use Vault as the Connect CA provider:
Now you can configure the Consul Helm chart to use Vault as the service mesh (connect) CA provider:
<CodeBlockConfig filename="values.yaml">
@ -83,7 +83,7 @@ global:
The `address` you provide to the `connectCA` configuration can be a Kubernetes DNS
address if the Vault cluster is running the same Kubernetes cluster.
The `rootPKIPath` and `intermediatePKIPath` should be the same as the ones
defined in your Connect CA policy. Behind the scenes, Consul will authenticate to Vault using a Kubernetes
defined in your service mesh CA policy. Behind the scenes, Consul will authenticate to Vault using a Kubernetes
service account using the [Kubernetes auth method](/vault/docs/auth/kubernetes) and will use the Vault token for any API calls to Vault. If the Vault token can not be renewed, Consul will re-authenticate to
generate a new Vault token.
@ -95,7 +95,7 @@ $ kubectl create secret generic vault-ca --from-file vault.ca=/path/to/your/vaul
### Secondary Datacenters
To configure Vault as the Connect CA in secondary datacenters, you need to make sure that the Root CA path is the same,
To configure Vault as the service mesh (connect) CA in secondary datacenters, you need to make sure that the Root CA path is the same,
but the intermediate is different for each datacenter. In the `connectCA` Helm configuration for a secondary datacenter,
you can specify a `intermediatePKIPath` that is, for example, prefixed with the datacenter
for which this configuration is intended (e.g. `dc2/connect-intermediate`).

2
website/content/docs/k8s/deployment-configurations/vault/wan-federation.mdx
View File

@ -626,7 +626,7 @@ Repeat the following steps for each datacenter in the cluster:
1. Configure and install Consul in the secondary datacenter (dc2).
-> **Note**: To configure Vault as the Connect CA in secondary datacenters, you need to make sure that the Root CA path is the same. The intermediate path is different for each datacenter. In the `connectCA` Helm configuration for a secondary datacenter, you can specify a `intermediatePKIPath` that is, for example, prefixed with the datacenter for which this configuration is intended (e.g. `dc2/connect-intermediate`).
-> **Note**: To configure Vault as the service mesh (connect) CA in secondary datacenters, you need to make sure that the Root CA path is the same. The intermediate path is different for each datacenter. In the `connectCA` Helm configuration for a secondary datacenter, you can specify a `intermediatePKIPath` that is, for example, prefixed with the datacenter for which this configuration is intended (e.g. `dc2/connect-intermediate`).
<CodeBlockConfig filename="consul-dc2.yaml" linenumbers highlight="4,5,6,7,8,9,10,11,12,13,14,15,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,37,38">

54
website/content/docs/k8s/helm.mdx
View File

@ -211,7 +211,7 @@ Use these links to navigate to a particular top-level stanza.
- `secretKey` ((#v-global-secretsbackend-vault-ca-secretkey)) (`string: ""`) - The key within the Kubernetes or Vault secret that holds the Vault CA certificate.
- `connectCA` ((#v-global-secretsbackend-vault-connectca)) - Configuration for the Vault Connect CA provider.
- `connectCA` ((#v-global-secretsbackend-vault-connectca)) - Configuration for the Vault service mesh CA provider.
The provider will be configured to use the Vault Kubernetes auth method
and therefore requires the role provided by `global.secretsBackend.vault.consulServerRole`
to have permissions to the root and intermediate PKI paths.
@ -223,13 +223,13 @@ Use these links to navigate to a particular top-level stanza.
- `authMethodPath` ((#v-global-secretsbackend-vault-connectca-authmethodpath)) (`string: kubernetes`) - The mount path of the Kubernetes auth method in Vault.
- `rootPKIPath` ((#v-global-secretsbackend-vault-connectca-rootpkipath)) (`string: ""`) - The path to a PKI secrets engine for the root certificate.
For more details, please refer to [Vault Connect CA configuration](/consul/docs/connect/ca/vault#rootpkipath).
For more details, please refer to [Vault service mesh CA configuration](/consul/docs/connect/ca/vault#rootpkipath).
- `intermediatePKIPath` ((#v-global-secretsbackend-vault-connectca-intermediatepkipath)) (`string: ""`) - The path to a PKI secrets engine for the generated intermediate certificate.
For more details, please refer to [Vault Connect CA configuration](/consul/docs/connect/ca/vault#intermediatepkipath).
For more details, please refer to [Vault service mesh CA configuration](/consul/docs/connect/ca/vault#intermediatepkipath).
- `additionalConfig` ((#v-global-secretsbackend-vault-connectca-additionalconfig)) (`string: {}`) - Additional Connect CA configuration in JSON format.
Please refer to [Vault Connect CA configuration](/consul/docs/connect/ca/vault#configuration)
- `additionalConfig` ((#v-global-secretsbackend-vault-connectca-additionalconfig)) (`string: {}`) - Additional service mesh CA configuration in JSON format.
Please refer to [Vault service mesh CA configuration](/consul/docs/connect/ca/vault#configuration)
for all configuration options available for that provider.
Example:
@ -250,14 +250,14 @@ Use these links to navigate to a particular top-level stanza.
- `caCert` ((#v-global-secretsbackend-vault-connectinject-cacert)) - Configuration to the Vault Secret that Kubernetes uses on
Kubernetes pod creation, deletion, and update, to get CA certificates
used issued from vault to send webhooks to the ConnectInject.
used issued from vault to send webhooks to the connect inject.
- `secretName` ((#v-global-secretsbackend-vault-connectinject-cacert-secretname)) (`string: null`) - The Vault secret path that contains the CA certificate for
Connect Inject webhooks.
connect inject webhooks.
- `tlsCert` ((#v-global-secretsbackend-vault-connectinject-tlscert)) - Configuration to the Vault Secret that Kubernetes uses on
Kubernetes pod creation, deletion, and update, to get TLS certificates
used issued from vault to send webhooks to the ConnectInject.
used issued from vault to send webhooks to the connect inject.
- `secretName` ((#v-global-secretsbackend-vault-connectinject-tlscert-secretname)) (`string: null`) - The Vault secret path that issues TLS certificates for connect
inject webhooks.
@ -672,10 +672,10 @@ Use these links to navigate to a particular top-level stanza.
contains best practices and recommendations for selecting suitable
hardware sizes for your Consul servers.
- `connect` ((#v-server-connect)) (`boolean: true`) - This will enable/disable [Connect](/consul/docs/connect). Setting this to true
- `connect` ((#v-server-connect)) (`boolean: true`) - This will enable/disable [service mesh](/consul/docs/connect). Setting this to true
_will not_ automatically secure pod communication, this
setting will only enable usage of the feature. Consul will automatically initialize
a new CA and set of certificates. Additional Connect settings can be configured
a new CA and set of certificates. Additional service mesh settings can be configured
by setting the `server.extraConfig` value.
- `serviceAccount` ((#v-server-serviceaccount))
@ -1027,7 +1027,7 @@ Use these links to navigate to a particular top-level stanza.
- `grpc` ((#v-client-grpc)) (`boolean: true`) - If true, agents will enable their GRPC listener on
port 8502 and expose it to the host. This will use slightly more resources, but is
required for Connect.
required for service mesh.
- `nodeMeta` ((#v-client-nodemeta)) - nodeMeta specifies an arbitrary metadata key/value pair to associate with the node
(refer to [`-node-meta`](/consul/docs/agent/config/cli-flags#_node_meta))
@ -1228,7 +1228,7 @@ Use these links to navigate to a particular top-level stanza.
- `enabled` ((#v-dns-enabled)) (`boolean: -`)
- `enableRedirection` ((#v-dns-enableredirection)) (`boolean: -`) - If true, services using Consul Connect will use Consul DNS
- `enableRedirection` ((#v-dns-enableredirection)) (`boolean: -`) - If true, services using Consul service mesh will use Consul DNS
for default DNS resolution. The DNS lookups fall back to the nameserver IPs
listed in /etc/resolv.conf if not found in Consul.
@ -1538,9 +1538,9 @@ Use these links to navigate to a particular top-level stanza.
### connectInject ((#h-connectinject))
- `connectInject` ((#v-connectinject)) - Configures the automatic Connect sidecar injector.
- `connectInject` ((#v-connectinject)) - Configures the automatic service mesh sidecar injector.
- `enabled` ((#v-connectinject-enabled)) (`boolean: true`) - True if you want to enable connect injection. Set to "-" to inherit from
- `enabled` ((#v-connectinject-enabled)) (`boolean: true`) - True if you want to enable service mesh sidecar injection. Set to "-" to inherit from
global.enabled.
- `replicas` ((#v-connectinject-replicas)) (`integer: 1`) - The number of deployment replicas.
@ -1550,13 +1550,13 @@ Use these links to navigate to a particular top-level stanza.
- `default` ((#v-connectinject-default)) (`boolean: false`) - If true, the injector will inject the
Connect sidecar into all pods by default. Otherwise, pods must specify the
[injection annotation](/consul/docs/k8s/connect#consul-hashicorp-com-connect-inject)
to opt-in to Connect injection. If this is true, pods can use the same annotation
to opt-in to service mesh sidecar injection. If this is true, pods can use the same annotation
to explicitly opt-out of injection.
- `transparentProxy` ((#v-connectinject-transparentproxy)) - Configures Transparent Proxy for Consul Service mesh services.
Using this feature requires Consul 1.10.0-beta1+.
- `defaultEnabled` ((#v-connectinject-transparentproxy-defaultenabled)) (`boolean: true`) - If true, then all Consul Service mesh will run with transparent proxy enabled by default,
- `defaultEnabled` ((#v-connectinject-transparentproxy-defaultenabled)) (`boolean: true`) - If true, then all Consul service mesh will run with transparent proxy enabled by default,
i.e. we enforce that all traffic within the pod will go through the proxy.
This value is overridable via the "consul.hashicorp.com/transparent-proxy" pod annotation.
@ -1651,7 +1651,7 @@ Use these links to navigate to a particular top-level stanza.
persistent: true
```
- `metrics` ((#v-connectinject-metrics)) - Configures metrics for Consul Connect services. All values are overridable
- `metrics` ((#v-connectinject-metrics)) - Configures metrics for services in the Consul service mesh. All values are overridable
via annotations on a per-pod basis.
- `defaultEnabled` ((#v-connectinject-metrics-defaultenabled)) (`string: -`) - If true, the connect-injector will automatically
@ -1660,14 +1660,14 @@ Use these links to navigate to a particular top-level stanza.
metrics will depend on whether metrics merging is enabled:
- If metrics merging is enabled:
the consul-dataplane will run a merged metrics server
combining Envoy sidecar and Connect service metrics,
combining Envoy sidecar and mesh service metrics,
i.e. if your service exposes its own Prometheus metrics.
- If metrics merging is disabled:
the listener will just expose Envoy sidecar metrics.
This will inherit from `global.metrics.enabled`.
- `defaultEnableMerging` ((#v-connectinject-metrics-defaultenablemerging)) (`boolean: false`) - Configures the consul-dataplane to run a merged metrics server
to combine and serve both Envoy and Connect service metrics.
to combine and serve both Envoy and mesh service metrics.
This feature is available only in Consul v1.10.0 or greater.
- `defaultMergedMetricsPort` ((#v-connectinject-metrics-defaultmergedmetricsport)) (`integer: 20100`) - Configures the port at which the consul-dataplane will listen on to return
@ -1768,13 +1768,13 @@ Use these links to navigate to a particular top-level stanza.
namespace-label: label-value
```
- `k8sAllowNamespaces` ((#v-connectinject-k8sallownamespaces)) (`array<string>: ["*"]`) - List of k8s namespaces to allow Connect sidecar
- `k8sAllowNamespaces` ((#v-connectinject-k8sallownamespaces)) (`array<string>: ["*"]`) - List of k8s namespaces to allow service mesh sidecar
injection in. If a k8s namespace is not included or is listed in `k8sDenyNamespaces`,
pods in that k8s namespace will not be injected even if they are explicitly
annotated. Use `["*"]` to automatically allow all k8s namespaces.
For example, `["namespace1", "namespace2"]` will only allow pods in the k8s
namespaces `namespace1` and `namespace2` to have Connect sidecars injected
namespaces `namespace1` and `namespace2` to have service mesh sidecars injected
and registered with Consul. All other k8s namespaces will be ignored.
To deny all namespaces, set this to `[]`.
@ -1783,7 +1783,7 @@ Use these links to navigate to a particular top-level stanza.
`namespaceSelector` takes precedence over both since it is applied first.
`kube-system` and `kube-public` are never injected, even if included here.
- `k8sDenyNamespaces` ((#v-connectinject-k8sdenynamespaces)) (`array<string>: []`) - List of k8s namespaces that should not allow Connect
- `k8sDenyNamespaces` ((#v-connectinject-k8sdenynamespaces)) (`array<string>: []`) - List of k8s namespaces that should not allow service mesh
sidecar injection. This list takes precedence over `k8sAllowNamespaces`.
`*` is not supported because then nothing would be allowed to be injected.
@ -1848,7 +1848,7 @@ Use these links to navigate to a particular top-level stanza.
auth method for Connect inject, set this to the name of your auth method.
- `aclInjectToken` ((#v-connectinject-aclinjecttoken)) - Refers to a Kubernetes secret that you have created that contains
an ACL token for your Consul cluster which allows the Connect injector the correct
an ACL token for your Consul cluster which allows the connect injector the correct
permissions. This is only needed if Consul namespaces <EnterpriseAlert inline /> and ACLs
are enabled on the Consul cluster and you are not setting
`global.acls.manageSystemACLs` to `true`.
@ -1892,7 +1892,7 @@ Use these links to navigate to a particular top-level stanza.
- `cpu` ((#v-connectinject-sidecarproxy-resources-limits-cpu)) (`string: null`) - Recommended production default: 100m
- `initContainer` ((#v-connectinject-initcontainer)) (`map`) - The resource settings for the Connect injected init container. If null, the resources
- `initContainer` ((#v-connectinject-initcontainer)) (`map`) - The resource settings for the connect injected init container. If null, the resources
won't be set for the initContainer. The defaults are optimized for developer instances of
Kubernetes, however they should be tweaked with the recommended defaults as shown below to speed up service registration times.
@ -1912,10 +1912,10 @@ Use these links to navigate to a particular top-level stanza.
### meshGateway ((#h-meshgateway))
- `meshGateway` ((#v-meshgateway)) - [Mesh Gateways](/consul/docs/connect/gateways/mesh-gateway) enable Consul Connect to work across Consul datacenters.
- `meshGateway` ((#v-meshgateway)) - [Mesh Gateways](/consul/docs/connect/gateways/mesh-gateway) enable Consul service mesh to work across Consul datacenters.
- `enabled` ((#v-meshgateway-enabled)) (`boolean: false`) - If [mesh gateways](/consul/docs/connect/gateways/mesh-gateway) are enabled, a Deployment will be created that runs
gateways and Consul Connect will be configured to use gateways.
gateways and Consul service mesh will be configured to use gateways.
This setting is required for [cluster peering](/consul/docs/k8s/connect/cluster-peering/tech-specs).
Requirements: consul 1.6.0+ if using `global.acls.manageSystemACLs``.
@ -2477,7 +2477,7 @@ ui:
type: LoadBalancer
```
The below `values.yaml` results in a three server Consul Enterprise cluster with 100GB of storage and automatic Connect injection.
The below `values.yaml` results in a three server Consul Enterprise cluster with 100GB of storage and automatic connect injection.
Note, this would require a secret that contains the enterprise license key.

10
website/content/docs/k8s/operations/tls-on-existing-cluster.mdx
View File

@ -13,7 +13,7 @@ you may want to configure TLS in a way that minimizes downtime to your applicati
Consul already supports rolling out TLS on an existing cluster without downtime.
However, depending on your Kubernetes use case, your upgrade procedure may be different.
## Gradual TLS Rollout without Consul Connect
## Gradual TLS Rollout without Consul Service Mesh
If you do not use a service mesh, follow this process.
@ -39,7 +39,7 @@ If you do not use a service mesh, follow this process.
1. Repeat steps 1 and 2, turning on TLS verification by setting `global.tls.verify`
to `true`.
## Gradual TLS Rollout with Consul Connect
## Gradual TLS Rollout with Consul Service Mesh
Because the sidecar Envoy proxies need to talk to the Consul client agent regularly
for service discovery, we can't enable TLS on the clients without also re-injecting a
@ -75,12 +75,12 @@ applications to it.
1. Run `helm upgrade` with the above config file.
1. At this point, all components (e.g., Consul Connect webhook and sync catalog) should be running
1. At this point, all components (e.g., Consul service mesh webhook and sync catalog) should be running
on the new node pool.
1. Redeploy all your Connect-enabled applications.
1. Redeploy all your mesh-enabled applications.
One way to trigger a redeploy is to run `kubectl drain` on the nodes in the old pool.
Now that the Connect webhook is TLS-aware, it adds TLS configuration to
Now that the service mesh webhook is TLS-aware, it adds TLS configuration to
the sidecar proxy. Also, Kubernetes should schedule these applications on the new node pool.
1. Perform a rolling upgrade of the servers described in

16
website/content/docs/lambda/invocation.mdx
View File

@ -11,7 +11,7 @@ This topic describes how to invoke AWS Lambda functions from the Consul service
## Overview
You can invoke Lambda functions from the Consul service mesh through terminating gateways (recommended) or directly from connect proxies.
You can invoke Lambda functions from the Consul service mesh through terminating gateways (recommended) or directly from service mesh proxies.
### Terminating Gateway
@ -30,13 +30,13 @@ The following diagram shows the invocation procedure:
</ImageConfig>
1. Make an HTTP request to the local Connect proxy.
1. The Connect proxy forwards the request to the terminating gateway.
1. Make an HTTP request to the local service mesh proxy.
1. The service mesh proxy forwards the request to the terminating gateway.
1. The terminating gateway invokes the function.
### Connect Proxy
### Service Mesh Proxy
You can invoke Lambda functions directly from a service's Connect proxy.
You can invoke Lambda functions directly from a service's mesh sidecar proxy.
This method has the following limitations:
- Intentions are unsupported. Consul enforces intentions by validating the client certificates presented when a connection is received. Lambda does not support client certificate validation, which prevents Consul from supporting intentions using this method.
- Transparent proxies are unsupported. This is because Lambda services are not
@ -50,12 +50,12 @@ The following diagram shows the invocation procedure:
<ImageConfig width={400}>
![Connect Proxy to Lambda](/img/connect_proxy_to_lambda.svg)
![Service Mesh Proxy to Lambda](/img/connect_proxy_to_lambda.svg)
</ImageConfig>
1. Make an HTTP request to the local Connect proxy.
2. The Connect proxy invokes the Lambda.
1. Make an HTTP request to the local service mesh proxy.
2. The service mesh proxy invokes the Lambda.
## Invoke a Lambda Function
Before you can invoke a Lambda function, register the service used to invoke

2
website/content/docs/release-notes/consul/v1_11_x.mdx
View File

@ -17,7 +17,7 @@ description: >-
- **TLS Certificates for Ingress Gateways via an SDS source**: Ingress Gateways can now be configured to retrieve TLS certificates from an external SDS Service and load the TLS certificates for Ingress listeners. This configuration is set using the `ingress-gateway` configuration entry via the [SDS](/consul/docs/connect/config-entries/ingress-gateway#sds) stanza within the Ingress Gateway TLS configuration.
- **Vault Auth Method support for Connect CA Vault Provider**: Consul now supports configuring the Connect CA Vault provider to use auth methods for authentication to Vault. Consul supports using any non-deprecated auth method that is available in Vault v1.8.5, including AppRole, AliCloud, AWS, Azure, Cloud Foundry, GitHub, Google Cloud, JWT/OIDC, Kerberos, Kubernetes, LDAP, Oracle Cloud Infrastructure, Okta, Radius, TLS Certificates, and Username & Password. The Vault Auth Method for Connect CA Provider is utilized by default for the [Vault Secrets Backend](/consul/docs/k8s/deployment-configurations/vault) feature on Consul on Kubernetes. Utilizing a Vault Auth method would no longer require a Vault token to be managed or provisioned ahead of time to be used for authentication to Vault.
- **Vault Auth Method support for service mesh CA Vault Provider**: Consul now supports configuring the service mesh CA Vault provider to use auth methods for authentication to Vault. Consul supports using any non-deprecated auth method that is available in Vault v1.8.5, including AppRole, AliCloud, AWS, Azure, Cloud Foundry, GitHub, Google Cloud, JWT/OIDC, Kerberos, Kubernetes, LDAP, Oracle Cloud Infrastructure, Okta, Radius, TLS Certificates, and Username & Password. The Vault Auth Method for service mesh CA Provider is utilized by default for the [Vault Secrets Backend](/consul/docs/k8s/deployment-configurations/vault) feature on Consul on Kubernetes. Utilizing a Vault Auth method would no longer require a Vault token to be managed or provisioned ahead of time to be used for authentication to Vault.
## What's Changed

2
website/content/docs/security/acl/acl-rules.mdx
View File

@ -34,7 +34,7 @@ The following resources are not covered by ACL policies:
- The [Status API](/consul/api-docs/status) is used by servers when bootstrapping and exposes basic IP and port information about the servers, and does not allow modification of any state.
- The datacenter listing operation of the [Catalog API](/consul/api-docs/catalog#list-datacenters) similarly exposes the names of known Consul datacenters, and does not allow modification of any state.
- The [connect CA roots endpoint](/consul/api-docs/connect/ca#list-ca-root-certificates) exposes just the public TLS certificate which other systems can use to verify the TLS connection with Consul.
- The [service mesh CA roots endpoint](/consul/api-docs/connect/ca#list-ca-root-certificates) exposes just the public TLS certificate which other systems can use to verify the TLS connection with Consul.
-> **Consul Enterprise Namespace** - In addition to directly-linked policies, roles, and service identities, Consul Enterprise enables ACL policies and roles to be defined in the [Namespaces definition](/consul/docs/enterprise/namespaces#namespace-definition) (Consul Enterprise 1.7.0+).

4
website/content/docs/security/acl/auth-methods/index.mdx
View File

@ -27,8 +27,8 @@ integrations allow for these credentials to be used to create ACL tokens with
properly-scoped policies without additional operator intervention.
In Consul 1.5.0 the focus is around simplifying the creation of tokens with the
privileges necessary to participate in a [Connect](/consul/docs/connect)
service mesh with minimal operator intervention.
privileges necessary to participate in a [service mesh](/consul/docs/connect)
with minimal operator intervention.
## Supported Types

32
website/content/docs/security/security-models/core.mdx
View File

@ -102,21 +102,21 @@ environment and adapt these configurations accordingly.
`server.<datacenter>.<domain>` hostname for outgoing TLS connections. The default configuration does not verify the
hostname of the certificate, only that it is signed by a trusted CA. This setting is critical to prevent a
compromised client agent from being restarted as a server and having all cluster state including all ACL tokens and
Connect CA root keys replicated to it. This setting was introduced in 0.5.1. From version 0.5.1 to 1.4.0 we
service mesh CA root keys replicated to it. This setting was introduced in 0.5.1. From version 0.5.1 to 1.4.0 we
documented that `verify_server_hostname` being true implied verify_outgoing however due to a bug this was not the
case so setting only `verify_server_hostname` results in plaintext communication between client and server. See
[CVE-2018-19653](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19653) for more details. This is fixed
in 1.4.1.
- [`auto_encrypt`](/consul/docs/agent/config/config-files#auto_encrypt) - Enables automated TLS certificate distribution for client
agent RPC communication using the Connect CA. Using this configuration a [`ca_file`](/consul/docs/agent/config/config-files#tls_defaults_ca_file)
agent RPC communication using the service mesh CA. Using this configuration a [`ca_file`](/consul/docs/agent/config/config-files#tls_defaults_ca_file)
and ACL token would still need to be distributed to client agents.
- [`allow_tls`](/consul/docs/agent/config/config-files#allow_tls) - By default this is false, and should be set to true on server
agents to allow certificates to be automatically generated and distributed from the Connect CA to client agents.
agents to allow certificates to be automatically generated and distributed from the service mesh CA to client agents.
- [`tls`](/consul/docs/agent/config/config-files#tls) - By default this is false, and should be set to true on client agents to
automatically request a client TLS certificate from the server's Connect CA.
automatically request a client TLS certificate from the server's service mesh CA.
**Example Server Agent TLS Configuration**
@ -321,7 +321,7 @@ The following are parts of the core Consul threat model:
This requires transport encryption to be enabled on the cluster and covers both TCP and UDP traffic.
- **Consul agent-to-CA communication** - Communication between the Consul server and the configured certificate
authority provider for Connect is always encrypted.
authority provider for service mesh is always encrypted.
- **Tampering of data in transit** - Any tampering should be detectable and cause Consul to avoid processing
the request.
@ -338,13 +338,13 @@ The following are parts of the core Consul threat model:
- **Denial of Service against a node** - DoS attacks against a node should not compromise the security stance of
the software.
- **Connect-based Service-to-Service communication** - Communications between two Connect-enabled services (natively or
by proxy) should be secure from eavesdropping and provide authentication. This is achieved via mutual TLS.
- **Communication between mesh services** - Communications between two mesh-enabled services (natively or
by sidecar proxy) should be secure from eavesdropping and provide authentication. This is achieved via mutual TLS.
The following are not part of the threat model for server agents:
- **Access (read or write) to the Consul data directory** - All Consul servers, including non-leaders, persist the full
set of Consul state to this directory. The data includes all KV, service registrations, ACL tokens, Connect CA
set of Consul state to this directory. The data includes all KV, service registrations, ACL tokens, service mesh CA
configuration, and more. Any read or write to this directory allows an attacker to access and tamper with that data.
- **Access (read or write) to the Consul configuration directory** - Consul configuration can enable or disable the ACL
@ -353,14 +353,14 @@ The following are not part of the threat model for server agents:
- **Memory access to a running Consul server agent** - If an attacker is able to inspect the memory state of a running
Consul server agent the confidentiality of almost all Consul data may be compromised. If you're using an external
Connect CA, the root private key material is never available to the Consul process and can be considered safe. Service
Connect TLS certificates should be considered compromised; they are never persisted by server agents but do exist
service mesh CA, the root private key material is never available to the Consul process and can be considered safe. Service
service mesh TLS certificates should be considered compromised; they are never persisted by server agents but do exist
in-memory during at least the duration of a Sign request.
The following are not part of the threat model for client agents:
- **Access (read or write) to the Consul data directory** - Consul clients will use the data directory to cache local
state. This includes local services, associated ACL tokens, Connect TLS certificates, and more. Read or write access
state. This includes local services, associated ACL tokens, service mesh TLS certificates, and more. Read or write access
to this directory will allow an attacker to access this data. This data is typically a smaller subset of the full data
of the cluster.
- **Access (read or write) to the Consul configuration directory** - Consul client configuration files contain the
@ -371,18 +371,18 @@ The following are not part of the threat model for client agents:
- **Memory access to a running Consul client agent** - The blast radius of this is much smaller than a server agent but
the confidentiality of a subset of data can still be compromised. Particularly, any data requested against the agent's
API including services, KV, and Connect information may be compromised. If a particular set of data on the server was
API including services, KV, and service mesh information may be compromised. If a particular set of data on the server was
never requested by the agent, it never enters the agent's memory since replication only exists between servers. An
attacker could also potentially extract ACL tokens used for service registration on this agent, since the tokens must
be stored in-memory alongside the registered service.
- **Network access to a local Connect proxy or service** - Communications between a service and a Connect-aware proxy
- **Network access to a local service mesh proxy or service** - Communications between a service and a mesh-aware proxy
are generally unencrypted and must happen over a trusted network. This is typically a loopback device. This requires
that other processes on the same machine are trusted, or more complex isolation mechanisms are used such as network
namespaces. This also requires that external processes cannot communicate to the Connect service or proxy (except on
the inbound port). Therefore, non-native Connect applications should only bind to non-public addresses.
namespaces. This also requires that external processes cannot communicate to the mesh service or sidecar proxy (except on
the inbound port). Therefore, non-native service mesh applications should only bind to non-public addresses.
- **Improperly Implemented Connect proxy or service** - A Connect proxy or natively integrated service must correctly
- **Improperly Implemented service mesh proxy or service** - A service mesh proxy or natively integrated service must correctly
serve a valid leaf certificate, verify the inbound TLS client certificate, and call the Consul agent-local authorized
endpoint. If any of this isn't performed correctly, the proxy or service may allow unauthenticated or unauthorized
connections.

2
website/content/docs/security/security-models/nia.mdx
View File

@ -76,7 +76,7 @@ security concerns accordingly.
- **Run without Root** - The NIA daemon does not require root or other administrative privileges to operate.
- **Protect NIA Daemon API Endpoint** - Any network endpoints provided by, or exposed to the NIA Daemon should be
protected using Consul Connect and appropriate firewall rules.
protected using Consul service mesh and appropriate firewall rules.
- **Use a centralized logging solution** - Export log entries within [syslog](https://en.wikipedia.org/wiki/Syslog)
generated from `consul-terraform-sync` to a centralized logging solution.

2
website/content/docs/services/services.mdx
View File

@ -6,7 +6,7 @@ description: >-
---
# Services overview
This topic provides overview information about services and how to make them discoverable in Consul when your network operates on virtual machines. If service mesh is enabled in your network, refer to the topics in [Consul Service Mesh](/consul/docs/connect/). If your network is running in Kubernetes, refer to the topics in [Consul on Kubernetes](/consul/docs/k8s).
This topic provides overview information about services and how to make them discoverable in Consul when your network operates on virtual machines. If service mesh is enabled in your network, refer to the topics in [Consul service mesh](/consul/docs/connect/). If your network is running in Kubernetes, refer to the topics in [Consul on Kubernetes](/consul/docs/k8s).
## Introduction
A _service_ is an entity in your network that performs a specialized operation or set of related operations. In many contexts, a service is software that you want to make available to users or other programs with access to your network. Services can also refer to native Consul functionality, such as _service mesh proxies_ and _gateways_, that enable you to establish connections between different parts of your network.

23
website/content/docs/upgrading/upgrade-specific.mdx
View File

@ -157,13 +157,13 @@ In Consul v1.15 and higher:
## Consul 1.14.x
### Service Mesh Compatibility
Prior to Consul 1.14, cluster peering or Consul connect were disabled by default.
Prior to Consul 1.14, cluster peering and Consul service mesh were disabled by default.
A breaking change was made in Consul 1.14 that:
- [Cluster Peering is enabled by default.](/consul/docs/connect/cluster-peering)
Cluster peering and WAN federation can coexist,
so there is no need to disable cluster peering to upgrade existing WAN federated datacenters.
To disable cluster peering nonetheless, set [`peering.enabled`](/consul/docs/agent/config/config-files#peering_enabled) to `false`.
- [Consul Connect is enabled by default.](/consul/docs/connect)
- [Consul service mesh is enabled by default.](/consul/docs/connect)
To disable, set [`connect.enabled`](/consul/docs/agent/config/config-files#connect_enabled) to `false`.
The changes to Consul service mesh in version 1.14 are incompatible with Nomad 1.4.3 and
@ -228,7 +228,7 @@ Consul 1.13.0 contains a bug that prevents Consul server agents from restoring
saved state on startup if the state
1. was generated before Consul 1.13 (such as during an upgrade), and
2. contained any Connect proxy registrations.
2. contained any service mesh proxy registrations.
This bug is fixed in Consul versions 1.13.1 and newer.
@ -770,7 +770,7 @@ registrations](/consul/docs/connect/registration/sidecar-service).
There are two major features in Consul 1.4.0 that may impact upgrades: a [new
ACL system](#acl-upgrade) and [multi-datacenter support for
Connect](#connect-multi-datacenter) in the Enterprise version.
service mesh](#multi-datacenter-service-mesh) in the Enterprise version.
### ACL Upgrade
@ -851,13 +851,13 @@ as soon as possible after upgrade, as well as updating any integrations to work
with the the new ACL [Token](/consul/api-docs/acl/tokens) and
[Policy](/consul/api-docs/acl/policies) APIs.
### Connect Multi-datacenter
### Multi-datacenter service mesh
This only applies to users upgrading from an older version of Consul Enterprise to Consul Enterprise 1.4.0 (all license types).
In addition, this upgrade will only affect clusters where [Connect is enabled](/consul/docs/connect/configuration) on your servers before the migration.
In addition, this upgrade will only affect clusters where [service mesh is enabled](/consul/docs/connect/configuration) on your servers before the migration.
Connect multi-datacenter uses the same primary/secondary approach as ACLs and
Multi-datacenter service mesh uses the same primary/secondary approach as ACLs and
will use the same [primary_datacenter](#primary-datacenter). When a secondary
datacenter server restarts with 1.4.0 it will detect it is not the primary and
begin an automatic bootstrap of multi-datacenter CA federation.
@ -866,11 +866,11 @@ Datacenters can be upgraded in either order; secondary datacenters will not
switch into multi-datacenter mode until all servers in both the secondary and
primary datacenter are detected to be running at least Consul 1.4.0. Secondary
datacenters monitor this periodically (every few minutes) and will
automatically upgrade Connect to use a federated Certificate Authority when
automatically upgrade service mesh to use a federated Certificate Authority when
they do.
In general, migrating a Consul cluster from OSS to Enterprise will update the
CA to be federated automatically and without impact on Connect traffic. When
CA to be federated automatically and without impact on service mesh traffic. When
upgrading Consul Enterprise 1.3.x to Consul Enterprise 1.4.0 upgrades the CA
upgrade is seamless, however depending on the size of the cluster, _new_
connection attempts in the secondary datacenter might fail for a short window
@ -879,15 +879,12 @@ authorization endpoint validating originating cluster in a way that was not
fully forwards compatible with migrating between cluster trust domains. That
issue is fixed in 1.4.0 as part of General Availability.
Once migrated (typically a few seconds). Connect will use the primary
Once migrated (typically a few seconds). The service mesh will use the primary
datacenter's Certificate Authority as the root of trust for all other
datacenters. CA migration or root key changes in the primary will now rotate
automatically and without loss of connectivity throughout all datacenters and
workloads.
For more information see [Connect
Multi-datacenter](/consul/docs/enterprise).
## Consul 1.3.0
This version added support for multiple tag filters in service discovery

2
website/public/img/connect_proxy_to_lambda.svg
View File

@ -13,4 +13,4 @@
}
</style>
</defs>
<rect x="0" y="0" width="560" height="280" fill="#ffffff"></rect><g stroke-linecap="round" transform="translate(10 30) rotate(0 90 40)"><path d="M0 0 C59.55 0, 119.1 0, 180 0 M0 0 C42.4 0, 84.81 0, 180 0 M180 0 C180 31.86, 180 63.72, 180 80 M180 0 C180 18.33, 180 36.66, 180 80 M180 80 C135.24 80, 90.48 80, 0 80 M180 80 C117.05 80, 54.09 80, 0 80 M0 80 C0 61.71, 0 43.41, 0 0 M0 80 C0 50.9, 0 21.8, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(15 61.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Lambda</text></g><g stroke-linecap="round" transform="translate(350 30) rotate(0 90 40)"><path d="M0 0 C50.63 0, 101.26 0, 180 0 M0 0 C62.98 0, 125.97 0, 180 0 M180 0 C180 29.58, 180 59.16, 180 80 M180 0 C180 16.8, 180 33.59, 180 80 M180 80 C130.53 80, 81.06 80, 0 80 M180 80 C133.55 80, 87.1 80, 0 80 M0 80 C0 63.12, 0 46.25, 0 0 M0 80 C0 62.7, 0 45.39, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(355 61.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Connect Proxy</text></g><g stroke-linecap="round" transform="translate(350 170) rotate(0 90 40)"><path d="M0 0 C37.79 0, 75.58 0, 180 0 M0 0 C49.47 0, 98.94 0, 180 0 M180 0 C180 20.64, 180 41.29, 180 80 M180 0 C180 16.88, 180 33.75, 180 80 M180 80 C141.07 80, 102.13 80, 0 80 M180 80 C129.1 80, 78.2 80, 0 80 M0 80 C0 61.81, 0 43.62, 0 0 M0 80 C0 48.92, 0 17.84, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(355 201.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Service</text></g><g stroke-linecap="round" transform="translate(330 10) rotate(0 110 130)"><path d="M0 0 C74.7 0, 149.4 0, 220 0 M0 0 C50.75 0, 101.49 0, 220 0 M220 0 C220 87.57, 220 175.14, 220 260 M220 0 C220 53.74, 220 107.48, 220 260 M220 260 C144.14 260, 68.29 260, 0 260 M220 260 C152.15 260, 84.29 260, 0 260 M0 260 C0 198.84, 0 137.67, 0 0 M0 260 C0 163.23, 0 66.46, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(450 170) rotate(0 0 -30)"><path d="M0 0 C0 -10, 0 -50, 0 -60 M0 0 C0 -10, 0 -50, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(450 170) rotate(0 0 -30)"><path d="M10.26 -31.81 C7.02 -40.7, 3.79 -49.6, 0 -60 M10.26 -31.81 C7.78 -38.63, 5.3 -45.44, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(450 170) rotate(0 0 -30)"><path d="M-10.26 -31.81 C-7.02 -40.7, -3.79 -49.6, 0 -60 M-10.26 -31.81 C-7.78 -38.63, -5.3 -45.44, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g></g><g stroke-linecap="round"><g transform="translate(350 70) rotate(0 -80 0)"><path d="M0 0 C-60.65 0, -121.3 0, -160 0 M0 0 C-51.61 0, -103.22 0, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(350 70) rotate(0 -80 0)"><path d="M-131.81 -10.26 C-142.5 -6.37, -153.18 -2.48, -160 0 M-131.81 -10.26 C-140.9 -6.95, -150 -3.64, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(350 70) rotate(0 -80 0)"><path d="M-131.81 10.26 C-142.5 6.37, -153.18 2.48, -160 0 M-131.81 10.26 C-140.9 6.95, -150 3.64, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g></g><g transform="translate(472.8076349537894 133.68057374010323) rotate(0 5 8.5)"><text x="0" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="start" style="white-space: pre;" direction="ltr">1</text></g><g transform="translate(268.90132808335125 38.78078312115713) rotate(0 5 8.5)"><text x="0" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="start" style="white-space: pre;" direction="ltr">2</text></g></svg>
<rect x="0" y="0" width="560" height="280" fill="#ffffff"></rect><g stroke-linecap="round" transform="translate(10 30) rotate(0 90 40)"><path d="M0 0 C59.55 0, 119.1 0, 180 0 M0 0 C42.4 0, 84.81 0, 180 0 M180 0 C180 31.86, 180 63.72, 180 80 M180 0 C180 18.33, 180 36.66, 180 80 M180 80 C135.24 80, 90.48 80, 0 80 M180 80 C117.05 80, 54.09 80, 0 80 M0 80 C0 61.71, 0 43.41, 0 0 M0 80 C0 50.9, 0 21.8, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(15 61.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Lambda</text></g><g stroke-linecap="round" transform="translate(350 30) rotate(0 90 40)"><path d="M0 0 C50.63 0, 101.26 0, 180 0 M0 0 C62.98 0, 125.97 0, 180 0 M180 0 C180 29.58, 180 59.16, 180 80 M180 0 C180 16.8, 180 33.59, 180 80 M180 80 C130.53 80, 81.06 80, 0 80 M180 80 C133.55 80, 87.1 80, 0 80 M0 80 C0 63.12, 0 46.25, 0 0 M0 80 C0 62.7, 0 45.39, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(355 61.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Mesh Sidecar Proxy</text></g><g stroke-linecap="round" transform="translate(350 170) rotate(0 90 40)"><path d="M0 0 C37.79 0, 75.58 0, 180 0 M0 0 C49.47 0, 98.94 0, 180 0 M180 0 C180 20.64, 180 41.29, 180 80 M180 0 C180 16.88, 180 33.75, 180 80 M180 80 C141.07 80, 102.13 80, 0 80 M180 80 C129.1 80, 78.2 80, 0 80 M0 80 C0 61.81, 0 43.62, 0 0 M0 80 C0 48.92, 0 17.84, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(355 201.5) rotate(0 85 8.5)"><text x="85" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="middle" style="white-space: pre;" direction="ltr">Service</text></g><g stroke-linecap="round" transform="translate(330 10) rotate(0 110 130)"><path d="M0 0 C74.7 0, 149.4 0, 220 0 M0 0 C50.75 0, 101.49 0, 220 0 M220 0 C220 87.57, 220 175.14, 220 260 M220 0 C220 53.74, 220 107.48, 220 260 M220 260 C144.14 260, 68.29 260, 0 260 M220 260 C152.15 260, 84.29 260, 0 260 M0 260 C0 198.84, 0 137.67, 0 0 M0 260 C0 163.23, 0 66.46, 0 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g stroke-linecap="round"><g transform="translate(450 170) rotate(0 0 -30)"><path d="M0 0 C0 -10, 0 -50, 0 -60 M0 0 C0 -10, 0 -50, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(450 170) rotate(0 0 -30)"><path d="M10.26 -31.81 C7.02 -40.7, 3.79 -49.6, 0 -60 M10.26 -31.81 C7.78 -38.63, 5.3 -45.44, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(450 170) rotate(0 0 -30)"><path d="M-10.26 -31.81 C-7.02 -40.7, -3.79 -49.6, 0 -60 M-10.26 -31.81 C-7.78 -38.63, -5.3 -45.44, 0 -60" stroke="#000000" stroke-width="1" fill="none"></path></g></g><g stroke-linecap="round"><g transform="translate(350 70) rotate(0 -80 0)"><path d="M0 0 C-60.65 0, -121.3 0, -160 0 M0 0 C-51.61 0, -103.22 0, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(350 70) rotate(0 -80 0)"><path d="M-131.81 -10.26 C-142.5 -6.37, -153.18 -2.48, -160 0 M-131.81 -10.26 C-140.9 -6.95, -150 -3.64, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g><g transform="translate(350 70) rotate(0 -80 0)"><path d="M-131.81 10.26 C-142.5 6.37, -153.18 2.48, -160 0 M-131.81 10.26 C-140.9 6.95, -150 3.64, -160 0" stroke="#000000" stroke-width="1" fill="none"></path></g></g><g transform="translate(472.8076349537894 133.68057374010323) rotate(0 5 8.5)"><text x="0" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="start" style="white-space: pre;" direction="ltr">1</text></g><g transform="translate(268.90132808335125 38.78078312115713) rotate(0 5 8.5)"><text x="0" y="13" font-family="Helvetica, Segoe UI Emoji" font-size="16px" fill="#000000" text-anchor="start" style="white-space: pre;" direction="ltr">2</text></g></svg>
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.4 KiB

After

Width:  |  Height:  |  Size: 4.4 KiB

2
website/public/img/terminating_gateway_to_lambda.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.0 KiB

After

Width:  |  Height:  |  Size: 6.0 KiB