From 4c6a34353324624b9d1a34446643b4ca662ae9ca Mon Sep 17 00:00:00 2001 From: temp Date: Fri, 18 Aug 2023 13:55:03 -0500 Subject: [PATCH 1/2] no-op commit due to failed cherry-picking From 48b3dc582bdb07e1eab6eb12d121f7f68b8be0d1 Mon Sep 17 00:00:00 2001 From: Tu Nguyen Date: Fri, 18 Aug 2023 11:54:42 -0700 Subject: [PATCH 2/2] fix merge conflicts --- website/content/api-docs/agent/service.mdx | 8 +- website/content/commands/exec.mdx | 2 +- .../docs/agent/config/config-files.mdx | 2 +- .../agent/limits/usage/init-rate-limits.mdx | 31 ++ .../usage/limit-request-rates-from-ips.mdx | 72 +++ .../limits/usage/monitor-rate-limits.mdx | 77 +++ .../usage/set-global-traffic-rate-limits.mdx | 62 +++ .../envoy-extensions/configuration/wasm.mdx | 484 ++++++++++++++++++ .../ecs/terraform/secure-configuration.mdx | 2 +- .../k8s/connect/onboarding-tproxy-mode.mdx | 295 +++++++++++ .../multi-cluster/vms-and-kubernetes.mdx | 2 +- .../docs/release-notes/consul/v1_11_x.mdx | 2 +- .../docs/release-notes/consul/v1_12_x.mdx | 2 +- .../acl/acl-federated-datacenters.mdx | 2 +- .../docs/security/acl/acl-policies.mdx | 4 +- website/content/docs/security/acl/index.mdx | 2 +- .../services/discovery/dns-static-lookups.mdx | 2 +- .../docs/upgrading/upgrade-specific.mdx | 6 +- 18 files changed, 1039 insertions(+), 18 deletions(-) create mode 100644 website/content/docs/agent/limits/usage/init-rate-limits.mdx create mode 100644 website/content/docs/agent/limits/usage/limit-request-rates-from-ips.mdx create mode 100644 website/content/docs/agent/limits/usage/monitor-rate-limits.mdx create mode 100644 website/content/docs/agent/limits/usage/set-global-traffic-rate-limits.mdx create mode 100644 website/content/docs/connect/proxies/envoy-extensions/configuration/wasm.mdx create mode 100644 website/content/docs/k8s/connect/onboarding-tproxy-mode.mdx diff --git a/website/content/api-docs/agent/service.mdx b/website/content/api-docs/agent/service.mdx index 3be17aced19..29b0379063a 100644 --- a/website/content/api-docs/agent/service.mdx +++ b/website/content/api-docs/agent/service.mdx @@ -693,10 +693,10 @@ For the `Connect` field, the parameters are: 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 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). + **Deprecated** Specifies that a managed service mesh proxy should be started + for this service instance, and optionally provides configuration for the proxy. + Managed proxies (which have been deprecated since Consul v1.3.0) have been + [removed](/consul/docs/connect/proxies) since v1.6.0. - `SidecarService` `(ServiceDefinition: nil)` - Specifies an optional nested service definition to register. For more information see [Sidecar Service Registration](/consul/docs/connect/registration/sidecar-service). diff --git a/website/content/commands/exec.mdx b/website/content/commands/exec.mdx index a90cdb35df1..07754bd2b93 100644 --- a/website/content/commands/exec.mdx +++ b/website/content/commands/exec.mdx @@ -40,7 +40,7 @@ execute this command. | `key:write` | `"_rexec"` prefix | | `event:write` | `"_rexec"` prefix | -In addition to the above, the policy associated with the [agent token](/consul/docs/security/acl/acl-tokens#acl-agent-token) should have `write` on `"_rexec"` key prefix. This is for the agents to read the `exec` command and write its output back to the KV store. +In addition to the above, the policy associated with the [agent token](/consul/docs/security/acl/tokens#acl-agent-token) should have `write` on `"_rexec"` key prefix. This policy permits agents to read the `exec` command and write its output back to the KV store. ## Usage diff --git a/website/content/docs/agent/config/config-files.mdx b/website/content/docs/agent/config/config-files.mdx index c6536fa945d..b79104aed50 100644 --- a/website/content/docs/agent/config/config-files.mdx +++ b/website/content/docs/agent/config/config-files.mdx @@ -905,7 +905,7 @@ Refer to the [formatting specification](https://golang.org/pkg/time/#ParseDurati - `default` ((#acl_tokens_default)) - When provided, this agent will use this token by default when making requests to the Consul servers - instead of the [anonymous token](/consul/docs/security/acl/acl-tokens#anonymous-token). + instead of the [anonymous token](/consul/docs/security/acl/tokens#anonymous-token). Consul HTTP API requests can provide an alternate token in their authorization header to override the `default` or anonymous token on a per-request basis, as described in [HTTP API Authentication](/consul/api-docs/api-structure#authentication). diff --git a/website/content/docs/agent/limits/usage/init-rate-limits.mdx b/website/content/docs/agent/limits/usage/init-rate-limits.mdx new file mode 100644 index 00000000000..1c84ca4f6e5 --- /dev/null +++ b/website/content/docs/agent/limits/usage/init-rate-limits.mdx @@ -0,0 +1,31 @@ +--- +layout: docs +page_title: Initialize rate limit settings +description: Learn how to determine regular and peak loads in your network so that you can set the initial global rate limit configurations. +--- + +# Initialize rate limit settings + +Because each network has different needs and application, you need to find out what the regular and peak loads in your network are before you set traffic limits. We recommend completing the following steps to benchmark request rates in your environment so that you can implement limits appropriate for your applications. + +1. In the agent configuration file, specify a global rate limit with arbitrary values based on the following conditions: + + - Environment where Consul servers are running + - Number of servers and the projected load + - Existing metrics expressing requests per second + +1. Set the [`limits.request_limits.mode`](/consul/docs/agent/config/config-files#mode-1) parameter in the agent configuration to `permissive`. In the following example, the configuration allows up to 1000 reads and 500 writes per second for each Consul agent: + + ```hcl + request_limits { + mode = "permissive" + read_rate = 1000.0 + write_rate = 500.0 + } + ``` +1. Observe the logs and metrics for your application's typical cycle, such as a 24 hour period. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for additional information. Call the [`/agent/metrics`](/consul/api-docs/agent#view-metrics) HTTP API endpoint and check the data for the following metrics: + + - `rpc.rate_limit.exceeded` with value `global/read` for label `limit_type` + - `rpc.rate_limit.exceeded` with value `global/write` for label `limit_type` + +1. If the limits are not reached, set the `mode` configuration to `enforcing`. Otherwise, continue to adjust and iterate until you find your network's unique limits. \ No newline at end of file diff --git a/website/content/docs/agent/limits/usage/limit-request-rates-from-ips.mdx b/website/content/docs/agent/limits/usage/limit-request-rates-from-ips.mdx new file mode 100644 index 00000000000..69c97558ce4 --- /dev/null +++ b/website/content/docs/agent/limits/usage/limit-request-rates-from-ips.mdx @@ -0,0 +1,72 @@ +--- +layout: docs +page_title: Limit traffic rates for a source IP address +description: Learn how to set read and request rate limits on RPC and gRPC traffic from all source IP addresses to a Consul resource. +--- + +# Limit traffic rates from source IP addresses + +This topic describes how to configure RPC and gRPC traffic rate limits for source IP addresses. This enables you to specify a budget for read and write requests to prevent any single source IP from overwhelming the Consul server and negatively affecting the network. For information about setting global traffic rate limits, refer to [Set a global limit on traffic rates](/consul/docs/agent/limits/usage/set-global-traffic-rate-limits). For an overview of Consul's server rate limiting capabilities, refer to [Limit traffic rates overview](/consul/docs/agent/limits). + + + +This feature requires Consul Enterprise. Refer to the [feature compatibility matrix](/consul/docs/enterprise#consul-enterprise-feature-availability) for additional information. + + + +## Overview + +You can set limits on the rate of read and write requests from source IP addresses to specific resources, which mitigates the risks to Consul servers when consul clients send excessive requests to a specific resource type. Before configuring traffic rate limits, you should complete the initialization process to understand normal traffic loads in your network. Refer to [Initialize rate limit settings](/consul/docs/agent/limits/init-rate-limits) for additional information. + +Complete the following steps to configure traffic rate limits from a source IP address: + +1. Define rate limits in a control plan request limit configuration entry. You can set limits for different types of resources calls. + +1. Apply the configuration entry to enact the limits. + +You should also monitor read and write rate activity and make any necessary adjustments. Refer to [Monitor rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for additional information. + +## Define rate limits + +Create a control plane request limit configuration entry in the `default` partition. The configuration entry applies to all client requests targeting any partition. Refer to the [control plane request limit configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit) reference documentation for details about the available configuration parameters. + +Specify the following parameters: + +- `kind`: This must be set to `control-plane-request-limit`. +- `name`: Specify the name of the service that you want to limit read and write operations to. +- `read_rate`: Specify overall number of read operations per second allowed from the service. +- `write_rate`: Specify overall number of write operations per second allowed from the service. + +You can also configure limits on calls to the key-value store, ACL system, and Consul catalog. + +## Apply the configuration entry + +If your network is deployed to virtual machines, use the `consul config write` command and specify the control plane request limit configuration entry to apply the configuration. For Kubernetes-orchestrated networks, use the `kubectl apply` command. + + + + +```shell-session +$ consul config write control-plane-request-limit.hcl +``` + + + + +```shell-session +$ consul config write control-plane-request-limit.json +``` + + + + +```shell-session +$ kubectl apply control-plane-request-limit.yaml +``` + + + + +## Disable request rate limits + +Set the [limits.request_limits.mode](/consul/docs/agent/config/config-files#mode-1) in the agent configuration to `disabled` to allow services to exceed the specified read and write requests limits. The `disabled` mode applies to all request rate limits, even limits specifed in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits. \ No newline at end of file diff --git a/website/content/docs/agent/limits/usage/monitor-rate-limits.mdx b/website/content/docs/agent/limits/usage/monitor-rate-limits.mdx new file mode 100644 index 00000000000..23502d1cb14 --- /dev/null +++ b/website/content/docs/agent/limits/usage/monitor-rate-limits.mdx @@ -0,0 +1,77 @@ +--- +layout: docs +page_title: Monitor traffic rate limit data +description: Learn about the metrics and logs you can use to monitor server rate limiting activity, include rate limits for read operations and writer operations +--- + +# Monitor traffic rate limit data + +This topic describes Consul functionality that enables you to monitor read and write request operations taking place in your network. Use the functionality to help you understand normal workloads and set safe limits on the number of requests Consul client agents and services can make to Consul servers. + +## Access rate limit logs + +Consul prints a log line for each rate limit request. The log provides the necessary information for identifying the source of the request and the configured limit. The log provides the information necessary for identifying the source of the request and the configured limit. Consul prints the log `DEBUG` log level and can drop the log to avoid affecting the server health. Dropping a log line increments the `rpc.rate_limit.log_dropped` metric. + +The following example log shows that RPC request from `127.0.0.1:53562` to `KVS.Apply` exceeded the limit: + +```text +2023-02-17T10:01:15.565-0500 [DEBUG] agent.server.rpc-rate-limit: RPC +exceeded allowed rate limit: rpc=KVS.Apply source_addr=127.0.0.1:53562 +limit_type=global/write limit_enforced=false +``` + +Refer to [`log_file`](/consul/docs/agent/config/config-files#log_file) for information about where to retrieve log files. + +## Review rate limit metrics + +Consul captures the following metrics associated with rate limits: + +- Type of limit +- Operation +- Rate limit mode + +Call the `/agent/metrics` API endpoint to view the metrics associated with rate limits. Refer to [View Metrics](/consul/api-docs/agent#view-metrics) for API usage information. In the following example, Consul dropped a call to the consul service because it exceeded the limit by one call: + +```shell-session +$ curl http://127.0.0.1:8500/v1/agent/metrics +{ + . . . + "Counters": [ + { + "Name": "consul.rpc.rate_limit.exceeded", + "Count": 1, + "Sum": 1, + "Min": 1, + "Max": 1, + "Mean": 1, + "Stddev": 0, + "Labels": { + "service": "consul" + } + }, + { + "Name": "consul.rpc.rate_limit.log_dropped", + "Count": 1, + "Sum": 1, + "Min": 1, + "Max": 1, + "Mean": 1, + "Stddev": 0, + "Labels": {} + } + ], + . . . +} +``` + +Refer to [Telemetry](/consul/docs/agent/telemetry) for additional information. + +## Request denials + +When an HTTP request is denied for rate limiting reason, Consul returns one of the following errors: + +- **429 Resource Exhausted**: Indicates that a server is not able to perform the request but that another server could potentially fulfill it. This error is most common on stale reads because any server may fulfill stale read requests. To resolve this type of error, we recommend immediately retrying the request to another server. If the request came from a Consul client agent, the agent automatically retries the request up to the limit set in the [`rpc_hold_timeout`](/consul/docs/agent/config/config-files#rpc_hold_timeout) configuration . + +- **503 Service Unavailable**: Indicates that server is unable to perform the request and that no other server can fulfill the request, either. This usually occurs on consistent reads or for writes. In this case we recommend retrying according to an exponential backoff schedule. If the request came from a Consul client agent, the agent automatically retries the request according to the [`rpc_hold_timeout`](/consul/docs/agent/config/config-files#rpc_hold_timeout) configuration. + +Refer to [Rate limit reached on the server](/consul/docs/troubleshoot/common-errors#rate-limit-reached-on-the-server) for additional information. \ No newline at end of file diff --git a/website/content/docs/agent/limits/usage/set-global-traffic-rate-limits.mdx b/website/content/docs/agent/limits/usage/set-global-traffic-rate-limits.mdx new file mode 100644 index 00000000000..e21aa78c1e2 --- /dev/null +++ b/website/content/docs/agent/limits/usage/set-global-traffic-rate-limits.mdx @@ -0,0 +1,62 @@ +--- +layout: docs +page_title: Set a global limit on traffic rates +description: Use global rate limits to prevent excessive rates of requests to Consul servers. +--- + +# Set a global limit on traffic rates + +This topic describes how to configure rate limits for RPC and gRPC traffic to the Consul server. + +## Introduction + +Rate limits apply to each Consul server separately and limit the number of read requests or write requests to the server on the RPC and internal gRPC endpoints. + +Because all requests coming to a Consul server eventually perform an RPC or an internal gRPC request, global rate limits apply to Consul's user interfaces, such as the HTTP API interface, the CLI, and the external gRPC endpoint for services in the service mesh. + +Refer to [Initialize Rate Limit Settings](/consul/docs/agent/limits/init-rate-limits) for additional information about right-sizing your gRPC request configurations. + +## Set a global rate limit for a Consul server + +Configure the following settings in your Consul server configuration to limit the RPC and gRPC traffic rates. + +- Set the rate limiter [`mode`](/consul/docs/agent/config/config-files#mode-1) +- Set the [`read_rate`](/consul/docs/agent/config/config-files#read_rate) +- Set the [`write_rate`](/consul/docs/agent/config/config-files#write_rate) + +In the following example, the Consul server is configured to prevent more than `500` read and `200` write RPC calls: + + + +```hcl +limits = { + rate_limit = { + mode = "enforcing" + read_rate = 500 + write_rate = 200 + } +} +``` + +```json +{ + "limits" : { + "rate_limit" : { + "mode" : "enforcing", + "read_rate" : 500, + "write_rate" : 200 + } + } +} + +``` + + + +## Monitor request rate traffic + +You should continue to mmonitor request traffic to ensure that request rates remain within the threshold you defined. Refer to [Monitor traffic rate limit data](/consul/docs/agent/limits/usage/monitor-rate-limits) for instructions about checking metrics and log entries, as well as troubleshooting informaiton. + +## Disable request rate limits + +Set the [`limits.request_limits.mode`](/consul/docs/agent/config/config-files#mode-1) to `disabled` to allow services to exceed the specified read and write requests limits, even limits specified in the [control plane request limits configuration entry](/consul/docs/connect/config-entries/control-plane-request-limit). Note that any other mode specified in the agent configuration only applies to global traffic rate limits. diff --git a/website/content/docs/connect/proxies/envoy-extensions/configuration/wasm.mdx b/website/content/docs/connect/proxies/envoy-extensions/configuration/wasm.mdx new file mode 100644 index 00000000000..56d910f3ee5 --- /dev/null +++ b/website/content/docs/connect/proxies/envoy-extensions/configuration/wasm.mdx @@ -0,0 +1,484 @@ +--- +layout: docs +page_title: WebAssembly extension configuration reference +description: Learn how to configure the wasm Envoy extension, which is a builtin Consul extension that allows you to run WebAssembly plugins in Envoy proxies. +--- + +# WebAssembly extension configuration reference + +This topic describes how to configure the `wasm` extension, which directs Consul to run WebAssembly (Wasm) plugins in Envoy proxies. Refer to [Run WebAssembly plug-ins in Envoy proxy](/consul/docs/connect/proxies/envoy-extensions/usage/wasm) for usage information. + +## Configuration model + +The following list outlines the field hierarchy, data types, and requirements for the `wasm` configuration. Place the configuration inside the `EnvoyExtension.Arguments` field in the proxy defaults or service defaults configuration entry. Refer the following documentation for additional information: + +- [`EnvoyExtensions` in proxy defaults](/consul/docs/connect/config-entries/proxy-defaults#envoyextensions) +- [`EnvoyExtensions` in service defaults](/consul/docs/connect/config-entries/service-defaults#envoyextensions) + +Click on a property name to view additional details, including default values. + +- [`Protocol`](#protocol): string +- [`ListenerType`](#listenertype): string | required +- [`ProxyType`](#proxytype): string | `connect-proxy` +- [`PluginConfig`](#pluginconfig): map | required + - [`Name`](#pluginconfig-name): string + - [`RootID`](#pluginconfig-rootid): string | required + - [`VmConfig`](#pluginconfig-vmconfig): map + - [`VmID`](#pluginconfig-vmconfig-vmid): string + - [`Runtime`](#pluginconfig-vmconfig): string | `v8` + - [`Code`](#pluginconfig-vmconfig-code): map + - [`Local`](#pluginconfig-vmconfig-code-local): map + - [`Filename`](#pluginconfig-vmconfig-code-local): string + - [`Remote`](#pluginconfig-vmconfig-code-remote): map + - [`HttpURI`](#pluginconfig-vmconfig-code-remote-httpuri): map + - [`Service`](#pluginconfig-vmconfig-code-remote-httpuri-service): map + - [`Name`](#pluginconfig-vmconfig-code-remote-httpuri-service): string + - [`Namespace`](#pluginconfig-vmconfig-code-remote-httpuri-service): string + - [`Partition`](#pluginconfig-vmconfig-code-remote-httpuri-service): string + - [`URI`](#pluginconfig-vmconfig-code-remote-httpuri-uri): string + - [`Timeout`](#pluginconfig-vmconfig-code-remote-httpuri-timeout): string + - [`SHA256`](#pluginconfig-vmconfig-code-remote-sha256): string + - [`RetryPolicy`](#pluginconfig-vmconfig-code-remote-retrypolicy): map + - [`RetryBackOff`](#pluginconfig-vmconfig-code-remote-retrypolicy-retrybackoff): map + - [`BaseInterval`](#pluginconfig-vmconfig-code-remote-retrypolicy-retrybackoff): string + - [`MaxInterval`](#pluginconfig-vmconfig-code-remote-retrypolicy-retrybackoff): string + - [`NumRetries`](#pluginconfig-vmconfig-code-remote-retrypolicy-numretries): number | `-1` + - [`Configuration`](#pluginconfig-vmconfig-configuration): string + - [`EnvironmentVariables`](#pluginconfig-vmconfig-environmentvariables): map + - [`HostEnvKeys`](#pluginconfig-vmconfig-environmentvariables-hostenvkeys): list of strings + - [`KeyValues`](#pluginconfig-vmconfig-environmentvariables-keyvalues): map + - [`Configuration`](#pluginconfig-configuration): string + - [`CapabilityRestrictionConfiguration`](#pluginconfig-vmconfig-capabilityrestrictionconfiguration): map + - [`AllowedCapabilities`](#pluginconfig-vmconfig-capabilityrestrictionconfiguration): map of strings + +## Complete configuration + +When all parameters are set for the extension, the configuration has the following form: + +```hcl +Protocol = "" +ListenerType = "" +ProxyType = "connect-proxy" +PluginConfig = { + Name = "" + RootID = "" + VmConfig = { + VmID = "" + Runtime = "v8" + Code = { + Local = { # Set either `Local` or `Remote', not both + Filename = "" + } + Remote = { # Set either `Local` or `Remote', not both + HttpURI = { + Service = { + Name = "" + Namespace = "" + Partition = "" + } + URI = "" + Timeout = "1s" + SHA256 = "" + RetryPolicy = { + RetryBackOff = { + BaseInterval = "1s" + MaxInterval = "10s" + } + NumRetries = -1 + } + } + Configuration = "" + EnvironmentVariables = { + HostEnvKeys = [ + <"keys"> + ] + KeyValues = { + [ + <"key = value"> + ] + } + } + Configuration = "" + CapabilityRestrictionConfiguration = { + AllowedCapabilities = { + "fd_read" = {} + "fd_seek" = {} + "environ_get" = {} + "clock_get_time" = {} + } + } +} +``` + +## Specification + +This section provides details about the fields you can configure for the `wasm` extension. + +### `Protocol` + +Specifies the type of Wasm filter to apply. You can set either `tcp` or `http`. Set the `Protocol` to the protocol that the Wasm plugin implements when loaded by the filter. For Consul to apply the filter, the protocol must match the service's protocol. + +#### Values + +- Default: None +- This field is required. +- Data type is one of the following string values: + - `tcp` + - `http` + +### `ListenerType` + +Specifies the type of listener the extension applies to. The listener type is either `inbound` or `outbound`. If the listener type is set to `inbound`, Consul applies the extension so the Wasm plugin is run when other services in the mesh send messages to the service attached to the proxy. If the listener type is set to `outbound`, Consul applies the extension so the Wasm plugin is run when the attached proxy sends messages to other services in the mesh. + +#### Values + +- Default: None +- This field is required. +- Data type is one of the following string values: + - `inbound` + - `outbound` + +### `ProxyType` + +Specifies the type of Envoy proxy that the extension applies to. The only supported value is `connect-proxy`. + +#### Values + +- Default: `connect-proxy` +- This field is required. +- Data type: String + +### `PluginConfig{}` + +Map containing the following configuration parameters for your Wasm plugin: + +- [`Name`](#pluginconfig-name) +- [`RootID`](#pluginconfig-rootid) +- [`VmConfig`](#pluginconfig-vmconfig) +- [`Configuration`](#pluginconfig-configuration) +- [`CapabilitiesRestrictionConfiguration`](#pluginconfig-capabilitiesrestrictionconfiguration) + +#### Values + +- Default: None +- This field is required. +- Data type: Map + +### `PluginConfig{}.Name` + +Specifies a unique name for a filter in a VM. Envoy uses the name to identify specific filters if multiple filters are processed on a VM with the same `VmID` and `RootID`. The name also appears in logs for debugging purposes. + +#### Values + +- Default: None +- Data type: String + +### `PluginConfig{}.RootID` + +Specifies a unique ID for a set of filters in a VM that share a `RootContext` and `Contexts`, such as a Wasm `HttpFilter` and a Wasm `AccessLog`, if applicable. All filters with the same `RootID` and `VmID` share `Context`s. + +#### Values + +- Default: None +- Data type: String + +### `PluginConfig{}.VmConfig{}` + +Map containing the following configuration parameters for the VM that runs your Wasm plugin: + +- [`VmID`](#pluginconfig-vmconfig-vmid) +- [`Runtime`](#pluginconfig-vmconfig-runtime) +- [`Code`](#pluginconfig-vmconfig-code) +- [`Configuration`](#pluginconfig-vmconfig-configuration) +- [`EnvironmentVariables`](#pluginconfig-vmconfig-environmentvariables) + +#### Values + +- Default: None +- Data type: Map + +### `PluginConfig{}.VmConfig{}.VmID` + +Specifies an ID that Envoy uses with a hash of the Wasm code to determine which VM runs the plugin. All plugins with the same `VmID` and `Code` use the same VM. If unspecified, all plugins with the same code run in the same VM. Sharing a VM between plugins may have security implications, but can reduce memory utilization and can make data sharing easier. + +#### Values + +- Default: None +- Data type: String + +### `PluginConfig{}.VmConfig{}.Runtime` + +Specifies the type of Wasm runtime. +#### Values + +- Default: `v8` +- Data type is one of the following string values: + - `v8` + - `wastime` + - `wamr` + - `wavm` + +### `PluginConfig{}.VmConfig{}.Code{}` + +Map containing one of the following configuration parameters: + +- [`Local`](#pluginconfig-vmconfig-code-local) +- [`Remote`](#pluginconfig-vmconfig-code-local) + +You can configure either `Local` or `Remote`, but not both. The `Code` block instructs Consul how to find the Wasm plugin code for Envoy to execute. + +#### Values + +- Default: None +- This field is required. +- Data type is a map containing one of the following configurations: + - [`Local`](#pluginconfig-vmconfig-code-local) + - [`Remote`](#pluginconfig-vmconfig-code-local) + +### `PluginConfig{}.VmConfig{}.Code{}.Local{}` + +Instructs Envoy to load the plugin code from a local volume. Do not configure the `Local` parameter if the plugin code is on a remote server. + +The `Local` field is a map that contains a `Filename` parameter. The `Filename` parameter takes a string value that specifies the path to the plugin on the local file system. + +Local plug-ins are not supported in Kubernetes-orchestrated environments. + +#### Values + +- Default: None +- Data type is a map containing the `Filename` parameter. The `Filename` parameter takes a string value that specifies the path to the plugin on the local file system. + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}` + +Instructs Envoy to load the plugin code from a remote server. Do not configure the `Remote` parameter if the plugin code is on the local VM. + +The `Remote` field is a map containing the following parameters: + +- [`HttpURI`](#pluginconfig-vmconfig-code-remote-httpuri) +- [`SHA256`](#pluginconfig-vmconfig-code-remote-sha256) +- [`RetryPolicy`](#pluginconfig-vmconfig-code-remote-retrypolicy) + +#### Values + +- Default: None +- Data type: Map + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}` + +Specifies the configuration for fetching the remote data. The `HttpURI` field is a map containing the following parameters: + +- [`Service`](#pluginconfig-vmconfig-code-remote-httpuri-service) +- [`URI`](#pluginconfig-vmconfig-code-remote-httpuri-uri) +- [`Timeout`](#pluginconfig-vmconfig-code-remote-httpuri-uri) + +#### Values + +- Default: None +- Data type: Map + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}.Service` + +Specifies the upstream service to fetch the remote plugin from. + +#### Values + +- Default: None +- Data type: Map + +The following table describes the fields you can specify in the `Service` map: + +| Parameter | Description | Data type | Default | +| --- | --- | --- | --- | +| `Name` | Specifies the name of the upstream service. | String | None | +| `Namespace` | Specifies the Consul namespace that the upstream service belongs to. | String | `default` | +| `Partition` | Specifies the Consul admin partition that the upstream service belongs to. | String | `default` | + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}.URI` + +Specifies the URI Envoy uses to fetch the plugin file from the upstream. This field is required for Envoy to retrieve plugin code from a remote location. You must specify the fully-qualified domain name (FDQN) of the remote URI, which includes the protocol, host, and path. + +#### Values + +- Default: None +- This field is required. +- Data type: String value that specifies a FDQN + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.HttpURI{}.Timeout` + +Specifies the maximum duration that a response can take to complete the request for the plugin data. + +#### Values + +- Default: `1s` +- Data type: String + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.SHA256` + +Specifies the required SHA256 string for verifying the remote data. + +#### Values + +- Default: None +- This field is required. +- Data type: String + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.RetryPolicy{}` + +Defines a policy for retrying requests to the upstream service when fetching the plugin data. The `RetryPolicy` field is a map containing the following parameters: + +- [`RetryBackoff`](#pluginconfig-vmconfig-code-remote-retrypolicy) +- [`NumRetries`](#pluginconfig-vmconfig-code-remote-numretries) + +#### Values + +- Default: None +- Data type: Map +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.RetryPolicy{}.RetryBackOff{}` + +Specifies parameters that control retry backoff strategy. + +#### Values + +- Default: None +- Data type: Map + +The following table describes the fields you can specify in the `RetryBackOff` map: + +| Parameter | Description | Data type | Default | +| --- | --- | --- | --- | +| `BaseInterval` | Specifies the base interval for determining the next backoff computation. Set a value greater than `0` and less than or equal to the `MaxInterval` value. | String | `1s` | +| `MaxInterval` | Specifies the maximum interval between retries. Set the value greater than or equal to the `BaseInterval` value. | String | `10s` | + +### `PluginConfig{}.VmConfig{}.Code{}.Remote{}.RetryPolicy{}.NumRetries` + +Specifies the number of times Envoy retries to fetch plugin data if the initial attempt is unsuccessful. + +#### Values + +- Default: `1` +- Data type: Integer + +### `PluginConfig{}.VmConfig{}.Configuration` + +Specifies the configuration Envoy encodes as bytes and passes to the plugin during VM startup. Refer to [`proxy_on_vm_start` in the Proxy Wasm ABI documentation](https://github.com/proxy-wasm/spec/tree/cefc2cbab70eaba2c187523dff0b38fce2f90771/abi-versions/vNEXT#proxy_on_vm_start) for additional information. + +#### Values + +- Default: None +- This field is required. +- Data type: String + +### `PluginConfig{}.VmConfig{}.EnvironmentVariables{}` + +Specifies environment variables for Enovy to inject into this VM so that they are available through WASI's `environ_get` and `environ_get_sizes` system calls. + +In most cases, WASI calls the functions implicitly in your language's standard library. As a result, you do not need to call them directly. You can also access environment variables as you would on native platforms. + +Envoy rejects the configuration if there is a key space conflict. + +The `EnvironmentVariables` field is a map containing parameters for setting the keys and values. + +#### Values + +- Default: None +- Data type: Map + +The following table describes the parameters contained in the `EnvironmentVariables` map: + +| Parameter | Description | Data type | Default | +| --- | --- | --- | --- | +| `HostEnvKeys` | Specifies a list of Envoy environment variable keys to expose to the VM. If a key exists in Envoy's environment variables, then the key-value pair is injected. Envoy ignores `HostEnvKeys` that do not exist in its environment variables. | List | None | +| `KeyValues` | Specifies a map of explicit key-value pairs to inject into the VM. | Map of string keys and values | None | + +### `PluginConfig{}.Configuration` + +Specifies the configuration Consul encodes as bytes and passes to the plugin during plugin startup. Refer to [`proxy_on_configure` in the Envoy documentation](https://github.com/proxy-wasm/spec/tree/cefc2cbab70eaba2c187523dff0b38fce2f90771/abi-versions/vNEXT#proxy_on_configure) for additional information. + +#### Values + +- Default: None +- Data type: String + +### `PluginConfig{}.CapabilityRestrictionConfiguration{}` + +Specifies a configuration for restricting the proxy-Wasm capabilities that are available to the module. + +The `CapabilityRestrictionConfiguration` field is a map that contains a `AllowedCapabilities` parameter. The `AllowedCapabilities` parameter takes a map of string values that correspond to Envoy capability names. Refer to the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/wasm/v3/wasm.proto#extensions-wasm-v3-capabilityrestrictionconfig) for additional information. + +!> **Security warning**: Consul ignores the value that each capability maps to. You can leave the `AllowedCapabilities` empty to allow all capabilities, but doing so gives the configured plugin full unrestricted access to the runtime API provided by the Wasm VM. You must set this to a non-empty map if you want to restrict access to specific capabilities provided by the Wasm runtime API. + +#### Values + +- Default: `""` +- Data type is a map containing the `AllowedCapabilities` parameter. The `AllowedCapabilities` parameter takes a map of string values that correspond to Envoy capability names. Refer to the [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/wasm/v3/wasm.proto#extensions-wasm-v3-capabilityrestrictionconfig) for additional information. + +## Examples + +The following examples demonstrate patterns that you may be able to model your configurations on. + +### Run a Wasm plugin from a local file + +In the following example, Consul figures the Envoy proxy for the `db` service with an inbound TCP Wasm filter that uses the plugin code from the local `/consul/extensions/sqli.wasm` file. + +```hcl + +Kind = "service-defaults" +Name = "db" +Protocol = "tcp" +EnvoyExtensions = [ + { + Name = "builtin/wasm" + Required = true + Arguments = { + Protocol = "tcp" + ListenerType = “inbound” + PluginConfig = { + VmConfig = { + Code = { + Local = { + Filename = "file:///consul/extensions/sqli.wasm" + } + } + } + Configuration = < **Security warning**: We recommend that you disable permissive mTLS mode after onboarding services to prevent non-mTLS connections to the service. Intentions are not enforced and encryption is not enabled for non-mTLS connections. + +## Workflow + +The workflow to configure mTLS settings depends on the applications you are onboarding and the order you intend to onboard them, but the following steps describe the general workflow: + +1. **Configure global settings**: Configure the mesh to allow services to send non-mTLS messages to services outside the mesh. Additionally, configure the mesh to let services in the mesh use permissive mTLS mode. +1. **Enable permissive mTLS mode**: If you are onboarding an upstream service prior to its related downstream services, then enable permissive mTLS mode in the service defaults configuration entry. This allows the upstream service to send encrypted messages from the mesh when you register the service with Consul. +1. **Configure intentions**: Intentions are controls that authorize traffic between services in the mesh. Transparent proxy uses intentions to infer traffic routes between Envoy proxies. Consul does not enforce intentions for non-mTLS connections made while proxies are in permissive mTLS mode, but intentions are necessary for completing the onboarding process. +1. **Register the service**: Create the service definition and configure and deploy its sidecar proxy. +1. **Re-secure the mesh**: If you enabled permissive mTLS mode, switch back to strict mTLS mode and revert the global settings to disable non-mTLS traffic in the service mesh. + +## Requirements + +Permissive mTLS is only supported for services running in transparent proxy mode. Transparent proxy mode is only available on Kubernetes deployments. + +## Configure global settings + +Configure Consul to allow services that are already in the mesh to send non-mTLS messages to services outside the mesh. You can also Consul to allow services to run in permissive mTLS mode. Set both configurations in the mesh gateway configuration entry, which is the global configuration that defines service mesh proxy behavior. + +### Allow outgoing non-mTLS traffic + +You can configure a global setting that allows services in the mesh to send non-mTLS messages to services outside the mesh. + +Add the `MeshDestinationsOnly` property to the mesh configuration entry and set the property to `false`. If the services belong to multiple admin partitions, you must apply the setting in each partition: + + + +```hcl +Kind = "mesh" + +TransparentProxy { + MeshDestinationsOnly = false +} +``` + +```yaml +apiVersion: consul.hashicorp.com/v1alpha1 +kind: Mesh +metadata: + name: mesh +spec: + allowEnablingPermissiveMutualTLS: true +``` + +```json +{ + "Kind": "mesh", + "TransparentProxy": [ + { + "MeshDestinationsOnly": false + } + ] +} +``` + + + +Alternatively, you can selectively allow outgoing traffic on a per-service basis by configuring [outbound port exclusions](/consul/docs/k8s/connect/transparent-proxy/enable-transparent-proxy#exclude-outbound-ports). This setting excludes outgoing traffic from traffic redirection imposed by transparent proxy. When changing this setting, you must redeploy your application. + +### Allow permissive mTLS modes for incoming traffic + +Set the `AllowEnablingPermissiveMutualTLS` parameter in the mesh configuration entry to `true` so that services in the mesh _are able_ to use permissive mTLS mode for incoming traffic. The parameter does not direct services to use permissive mTLS. It is a global parameter that allows services to run in permissive mTLS mode. + + + +```hcl +Kind = "mesh" + +AllowEnablingPermissiveMutualTLS = true +TransparentProxy { + MeshDestinationsOnly = false +} +``` + +```yaml +apiVersion: consul.hashicorp.com/v1alpha1 +kind: Mesh +metadata: + name: mesh +spec: + allowEnablingPermissiveMutualTLS: true + transparentProxy: + meshDestinationsOnly: false +``` + + +```json +{ + "Kind": "mesh", + "AllowEnablingPermissiveMutualTLS": true, + "TransparentProxy": [ + { + "MeshDestinationsOnly": false + } + ] +} +``` + + + +You can change this setting back to `false` at any time, even if there are services currently running in permissive mode. Doing so allows you to decide at which point during the onboarding process to stop allowing services to use permissive mTLS. When the `MeshDestinationOnly` is set to `false`, you must configure all new services added to the mesh with `MutualTLSMode=strict` for the Consul to securely route traffic throughout the mesh. + +## Enable permissive mTLS mode + +Depending on the services you are onboarding, you may not need to enable permissive mTLS mode. If the service does not accept incoming traffic or accepts traffic from downstream services that are already part of the service mesh, then permissive mTLS mode is not required to continue. + +To enable permissive mTLS mode for the service, set [`MutualTLSMode=permissive`](/consul/docs/connect/config-entries/service-defaults#mutualtlsmode) in the service defaults configuration entry for the service. The following example shows how to configure this setting for a service named `example-service`. + + + +```hcl +Kind = "service-defaults" +Name = "example-service" + +MutualTLSMode = "permissive" +``` + +```yaml +apiVersion: consul.hashicorp.com/v1alpha1 +kind: ServiceDefaults +metadata: + name: example-service +spec: + mutualTLSMode: "permissive" +``` + +```json +{ + "Kind": "service-defaults", + "Name": "example-service", + "MutualTLSMode": "permissive" +} +``` + + + +Refer to the [service defaults configuration reference](/consul/docs/connect/config-entries/service-defaults) for information about all settings. + +You can change this setting back to `strict` at any time to ensure mTLS is required for incoming traffic to this service. + +## Configure intentions + +Service intentions are mechanisms in Consul that control traffic between services in the mesh. + +We recommend creating intentions that restrict services to accepting only necessary traffic. You must identify the downstream services that send messages to the service you want to add to the mesh and then create an intention to allow traffic to the service from its downstreams. + +When transparent proxy enabled and the `MutualTLSMode` parameter is set to `permissive`, incoming traffic from a downstream service to another upstream service is not secured by mTLS unless that upstream relationship is known to Consul. You must either define an intention so that Consul can infer the upstream relationship from the intention, or you must include an explicit upstream as part of the service definition for the downstream. + +Refer to [Service intentions](/consul/docs/connect/intentions) for additional information about how intentions work and how to create them. + +## Add the service to the mesh + +Register your service into the catalog and update your application to deploy a sidecar proxy. You should also monitor your service to verify its configuration. Refer to the [Consul on Kubernetes service mesh overview](/consul/docs/k8s/connect) for additional information. + +## Re-secure mesh traffic + +If the newly added service was placed in permissive mTLS mode for onboarding, then you should switch to strict mode when it is safe to do so. You should also revert the global settings that allow services to send and receive non-mTLS traffic. + +### Disable permissive mTLS mode + +Configure the service to operate in strict mTLS mode after the service is no longer receiving incoming non-mTLS traffic. After the downstream services that send messages to this service are all onboarded to the mesh, this service should no longer receive non-mTLS traffic. + +Check the following Envoy listener statistics for the sidecar proxy to determine if the sidecar is receiving non-mTLS traffic: + +- The `tcp.permissive_public_listener.*` statistics indicate non-mTLS traffic. If these metrics are static over a sufficient period of time, that indicates the sidecar is not receiving non-mTLS traffic. +- The `tcp.public_listener.*` statistics indicate mTLS traffic. If incoming traffic is expected to this service and these statistics are changing, then the sidecar is receiving mTLS traffic. + +Refer to the [service mesh observability overview](/consul/docs/connect/observability) and [metrics configuration for Consul on Kubernetes documentation](/consul/docs/k8s/connect/observability/metrics) for additional information. + +If your service is still receiving non-mTLS traffic, complete the following steps to determine the source of the non-mTLS traffic: + +1. Verify the list of downstream services. Optionally, you can enable [Envoy access logging](/consul/docs/connect/observability/access-logs) to determine source IP addresses for incoming traffic, and cross-reference those IP addresses with services in your network. +1. Verify that each downstream is onboarded to the service mesh. If a downstream is not onboarded, consider onboarding it next. +1. Verify that each downstream has an intention that allows it to send traffic to the upstream service. + +After you determine it is safe to move the service to strict mode, set `MutualTLSMode=strict` in the service defaults configuration entry. + + + +```hcl +Kind = "service-defaults" +Name = "example-service" + +MutualTLSMode = "strict" +``` + +```yaml +apiVersion: consul.hashicorp.com/v1alpha1 +kind: ServiceDefaults +metadata: + name: example-service +spec: + mutualTLSMode: "strict" +``` + +```json +{ + "Kind": "service-defaults", + "MutualTLSMode": "strict", + "Name": "example-service" +} +``` + + + +### Disable non-mTLS traffic + +After all services are onboarded, revert the global settings that allow non-mTLS traffic and verify that permissive mTLS mode is not being used in the mesh. + +Set `AllowEnablingPermissiveMutualTLS=false` and `MeshDestinationsOnly=true` in the mesh config entry. + + + +```hcl +Kind = “mesh” + +AllowEnablingPermissiveMutualTLS = false +TransparentProxy { + MeshDestinationsOnly = true +} +``` + +```yaml +apiVersion: consul.hashicorp.com/v1alpha1 +kind: Mesh +metadata: + name: mesh +spec: + allowEnablingPermissiveMutualTLS: false + transparentProxy: + meshDestinationsOnly: true +``` + + +```json +{ + "Kind": "mesh", + "AllowEnablingPermissiveMutualTLS": false, + "TransparentProxy": [ + { + "MeshDestinationsOnly": true + } + ] +} +``` + + + +For each namespace, admin partition, and datacenter in your Consul deployment, run the `consul config list` and `consul config read` commands to verify that no services are using `permissive` mTLS mode. + +The following command returns any service defaults configuration entries that contain `'MutualTLSMode = "permissive"'`: + +```shell-session +$ consul config list -kind service-defaults -filter 'MutualTLSMode == "permissive"' +``` + + In each admin partition and datacenter, verify that `MutualTLSMode = "permissive"` is not set in the proxy defaults configuration entry . If `MutualTLSMode` is either empty or if the configuration entry is not found, then the mode is `strict` by default. + + The following command fetches the proxy defaults configuration entry: + +```shell-session +$ consul config read -kind proxy-defaults -name global +{ + "Kind": "proxy-defaults", + "Name": "global", + "Partition": "default", + "Namespace": "default", + "TransparentProxy": {}, + "MutualTLSMode": "", + "MeshGateway": {}, + "Expose": {}, + "AccessLogs": {}, + "CreateIndex": 26, + "ModifyIndex": 30 +} +``` \ No newline at end of file diff --git a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx index 6486630daed..cfa2bb4fee5 100644 --- a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx +++ b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx @@ -258,7 +258,7 @@ You'll need: } } ``` -1. If ACLs are enabled you'll also need to modify the [anonymous token](/consul/docs/security/acl/acl-tokens#anonymous-token) policy to have the following permissions: +1. If ACLs are enabled you must also modify the [anonymous token](/consul/docs/security/acl/tokens#anonymous-token) policy to have the following permissions: ```hcl node_prefix "" { diff --git a/website/content/docs/release-notes/consul/v1_11_x.mdx b/website/content/docs/release-notes/consul/v1_11_x.mdx index 3334c6fbde7..df29f300275 100644 --- a/website/content/docs/release-notes/consul/v1_11_x.mdx +++ b/website/content/docs/release-notes/consul/v1_11_x.mdx @@ -23,7 +23,7 @@ description: >- - The legacy ACL system that was deprecated in Consul 1.4.0 has been removed. Before upgrading you should verify that all tokens and policies have been migrated to the newer ACL system. Complete the [Migrate Legacy ACL Tokens](/consul/tutorials/security-operations/access-control-token-migration) tutorial to learn more. -- The `agent_master` ACL token has been renamed to `agent_recovery` ACL token. In addition, the `consul acl set-agent-token master` command has been replaced with `consul acl set-agent-token recovery`. See [ACL Agent Recovery Token](/consul/docs/security/acl/acl-tokens#acl-agent-recovery-token) and [Consul ACL Set Agent Token](/consul/commands/acl/set-agent-token) for more information. +- The `agent_master` ACL token has been renamed to `agent_recovery` ACL token. In addition, the `consul acl set-agent-token master` command has been replaced with `consul acl set-agent-token recovery`. Refer to [ACL Agent Recovery Token](/consul/docs/security/acl/tokens#acl-agent-recovery-token) and [Consul ACL Set Agent Token](/consul/commands/acl/set-agent-token) for more information. - Drops support for Envoy versions 1.15.x and 1.16.x diff --git a/website/content/docs/release-notes/consul/v1_12_x.mdx b/website/content/docs/release-notes/consul/v1_12_x.mdx index ebdaaed98b0..85248802b7f 100644 --- a/website/content/docs/release-notes/consul/v1_12_x.mdx +++ b/website/content/docs/release-notes/consul/v1_12_x.mdx @@ -30,7 +30,7 @@ description: >- - The `disable_compat_1.9` option now defaults to true. Metrics formatted in the style of version 1.9, such as `consul.http...`, can still be enabled by setting disable_compat_1.9 = false. However, these metrics will be removed in 1.13. -- The `agent_master` ACL token has been renamed to `agent_recovery` ACL token. In addition, the `consul acl set-agent-token master` command has been replaced with `consul acl set-agent-token recovery`. Refer to [ACL Agent Recovery Token](/consul/docs/security/acl/acl-tokens#acl-agent-recovery-token) and [Consul ACL Set Agent Token](/consul/commands/acl/set-agent-token) for more information. +- The `agent_master` ACL token has been renamed to `agent_recovery` ACL token. In addition, the `consul acl set-agent-token master` command has been replaced with `consul acl set-agent-token recovery`. Refer to [ACL Agent Recovery Token](/consul/docs/security/acl/tokens#acl-agent-recovery-token) and [Consul ACL Set Agent Token](/consul/commands/acl/set-agent-token) for more information. - If TLS min versions and max versions are not specified, the TLS min/max versions default to the following values. For details on how to configure TLS min and max, refer to the [Mesh TLS config entry](/consul/docs/connect/config-entries/mesh#tls) or CRD documentation. - Incoming connections: TLS 1.2 for min0 version, TLS 1.3 for max version diff --git a/website/content/docs/security/acl/acl-federated-datacenters.mdx b/website/content/docs/security/acl/acl-federated-datacenters.mdx index 390b5c75719..cdb8a3aaee0 100644 --- a/website/content/docs/security/acl/acl-federated-datacenters.mdx +++ b/website/content/docs/security/acl/acl-federated-datacenters.mdx @@ -180,7 +180,7 @@ $ consul join -token="ACL_MANAGEMENT_TOKEN" -wan [server 1, server 2, ...] ## Configure Clients in Secondary Datacenters -When ACLs are enabled, client agents need a special token known as the [`agent token`](/consul/docs/security/acl/acl-tokens#acl-agent-token) to perform internal operations. Agent tokens need to have the right policies for node related actions, including +When ACLs are enabled, client agents need a special token known as the [`agent token`](/consul/docs/security/acl/tokens#acl-agent-token) to perform internal operations. Agent tokens need to have the right policies for node related actions, including registering itself in the catalog, updating node level health checks, and performing [anti-entropy](/consul/docs/architecture/anti-entropy) syncing. ### Generate Agent ACL Token diff --git a/website/content/docs/security/acl/acl-policies.mdx b/website/content/docs/security/acl/acl-policies.mdx index e1583f250a2..ab21b8c8929 100644 --- a/website/content/docs/security/acl/acl-policies.mdx +++ b/website/content/docs/security/acl/acl-policies.mdx @@ -11,7 +11,7 @@ This topic describes policies, which are components in Consul's access control l ## Introduction -A policy is a group of one or more ACL rules that are linked to [ACL tokens](/consul/docs/security/acl/acl-tokens). The following diagram describes the relationships between rules, policies, and tokens: +A policy is a group of one or more ACL rules that are linked to [ACL tokens](/consul/docs/security/acl/tokens). The following diagram describes the relationships between rules, policies, and tokens: ![ACL system component relationships](/img/acl-token-policy-rule-relationship.png) @@ -326,7 +326,7 @@ A policy that has been implemented must still be linked to a token before the po The person responsible for administrating ACLs can use the command line or call the API endpoint to link policies to tokens. Tokens can also be generated dynamically from an external system using Consul's [auth methods](/consul/docs/security/acl/auth-methods) functionality. -Refer to the [tokens documentation](/consul/docs/security/acl/acl-tokens), as well as the [ACL tutorial](/consul/tutorials/security/access-control-setup-production#create-the-agent-token), for details about creating and linking policies to tokens. +Refer to the [tokens documentation](/consul/docs/security/acl/tokens), as well as the [ACL tutorial](/consul/tutorials/security/access-control-setup-production#create-the-agent-token), for details about creating and linking policies to tokens. ## Policy Attributes diff --git a/website/content/docs/security/acl/index.mdx b/website/content/docs/security/acl/index.mdx index a577bd01147..4ee0d187435 100644 --- a/website/content/docs/security/acl/index.mdx +++ b/website/content/docs/security/acl/index.mdx @@ -41,7 +41,7 @@ ACL tokens are the core method of authentication in Consul. Tokens contain sever Refer to the following topics for details about tokens: -- [Tokens](/consul/docs/security/acl/acl-tokens) +- [Tokens](/consul/docs/security/acl/tokens) - [ACL token command line](/consul/commands/acl/token) - [ACL tokens API](/consul/api-docs/acl/tokens) diff --git a/website/content/docs/services/discovery/dns-static-lookups.mdx b/website/content/docs/services/discovery/dns-static-lookups.mdx index 353f4e2628e..a279373460f 100644 --- a/website/content/docs/services/discovery/dns-static-lookups.mdx +++ b/website/content/docs/services/discovery/dns-static-lookups.mdx @@ -18,7 +18,7 @@ All versions of Consul support DNS lookup features. If ACLs are enabled, you must present a token linked with the necessary policies. We recommend using a separate token in production deployments for querying the DNS. By default, Consul agents resolve DNS requests using the preconfigured tokens in order of precedence: The agent's [`default` token](/consul/docs/agent/config/config-files#acl_tokens_default) -The built-in [`anonymous` token](/consul/docs/security/acl/acl-tokens#built-in-tokens). +The built-in [`anonymous` token](/consul/docs/security/acl/tokens#built-in-tokens). The following table describes the available DNS lookups and required policies when ACLs are enabled: diff --git a/website/content/docs/upgrading/upgrade-specific.mdx b/website/content/docs/upgrading/upgrade-specific.mdx index 79b0285d63c..cd881e957d7 100644 --- a/website/content/docs/upgrading/upgrade-specific.mdx +++ b/website/content/docs/upgrading/upgrade-specific.mdx @@ -759,9 +759,9 @@ Starting with Consul 1.7.1 this is the new default. #### Removal of Deprecated Features -Managed proxies (which have been [deprecated](/consul/docs/connect/proxies/managed-deprecated) -since Consul 1.3.0) have now been [removed](/consul/docs/connect/proxies). Before -upgrading, you will need to migrate any managed proxy usage to [sidecar service +Managed proxies, which are deprecated since Consul v1.3.0, have now been +[removed](/consul/docs/connect/proxies). Before upgrading, you must +migrate any managed proxy usage to [sidecar service registrations](/consul/docs/connect/registration/sidecar-service). ## Consul 1.4.0