Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention create -replace`](/consul/commands/intention/create#replace).
@@ -149,16 +140,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------------------------ |
-| `NO` | `none` | `none` | `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention create`](/consul/commands/intention/create).
@@ -246,16 +228,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------------------------ |
-| `NO` | `none` | `none` | `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
This endpoint supports the same parameters as the [create an intention](#create-intention-with-id) endpoint.
Additional parameters unique to this endpoint include:
@@ -300,16 +273,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ----------------------------- |
-| `YES` | `all` | `none` | `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention get`](/consul/commands/intention/get).
@@ -372,16 +336,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ----------------------------- |
-| `YES` | `all` | `none` | `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention get`](/consul/commands/intention/get).
@@ -435,16 +390,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ----------------------------- |
-| `YES` | `all` | `none` | `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention list`](/consul/commands/intention/list).
@@ -522,16 +468,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------------------------ |
-| `NO` | `none` | `none` | `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention delete`](/consul/commands/intention/delete).
@@ -577,16 +514,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ------------------------------ |
-| `NO` | `none` | `none` | `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention delete`](/consul/commands/intention/delete).
@@ -633,16 +561,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | ------------- | ----------------------------- |
-| `NO` | `none` | `none` | `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention check`](/consul/commands/intention/check).
@@ -693,16 +612,7 @@ The table below shows this endpoint's support for
| Blocking Queries | Consistency Modes | Agent Caching | ACL Required |
| ---------------- | ----------------- | -------------------- | ----------------------------- |
-| `YES` | `all` | `background refresh` | `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
The corresponding CLI command is [`consul intention match`](/consul/commands/intention/match).
diff --git a/website/content/commands/connect/envoy.mdx b/website/content/commands/connect/envoy.mdx
index c35a0b4feaa8..c9e0ffb2e932 100644
--- a/website/content/commands/connect/envoy.mdx
+++ b/website/content/commands/connect/envoy.mdx
@@ -56,7 +56,7 @@ Usage: `consul connect envoy [options] [-- pass-through options]`
ACL token from `-token` or the environment and so should be handled as a secret.
This token grants the identity of any service it has `service:write` permission
for and so can be used to access any upstream service that that service is
- allowed to access by [Connect intentions](/consul/docs/connect/intentions).
+ allowed to access by [service mesh intentions](/consul/docs/connect/intentions).
- `-envoy-version` - The version of envoy that is being started. Default is
`1.23.1`. This is required so that the correct configuration can be generated.
diff --git a/website/content/commands/connect/index.mdx b/website/content/commands/connect/index.mdx
index 166b8ff83526..b390f1899354 100644
--- a/website/content/commands/connect/index.mdx
+++ b/website/content/commands/connect/index.mdx
@@ -10,7 +10,7 @@ description: >-
Command: `consul connect`
The `connect` command is used to interact with Consul
-[Connect](/consul/docs/connect/intentions) subsystems. It exposes commands for
+[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.
diff --git a/website/content/commands/intention/check.mdx b/website/content/commands/intention/check.mdx
index d9a4d5d328c3..fadc8d224bd9 100644
--- a/website/content/commands/intention/check.mdx
+++ b/website/content/commands/intention/check.mdx
@@ -31,16 +31,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ----------------------------- |
-| `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
## Usage
diff --git a/website/content/commands/intention/create.mdx b/website/content/commands/intention/create.mdx
index 31f2ae899a9b..71c491b06ad8 100644
--- a/website/content/commands/intention/create.mdx
+++ b/website/content/commands/intention/create.mdx
@@ -25,16 +25,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ------------------------------ |
-| `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
## Usage
diff --git a/website/content/commands/intention/delete.mdx b/website/content/commands/intention/delete.mdx
index 87d9d65e9051..ad2fca1c97e2 100644
--- a/website/content/commands/intention/delete.mdx
+++ b/website/content/commands/intention/delete.mdx
@@ -19,16 +19,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ------------------------------ |
-| `intentions:write`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
-> **Deprecated** - The one argument form of this command is deprecated in
Consul 1.9.0. Intentions no longer need IDs when represented as
diff --git a/website/content/commands/intention/get.mdx b/website/content/commands/intention/get.mdx
index 68dd744404f6..84b3a86065d0 100644
--- a/website/content/commands/intention/get.mdx
+++ b/website/content/commands/intention/get.mdx
@@ -24,16 +24,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ----------------------------- |
-| `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
## Usage
diff --git a/website/content/commands/intention/index.mdx b/website/content/commands/intention/index.mdx
index 9246ef9e0508..d3e4fc56c431 100644
--- a/website/content/commands/intention/index.mdx
+++ b/website/content/commands/intention/index.mdx
@@ -14,10 +14,9 @@ The `intention` command is used to interact with Connect
creating, updating, reading, deleting, checking, and managing intentions.
This command is available in Consul 1.2 and later.
-Intentions are managed primarily via
-[`service-intentions`](/consul/docs/connect/config-entries/service-intentions) config
-entries after Consul 1.9. Intentions may also be managed via the [HTTP
-API](/consul/api-docs/connect/intentions).
+Use the
+[`service-intentions`](/consul/docs/connect/config-entries/service-intentions) configuration entry or the [HTTP
+API](/consul/api-docs/connect/intentions) to manage intentions.
~> **Deprecated** - This command is deprecated in Consul 1.9.0 in favor of
using the [config entry CLI command](/consul/commands/config/write). To create an
diff --git a/website/content/commands/intention/list.mdx b/website/content/commands/intention/list.mdx
index 928f416095d8..85a7d6b9d6ce 100644
--- a/website/content/commands/intention/list.mdx
+++ b/website/content/commands/intention/list.mdx
@@ -19,16 +19,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ----------------------------- |
-| `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
## Usage
diff --git a/website/content/commands/intention/match.mdx b/website/content/commands/intention/match.mdx
index e0bbfc1222e5..4c727b1fc21c 100644
--- a/website/content/commands/intention/match.mdx
+++ b/website/content/commands/intention/match.mdx
@@ -24,16 +24,7 @@ are not supported from commands, but may be from the corresponding HTTP endpoint
| ACL Required |
| ----------------------------- |
-| `intentions:read`1 |
-
-
Define intention rules in the `service` policy. Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements) for additional information.
|
## Usage
diff --git a/website/content/docs/connect/config-entries/service-defaults.mdx b/website/content/docs/connect/config-entries/service-defaults.mdx
index e1e15cf7acb2..75b8497c98c2 100644
--- a/website/content/docs/connect/config-entries/service-defaults.mdx
+++ b/website/content/docs/connect/config-entries/service-defaults.mdx
@@ -459,7 +459,7 @@ Specifies the default protocol for the service. In service mesh use cases, the `
- [observability](/consul/docs/connect/observability)
- [service splitter configuration entry](/consul/docs/connect/config-entries/service-splitter)
- [service router configuration entry](/consul/docs/connect/config-entries/service-router)
-- [L7 intentions](/consul/docs/connect/intentions)
+- [L7 intentions](/consul/docs/connect/intentions/index#l7-traffic-intentions)
You can set the global protocol for proxies in the [`proxy-defaults`](/consul/docs/connect/config-entries/proxy-defaults#default-protocol) configuration entry, but the protocol specified in the `service-defaults` configuration entry overrides the `proxy-defaults` configuration.
@@ -831,7 +831,7 @@ Specifies the default protocol for the service. In service service mesh use case
- [observability](/consul/docs/connect/observability)
- [`service-splitter` configuration entry](/consul/docs/connect/config-entries/service-splitter)
- [`service-router` configuration entry](/consul/docs/connect/config-entries/service-router)
-- [L7 intentions](/consul/docs/connect/intentions)
+- [L7 intentions](/consul/docs/connect/intentions/index#l7-traffic-intentions)
You can set the global protocol for proxies in the [`ProxyDefaults` configuration entry](/consul/docs/connect/config-entries/proxy-defaults#default-protocol), but the protocol specified in the `ServiceDefaults` configuration entry overrides the `ProxyDefaults` configuration.
diff --git a/website/content/docs/connect/config-entries/service-intentions.mdx b/website/content/docs/connect/config-entries/service-intentions.mdx
index 34c948ac1efd..1eb2c42667a0 100644
--- a/website/content/docs/connect/config-entries/service-intentions.mdx
+++ b/website/content/docs/connect/config-entries/service-intentions.mdx
@@ -1,40 +1,932 @@
---
layout: docs
-page_title: Service Intentions - Configuration Entry Reference
+page_title: Service intentions configuration entry reference
description: >-
- The service intentions configuration entry kind defines the communication permissions between service types. Use the reference guide to learn about `""service-intentions""` config entry parameters and how to authorize L4 and L7 communication int he service mesh with intentions.
+ Use the service intentions configuration entry to allow or deny traffic to services in the mesh from specific sources. Learn how to configure `service-intention` config entries
---
-# Service Intentions Configuration Entry ((#service-intentions))
+# Service intentions configuration entry reference
--> **1.9.0+:** This config entry is available in Consul versions 1.9.0 and newer.
+This topic provides reference information for the service intentions configuration entry. Intentions are configurations for controlling access between services in the service mesh. A single service intentions configuration entry specifies one destination service and one or more L4 traffic sources, L7 traffic sources, or combination of traffic sources. Refer to [Service mesh intentions overview](/consul/docs/connect/intentions) for additional information.
-The `service-intentions` config entry kind (`ServiceIntentions` on Kubernetes) controls Connect traffic
-authorization for both networking layer 4 (e.g. TCP) and networking layer 7
-(e.g. HTTP).
+## Configuration model
-Service intentions config entries represent a collection of
-[intentions](/consul/docs/connect/intentions) sharing a specific destination. All
-intentions governing access to a specific destination are stored in a single
-`service-intentions` config entry.
+
-A single config entry may define a mix of both L4 and L7 style intentions, but
-for a specific source L4 and L7 intentions are mutually exclusive. Only one
-will apply at a time. Default behavior for L4 is configurable (regardless of
-global setting) by defining a low precedence intention for that destination.
+
-## Interaction with other Config Entries
+- [`Kind`](#kind): string | required | must be set to `service-intentions`
+- [`Name`](#name): string | required
+- [`Namespace`](#namespace): string | `default` |
+- [`Partition`](#partition): string | `default` |
+- [`Meta`](#meta): map | no default
+- [`Sources`](#sources): list | no default
+ - [`Name`](#sources-name): string | no default
+ - [`Peer`](#sources-peer): string | no default
+ - [`Namespace`](#sources-namespace): string | no default |
+ - [`Partition`](#sources-partition): string | no default |
+ - [`Action`](#sources-action): string | no default | required for L4 intentions
+ - [`Permissions`](#sources-permissions): list | no default
+ - [`Action`](#sources-permissions-action): string | no default | required
+ - [`HTTP`](#sources-permissions-http): map | required
+ - [`PathExact`](#sources-permissions-http): string | no default
+ - [`PathPrefix`](#sources-permissions-http): string | no default
+ - [`PathRegex`](#sources-permissions-http): string | no default
+ - [`Methods`](#sources-permissions-http): list | no default
+ - [`Header`](#sources-permissions-http-header): list of maps |no default
+ - [`Name`](#sources-permissions-http-header): string | required
+ - [`Present`](#sources-permissions-http-header): boolean | `false`
+ - [`Exact`](#sources-permissions-http-header): string | no default
+ - [`Prefix`](#sources-permissions-http-header): string | no default
+ - [`Suffix`](#sources-permissions-http-header): string | no default
+ - [`Regex`](#sources-permissions-http-header): string | no default
+ - [`Invert`](#sources-permissions-http-header): boolean | `false`
+ - [`Precedence`](#sources-precedence): number | no default | _read-only_
+ - [`Type`](#sources-type): string | `consul`
+ - [`Description`](#sources-description): string
+ - [`LegacyID`](#sources-legacyid): string | no default | _read-only_
+ - [`LegacyMeta`](#sources-legacymeta): map | no default | _read-only_
+ - [`LegacyCreateTime`](#sources-legacycreatetime): string | no default | _read-only_
+ - [`LegacyUpdateTime`](#sources-legacyupdatetime): string | no default | _read-only_
-L7 intentions within a config entry are restricted to only destination services
-that define their protocol as HTTP-based via a corresponding
-[`service-defaults`](/consul/docs/connect/config-entries/service-defaults) config entry
-or globally via [`proxy-defaults`](/consul/docs/connect/config-entries/proxy-defaults) .
+
+
-## Sample Config Entries
+- [`apiVersion`](#apiversion): string | must be set to `consul.hashicorp.com/v1alpha1`
+- [`kind`](#kind): string | must be set to `ServiceIntentions`
+- [`metadata`](#metadata): map | required
+ - [`name`](#metadata-name): string | required
+ - [`namespace`](#metadata-namespace): string | `default` |
+- [`spec`](#spec): map | no default
+ - [`destination`](#spec-destination): map | no default
+ - [`name`](#spec-destination-name): string | required
+ - [`namespace`](#metadata-namespace): string | `default` |
+ - [`sources`](#spec-sources): list | no default
+ - [`name`](#spec-sources-name): string | no default
+ - [`peer`](#spec-sources-peer): string | no default
+ - [`namespace`](#spec-sources-namespace): string | no default |
+ - [`partition`](#spec-sources-partition): string | no default |
+ - [`action`](#spec-sources-action): string | no default | required for L4 intentions
+ - [`permissions`](#spec-sources-permissions): list | no default
+ - [`action`](#spec-sources-permissions-action): string | no default | required
+ - [`http`](#spec-sources-permissions-http): map | required
+ - [`pathExact`](#spec-sources-permissions-http): string | no default
+ - [`pathPrefix`](#spec-sources-permissions-http): string | no default
+ - [`pathRegex`](#spec-sources-permissions-http): string | no default
+ - [`methods`](#spec-sources-permissions-http): list | no default
+ - [`header`](#spec-sources-permissions-http-header): list of maps |no default
+ - [`name`](#spec-sources-permissions-http-header): string | required
+ - [`present`](#spec-sources-permissions-http-header): boolean | `false`
+ - [`exact`](#spec-sources-permissions-http-header): string | no default
+ - [`prefix`](#spec-sources-permissions-http-header): string | no default
+ - [`suffix`](#spec-sources-permissions-http-header): string | no default
+ - [`regex`](#spec-sources-permissions-http-header): string | no default
+ - [`invert`](#spec-sources-permissions-http-header): boolean | `false`
+ - [`type`](#spec-sources-type): string | `consul`
+ - [`description`](#spec-sources-description): string
-The following examples demonstrate potential use-cases for the `service-intentions` configuration entry.
+
+
-### REST Access
+## Complete configuration
+
+
+
+
+
+```hcl
+Kind = "service-intentions"
+Name = ""
+Namespace = "" # string
+Partition = "" # string
+Meta = {
+ "" = ""
+ "" = ""
+ }
+Sources = [
+ {
+ Name = "" # string
+ Peer = "" # string
+ Namespace = "" # string
+ Partition = "" # string
+ Action = "allow" or "deny" # string for L4 intentions
+ Permissions = [
+ {
+ Action = "allow" or "deny" # string for L7 intenions
+ HTTP = {
+ PathExact = "" # string
+ PathPrefix = "" # string
+ PathRegex = "" # string
+ Methods = [
+ "", # string
+ ""
+ ]
+ Header = [
+ {
+ Name = "" # string
+ Present = # boolean
+ },
+ {
+ Name = "" # string
+ Exact = "" # boolean
+ },
+ {
+ Name = "" # string
+ Prefix = "" # string
+ },
+ {
+ Name = "" # string
+ Suffix = "" # string
+ },
+ {
+ Name = "" # string
+ Regex = "" # string
+ Invert = # boolean
+ }
+ ]
+ }
+ }
+ ]
+ Type = "consul" # string
+ Description = "" # string
+ Precedence = # number
+ LegacyID = # string
+ LegacyMeta = # string
+ LegacyCreateTime = # string
+ LegacyUpdateTime = # string
+ }
+]
+```
+
+
+
+
+```yaml
+apiVersion: consul.hashicorp.com/v1alpha1
+kind: service-intentions
+metadata:
+ name:
+ namespace:
+spec:
+ destination:
+ destination:
+ name:
+ namespace:
+ sources:
+ name:
+ peer:
+ namespace:
+ partition:
+ action: allow or deny
+ permissions:
+ - action: allow or deny
+ http:
+ pathExact:
+ pathPrefix:
+ pathRegex:
+ methods:
+ -
+
+ header:
+ - name:
+ present: true
+ - name:
+ exact: false
+ - name:
+ prefix:
+ - name:
+ suffix:
+ - name:
+ regex:
+ invert: false
+ type: consul
+ description:
+```
+
+
+
+
+```json
+{
+ "Kind":"service-intentions",
+ "Name":"",
+ "Namespace":"",
+ "Partition":"",
+ "Meta":{
+ "key-1":"",
+ "key-2":""
+ },
+ "Sources":[
+ {
+ "Name":"",
+ "Peer":"",
+ "Namespace":"",
+ "Partition":"",
+ "Action":"allow or deny",
+ "Permissions":[
+ {
+ "Action":"allow or deny",
+ "HTTP":{
+ "PathExact":"",
+ "PathPrefix":"",
+ "PathRegex":"",
+ "Methods":[
+ "",
+ ""
+ ],
+ "Header":[
+ {
+ "Name":"",
+ "Present":true
+ },
+ {
+ "Name":"",
+ "Exact":false
+ },
+ {
+ "Name":"",
+ "Prefix":""
+ },
+ {
+ "Name":"",
+ "Suffix":""
+ },
+ {
+ "Name":"",
+ "Regex":"",
+ "Invert":false
+ }
+ ]
+ }
+ }
+ ],
+ "Type":"consul",
+ "Description":"",
+ "Precedence":"",
+ "LegacyID":"",
+ "LegacyMeta":"",
+ "LegacyCreateTime":"",
+ "LegacyUpdateTime":""
+ }
+ ]
+}
+```
+
+
+
+
+
+## Specification
+
+This section provides details about the fields you can configure in the service defaults configuration entry.
+
+
+
+
+
+### `Kind`
+
+Specifies the type of configuration entry to implement. Must be set to `service-intentions`.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String value that must be set to `service-intentions`.
+
+### `Name`
+
+Specifies a name of the destination service for all intentions defined in the configuration entry.
+
+#### Values
+
+- Default: Defaults to the name of the node after writing the entry to the Consul server.
+- This field is required.
+- Data type: String
+
+You can also specify a wildcard character (`*`) to match all services without intentions. Intentions that are applied with a wildcard, however, are not supported when defining L7 [`Permissions`](#sources-permissions).
+
+### `Namespace`
+
+Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. Services in the namespace are the traffic destinations that the intentions allow or deny traffic to.
+
+#### Values
+
+- Default: `default`
+- Data type: String
+
+You can also specify a wildcard character (`*`) to match all namespaces. Intentions that are applied with a wildcard, however, are not supported when defining L7 [`Permissions`](#sources-permissions).
+
+### `Partition`
+
+Specifies the [admin partition](/consul/docs/enterprise/admin-partitions) to apply the configuration entry. Services in the specified partition are the traffic destinations that the intentions allow or deny traffic to.
+
+#### Values
+
+- Default: `default`
+- Data type: String
+
+### `Meta`
+
+Specifies key-value pairs to add to the KV store when the configuration entry is evaluated.
+
+#### Values
+
+- Default: None
+- Data type: Map of one or more key-value pairs
+ - keys: String
+ - values: String, integer, or float
+
+### `Sources[]`
+
+List of configurations that define intention sources and the authorization granted to the sources. You can specify source configurations in any order, but Consul stores and evaluates them in order of reverse precedence at runtime. Refer to [`Precedence`](#sources-precedence) for additional information.
+
+#### Values
+
+- Default: None
+- List of objects that contain the following fields:
+ - `Name`
+ - `Peer`
+ - `Namespace`
+ - `Partition`
+ - `Action`
+ - `Permissions`
+ - `Precedence`
+ - `Type`
+ - `Description`
+ - `LegacyID`
+ - `LegacyMeta`
+ - `LegacyCreateTime`
+ - `LegacyUpdateTime`
+
+### `Sources[].Name`
+
+Specifies the name of the source that the intention allows or denies traffic from. If [`Type`](#sources-type) is set to `consul`, then the value refers to the name of a Consul service. The source is not required to be registered into the Consul catalog.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String
+
+### `Sources[].Peer`
+
+Specifies the name of a peered Consul cluster that the intention allows or denies traffic from. Refer to [Cluster peering overview](/consul/docs/connect/cluster-peering) for additional information about peers.
+
+The `Peer` and `Partition` fields are mutually exclusive.
+
+#### Values
+
+- Default: None
+- Data type: String
+
+### `Sources[].Namespace`
+
+Specifies the traffic source namespace that the intention allows or denies traffic from.
+
+#### Values
+
+- Default: If [`Peer`](#sources-peer) is unspecified, defaults to the destination [`Namespace`](#namespace).
+- Data type: String
+
+### `Sources[].Partition`
+
+Specifies the name of an admin partition that the intention allows or denies traffic from. Refer to [Admin Partitions](/consul/docs/enterprise/admin-partitions) for additional information about partitions.
+
+The `Peer` and `Partition` fields are mutually exclusive.
+
+#### Values
+
+- Default: If [`Peer`](#sources-peer) is unspecified, defaults to the destination [`Partition`](#partition).
+- Data type: string
+
+### `Sources[].Action`
+
+Specifies the action to take when the source sends traffic to the destination service. The value is either `allow` or `deny`. Do not configure this field to apply L7 intentions to the same source. Configure the [`Permissions`](#sources-permissions) field instead.
+
+#### Values
+
+- Default: None
+- This field is required for L4 intentions.
+- Data type: String value set to either `allow` or `deny`
+
+Refer to the following examples for additional guidance:
+
+- [L4 Intentions for specific sources and destinations](#l4-intentions-for-specific-sources-and-destinations)
+- [L4 intentions for all destinations](#l4-intentions-for-all-destinations)
+- [L4 intentions for all sources](#l4-intentions-for-all-sources)
+- [L4 and L7](#l4-and-l7)
+
+### `Sources[].Permissions[]`
+
+Specifies a list of permissions for L7 traffic sources. The list contains one or more actions and a set of match criteria for each action.
+
+Consul applies permissions in the order specified in the configuration. Beginning at the top of the list, Consul applies the first matching request and stops evaluating against the remaining configurations.
+
+For requests that do not match any of the defined permissions, Consul applies the intention behavior defined in the [`acl_default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) configuration.
+
+Do not configure this field for L4 intentions. Use the [`Sources.Action`](#sources-action) parameter instead.
+
+The `Permissions` only applies to services with a compatible protocol. `Permissions` are not supported when the [`Name`](#name) or [`Namespace`](#namespace) field is configured with a wildcard because service instances or services in a namespace may use different protocols.
+
+#### Values
+
+- Default: None
+- List of objects that contain the following fields:
+ - `Action`
+ - `HTTP`
+
+Refer to the following examples for additional guidance:
+
+- [Rest access](#rest-access)
+- [gRPC](#grpc)
+- [Cluster peering](#cluster-peering)
+- [L4 and L7](#l4-and-l7)
+
+### `Sources[].Permissions[].Action`
+
+Specifies the action to take when the source sends traffic to the destination service. The value is either `allow` or `deny`.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String value set to either `allow` or `deny`.
+
+### `Sources[].Permissions[].HTTP`
+
+Specifies a set of HTTP-specific match criteria. Consul applies the action defined in the [`Action`](#sources-permissions-action) field to source traffic that matches the criteria.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: Map
+
+The following table describes the parameters that the HTTP map may contain:
+
+| Parameter | Description | Data type | Default |
+| --- | --- | --- | --- |
+| `PathExact` | Specifies an exact path to match on the HTTP request path. Do not specify `PathExact` if `PathPrefix` or `PathRegex` are configured in the same `HTTP` configuration. | string | none |
+| `PathPrefix` | Specifies a path prefix to match on the HTTP request path. Do not specify `PathPrefix` if `PathExact` or `PathRegex` are configured in the same `HTTP` configuration. | string | none |
+| `PathRegex` | Defines a regular expression to match on the HTTP request path. Do not specify `PathRegex` if `PathExact` or `PathPrefix` are configured in the same `HTTP` configuration. The regex syntax is proxy-specific. If using Envoy, refer to the [re2 documentation](https://github.com/google/re2/wiki/Syntax) for details. | string | none |
+| `Methods` | Specifies a list of HTTP methods. Consul applies the permission if a request matches the `PathExact`, `PathPrefix`, `PathRegex`, or `Header`, and the source sent the request using one of the specified methods. Refer to the [Mozilla documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) for a list of supported request headers. | list | All request methods |
+| `Header` | Specifies a header name and matching criteria for HTTP request headers. Refer to [`Sources[].Permissions[].HTTP[].Header`](#sources-permissions-http-header) for details. | list of maps | none |
+
+### `Sources[].Permissions[].HTTP[].Header[]`
+
+Specifies a header name and matching criteria for HTTP request headers. The request header must match all specified criteria for the permission to apply.
+
+#### Values
+
+- Default: None
+- Data type: list of objects
+
+Each member of the `Header` list is a map that contains a `Name` field and at least one match criterion. The following table describes the parameters that each member of the `Header` list may contain:
+
+| Parameter | Description | Data type | Required |
+| --- | --- | --- | --- |
+| `Name` | Specifies the name of the header to match. | string | required |
+| `Present` | Enables a match if the header configured in the `Name` field appears in the request. Consul matches on any value as long as the header key appears in the request. Do not specify `Present` if `Exact`, `Prefix`, `Suffix`, or `Regex` are configured in the same `Header` configuration. | boolean | optional |
+| `Exact` | Specifies a value for the header key set in the `Name` field. If the request header value matches the `Exact` value, Consul applies the permission. Do not specify `Exact` if `Present`, `Prefix`, `Suffix`, or `Regex` are configured in the same `Header` configuration. | string | optional |
+| `Prefix` | Specifies a prefix value for the header key set in the `Name` field. If the request header value starts with the `Prefix` value, Consul applies the permission. Do not specify `Prefix` if `Present`, `Exact`, `Suffix`, or `Regex` are configured in the same `Header` configuration. | string | optional |
+| `Suffix` | Specifies a suffix value for the header key set in the `Name` field. If the request header value ends with the `Suffix` value, Consul applies the permission. Do not specify `Suffix` if `Present`, `Exact`, `Prefix`, or `Regex` are configured in the same `Header` configuration. | string | optional |
+| `Regex` | Specifies a regular expression pattern as the value for the header key set in the `Name` field. If the request header value matches the regex, Consul applies the permission. Do not specify `Regex` if `Present`, `Exact`, `Prefix`, or `Suffix` are configured in the same `Header` configuration. The regex syntax is proxy-specific. If using Envoy, refer to the [re2 documentation](https://github.com/google/re2/wiki/Syntax) for details. | string | optional |
+| `Invert` | Inverts the matching logic configured in the `Header`. Default is `false`. | boolean | optional |
+
+
+### `Sources[].Precedence`
+
+The `Precedence` field contains a read-only integer. Consul generates the value based on name configurations for the source and destination services. Refer to [Precedence and matching order](/consul/docs/connect/intentions/create-manage-intentions#precedence-and-matching-order) for additional information.
+
+### `Sources[].Type`
+
+Specifies the type of destination service that the configuration entry applies to. The only value supported is `consul`.
+
+#### Values
+
+- Default: `consul`
+- Data type: String
+
+### `Sources[].Description`
+
+Specifies a description of the intention. Consul presents the description in API responses to assist other tools integrated into the network.
+
+#### Values
+
+- Default: None
+- Data type: String
+
+### `Sources[].LegacyID`
+
+Read-only unique user ID (UUID) for the intention in the system. Consul generates the value and exposes it in the configuration entry so that legacy API endpoints continue to function. Refer to [Read Specific Intention by ID](/consul/api-docs/connect/intentions#read-specific-intention-by-id) for additional information.
+
+### `Sources[].LegacyMeta`
+
+Read-only set of arbitrary key-value pairs to attach to the intention. Consul generates the metadata and exposes it in the configuration entry so that legacy intention API endpoints continue to function. Refer to [Read Specific Intention by ID](/consul/api-docs/connect/intentions#read-specific-intention-by-id) for additional information.
+
+### `Sources[].CreateTime`
+
+Read-only timestamp for the intention creation. Consul exposes the timestamp in the configuration entry to allow legacy intention API endpoints to continue functioning. Refer to [Read Specific Intention by ID](/consul/api-docs/connect/intentions#read-specific-intention-by-id) for additional information.
+
+### `Sources[].LegacyUpdateTime`
+
+Read-only timestamp marking the most recent intention update. Consul exposes the timestamp in the configuration entry to allow legacy intention API endpoints to continue functioning. Refer to [Read Specific Intention by ID](/consul/api-docs/connect/intentions#read-specific-intention-by-id) for additional information.
+
+
+
+
+
+### `apiVersion`
+
+Specifies the version of the Consul API for integrating with Kubernetes. The value must be `consul.hashicorp.com/v1alpha1`.
+
+#### Values
+
+- Default: None
+- This field is required.
+- String value that must be set to `consul.hashicorp.com/v1alpha1`.
+
+### `kind`
+
+Specifies the type of configuration entry to implement. Must be set to `ServiceIntentions`.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String value that must be set to `ServiceIntentions`.
+
+### `metadata`
+
+Map that contains an arbitrary name for the configuration entry and the namespace it applies to.
+
+#### Values
+
+- Default: None
+- Data type: Map
+
+### `metadata.name`
+
+Specifies an arbitrary name for the configuration entry. Note that in other configuration entries, the `metadata.name` field specifies the name of the service that the settings apply to. For service intentions, the service that accepts the configurations is the _destination_ and is specified in the [`spec.destination.name`](#spec-destination-name) field. Refer to the following topics for additional information:
+
+- [ServiceIntentions Special Case (OSS)](/consul/docs/k8s/crds#serviceintentions-special-case)
+- [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise)
+
+#### Values
+
+- Default: None
+- Data type: String
+
+### `metadata.namespace`
+
+Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Open source Consul distributions (Consul OSS) ignore the `metadata.namespace` configuration.
+
+#### Values
+
+- Default: `default`
+- Data type: String
+
+### `spec`
+Map that contains the details about the `ServiceIntentions` configuration entry. The `apiVersion`, `kind`, and `metadata` fields are siblings of the spec field. All other configurations are children.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: Map
+
+### `spec.destination`
+
+Map that identifies the destination name and destination namespace that source services are allowed or denied access to.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: Map
+
+### `spec.destination.name`
+
+Specifies the name of the destination service in the mesh that the intentions apply to.
+You can also specify a wildcard character (`*`) to match all services that are missing intention settings. Intentions that are applied with a wildcard, however, are not supported when defining L7 [`permissions`](#spec-sources-permissions).
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String
+
+### `spec.metadata.namespace`
+
+Specifies the [namespace](/consul/docs/enterprise/namespaces) that the configuration entry applies to. You can also specify a wildcard character (`*`) to match all namespaces. Intentions that are applied with a wildcard, however, are not supported when defining L7 [`permissions`](#spec-sources-permissions).
+
+Refer to [Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for information about how Consul namespaces map to Kubernetes Namespaces. Open source Consul distributions (Consul OSS) ignore the `metadata.namespace` configuration.
+
+#### Values
+
+- Default: If not set, destination service namespace is inherited from the `connectInject.consulNamespaces` configuration. Refer to [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise) for details.
+- Data type: String
+
+### `spec.sources[]`
+
+List of configurations that define intention sources and the authorization granted to the sources. You can specify source configurations in any order, but Consul stores and evaluates them in order of reverse precedence at runtime.
+
+#### Values
+
+- Default: None
+- List of objects that contain the following fields:
+ - `name`
+ - `peer`
+ - `namespace`
+ - `partition`
+ - `Action`
+ - `permissions`
+ - `type`
+ - `description`
+
+### `spec.sources[].name`
+
+Specifies the name of the source that the intention allows or denies traffic from. If [`type`](#sources-type) is set to `consul`, then the value refers to the name of a Consul service. The source is not required to be registered into the Consul catalog.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String
+
+### `spec.sources[].peer`
+
+Specifies the name of a peered Consul cluster that the intention allows or denies traffic from. Refer to [Cluster peering overview](/consul/docs/connect/cluster-peering) for additional information about peers. The `peer` and `partition` fields are mutually exclusive.
+#### Values
+
+- Default: None
+- Data type: String
+
+### `spec.sources[].namespace`
+
+Specifies the traffic source namespace that the intention allows or denies traffic from.
+
+#### Values
+
+- Default: If [`peer`](#spec-sources-peer) is unspecified, defaults to the namespace specified in the [`spec.destination.namespace`](#spec-destination-namespace) field.
+- Data type: String
+
+### `spec.sources[].partition`
+
+Specifies the name of an admin partition that the intention allows or denies traffic from. Refer to [Admin Partitions](/consul/docs/enterprise/admin-partitions) for additional information about partitions. The `peer` and `partition` fields are mutually exclusive.
+
+#### Values
+
+- Default: If [`peer`](#sources-peer) is unspecified, defaults to the partition specified in [`spec.destination.partition`](#spec-destination-partition).
+- Data type: String
+
+### `spec.sources[].action`
+
+Specifies the action to take when the source sends traffic to the destination service. The value is either `allow` or `deny`. Do not configure this field for L7 intentions. Configure the [`spec.sources.permissions`](#spec-sources-permissions) field instead.
+
+#### Values
+
+- Default: None
+- This field is required for L4 intentions.
+- Data type: String value set to either `allow` or `deny`
+
+### `spec.sources[].permissions[]`
+
+Specifies a list of permissions for L7 traffic sources. The list contains one or more actions and a set of match criteria for each action.
+
+Consul applies permissions in the order specified in the configuration. Starting at the beginning of the list, Consul applies the first matching request and stops evaluating against the remaining configurations.
+
+For requests that do not match any of the defined permissions, Consul applies the intention behavior defined in the [`acl_default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) configuration.
+
+Do not configure this field for L4 intentions. Use the [`spec.sources.action`](#sources-action) parameter instead.
+
+`permissions` configurations only apply to services with a compatible protocol. As a result, they are not supported when the [`spec.destination.name`](#spec-destination-name) or [`spec.destination.namespace`](#spec-destination-namespace) field is configured with a wildcard because service instances or services in a namespace may use different protocols.
+
+#### Values
+
+- Default: None
+- List of objects that contain the following fields:
+ - `action`
+ - `http`
+
+### `spec.sources[].permissions[].action`
+
+Specifies the action to take when the source sends traffic to the destination service. The value is either `allow` or `deny`.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: String value set to either `allow` or `deny`
+
+### `spec.sources[].permissions[].http`
+
+Specifies a set of HTTP-specific match criteria. Consul applies the action defined in the [`spec.sources.permissions.action`](#spec-sources-permissions-action) field to source traffic that matches the criteria.
+
+#### Values
+
+- Default: None
+- This field is required.
+- Data type: Map
+
+The following table describes the parameters that the HTTP map may contain:
+
+| Parameter | Description | Data type | Default |
+| --- | --- | --- | --- |
+| `pathExact` | Specifies an exact path to match on the HTTP request path. Do not specify `pathExact` if `pathPrefix` or `pathRegex` are configured in the same `http` configuration. | string | none |
+| `pathPrefix` | Specifies a path prefix to match on the HTTP request path. Do not specify `pathPrefix` if `pathExact` or `pathRegex` are configured in the same `http` configuration. | string | none |
+| `pathRegex` | Defines a regular expression to match on the HTTP request path. Do not specify `pathRegex` if `pathExact` or `pathPrefix` are configured in the same `http` configuration. The regex syntax is proxy-specific. If using Envoy, refer to the [re2 documentation](https://github.com/google/re2/wiki/Syntax) for details. | string | none |
+| `methods` | Specifies a list of HTTP methods. Consul applies the permission if a request matches the `pathExact`, `pathPrefix`, `pathRegex`, or `header`, and the source sent the request using one of the specified methods. Refer to the [Mozilla documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods) for a list of supported request headers. | list | All request methods |
+| `header` | Specifies a header name and matching criteria for HTTP request headers. Refer to [`spec.sources[].permissions[].http[].header`](#spec-sources-permissions-http-header) for details. | list of maps | none |
+
+### `spec.sources[].permissions[].http[].header`
+
+Specifies a set of criteria for matching HTTP request headers. The request header must match all specified criteria for the permission to apply.
+
+#### Values
+
+- Default: None
+- Data type: List of maps
+
+Each member of the `header` list is a map that contains a `name` field and at least one match criterion. The following table describes the parameters that each member of the `header` list may contain:
+
+| Parameter | Description | Data type | Required |
+| --- | --- | --- | --- |
+| `name` | Specifies the name of the header to match. | string | required |
+| `present` | Enables a match if the header configured in the `name` field appears in the request. Consul matches on any value as long as the header key appears in the request. Do not specify `present` if `exact`, `prefix`, `suffix`, or `regex` are configured in the same `header` configuration. | boolean | optional |
+| `Exact` | Specifies a value for the header key set in the `Name` field. If the request header value matches the `exact` value, Consul applies the permission. Do not specify `exact` if `present`, `prefix`, `suffix`, or `regex` are configured in the same `header` configuration. | string | optional |
+| `prefix` | Specifies a prefix value for the header key set in the `name` field. If the request header value starts with the `prefix` value, Consul applies the permission. Do not specify `prefix` if `present`, `exact`, `suffix`, or `regex` are configured in the same `header` configuration. | string | optional |
+| `suffix` | Specifies a suffix value for the header key set in the `name` field. If the request header value ends with the `suffix` value, Consul applies the permission. Do not specify `suffix` if `present`, `exact`, `prefix`, or `regex` are configured in the same `header` configuration. | string | optional |
+| `regex` | Specifies a regular expression pattern as the value for the header key set in the `name` field. If the request header value matches the regex, Consul applies the permission. Do not specify `regex` if `present`, `exact`, `prefix`, or `suffix` are configured in the same `header` configuration. The regex syntax is proxy-specific. If using Envoy, refer to the [re2 documentation](https://github.com/google/re2/wiki/Syntax) for details. | string | optional |
+| `invert` | Inverts the matching logic configured in the `header`. Default is `false`. | boolean | optional |
+
+### `spec.sources[].type`
+
+Specifies the type of destination service that the configuration entry applies to. The only value supported is `consul`.
+
+#### Values
+
+- Default: `consul`
+- Data type: String
+
+### `spec.sources[].description`
+
+Specifies a description of the intention. Consul presents the description in API responses to assist other tools integrated into the network.
+
+#### Values
+
+- Default: None
+- Data type: String
+
+
+
+
+
+
+## Examples
+
+The following examples demonstrate potential use-cases for the service intentions configuration entry.
+
+### L4 Intentions for specific sources and destinations
+
+The following example configuration entry specifies an L4 intention that denies traffic from `web` to `db` service instances, but allows traffic from `api` to `db`.
+
+
+
+```hcl
+Kind = "service-intentions"
+Name = "db"
+Sources = [
+ {
+ Name = "web"
+ Action = "deny"
+ },
+ {
+ Name = "api"
+ Action = "allow"
+ }
+]
+```
+
+```yaml
+apiVersion: consul.hashicorp.com/v1alpha1
+kind: ServiceIntentions
+spec:
+ destination:
+ name: db
+ sources:
+ - name: web
+ action: deny
+ - name: api
+ action: allow
+```
+
+```json
+{
+ "Kind": "service-intentions",
+ "Name": "db",
+ "Sources": [
+ {
+ "Action": "deny",
+ "Name": "web"
+ },
+ {
+ "Action": "allow",
+ "Name": "api"
+ }
+ ]
+}
+```
+
+
+
+### L4 intentions for all destinations
+
+In the following L4 example, the destination is configured with a `*` wildcard. As a result, traffic from `web` service instances is denied for any service in the datacenter.
+
+
+
+```hcl
+Kind = "service-intentions"
+Name = "*"
+Sources = [
+ {
+ Name = "web"
+ Action = "deny"
+ }
+]
+```
+
+```yaml
+apiVersion: consul.hashicorp.com/v1alpha1
+kind: ServiceIntentions
+spec:
+ destination:
+ name: *
+ sources:
+ - name: web
+ action: deny
+```
+
+```json
+{
+ "Kind": "service-intentions",
+ "Name": "*",
+ "Sources": [
+ {
+ "Action": "deny",
+ "Name": "web"
+ }
+ ]
+}
+```
+
+
+
+### L4 intentions for all sources
+
+In the following L4 example, the source is configured with a `*` wildcard. As a result, traffic from any service is denied to `db` service instances.
+
+
+
+```hcl
+Kind = "service-intentions"
+Name = "db"
+Sources = [
+ {
+ Name = "*"
+ Action = "deny"
+ }
+]
+```
+
+```yaml
+apiVersion: consul.hashicorp.com/v1alpha1
+kind: ServiceIntentions
+spec:
+ destination:
+ name: db
+ sources:
+ - name: *
+ action: deny
+```
+
+```json
+{
+ "Kind": "service-intentions",
+ "Name": "db",
+ "Sources": [
+ {
+ "Action": "deny",
+ "Name": "*"
+ }
+ ]
+}
+```
+
+
+### REST access
In the following example, the `admin-dashboard` and `report-generator` services have different levels of access when making REST calls:
@@ -134,8 +1026,8 @@ spec:
### gRPC
-In the following use-case, access to the `IssueRefund` gRPC service method is set to `deny`. Because gRPC method calls [are
-HTTP/2](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md), an HTTP path-matching rule can be used to control traffic:
+In the following example, Consul denies requests from `frontend-web` to the `IssueRefund` gRPC service.
+Because gRPC method calls use the [HTTP/2 protocol](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md), you can apply an HTTP path-matching rule to control traffic:
@@ -174,8 +1066,8 @@ Sources = [
}
]
}
- # NOTE: a default catch-all based on the default ACL policy will apply to
- # unmatched connections and requests. Typically this will be DENY.
+ # A default catch-all based on the default ACL policy applies to
+ # unmatched connections and requests. This is typically DENY.
]
```
@@ -204,8 +1096,8 @@ spec:
- action: allow
http:
pathPrefix: '/mycompany.BillingService/'
- # NOTE: a default catch-all based on the default ACL policy will apply to
- # unmatched connections and requests. Typically this will be DENY.
+ # A default catch-all based on the default ACL policy applies to
+ # unmatched connections and requests. This is typically DENY.
```
```json
@@ -249,7 +1141,7 @@ spec:
### L4 and L7
-You can mix and match L4 and L7 intentions per source:
+In the following example, Consul enforces application layer intentions that deny requests to `api` from `hackathon-project` but allow requests from `web`. In the same configuration entry, Consul enforces network layer intentions that allow requests from `nightly-reconciler` that send `POST` requests to the `/v1/reconcile-data` HTTP endpoint:
@@ -277,8 +1169,8 @@ Sources = [
}
]
},
- # NOTE: a default catch-all based on the default ACL policy will apply to
- # unmatched connections and requests. Typically this will be DENY.
+ # A default catch-all based on the default ACL policy applies to
+ # unmatched connections and requests. This is typically DENY.
]
```
@@ -301,8 +1193,8 @@ spec:
http:
pathExact: /v1/reconcile-data
methods: ['POST']
- # NOTE: a default catch-all based on the default ACL policy will apply to
- # unmatched connections and requests. Typically this will be DENY.
+ # A default catch-all based on the default ACL policy applies to
+ # unmatched connections and requests. This is typically DENY.
```
```json
@@ -384,406 +1276,5 @@ When using cluster peering connections, intentions secure your deployments with
]
}
```
-
-
-## Available Fields
-
-',
- yaml: false,
- },
- {
- name: 'Namespace',
- type: `string: "default"`,
- enterprise: true,
- description:
- "Specifies the namespaces the config entry will apply to. This may be set to the wildcard character (`*`) to match all services in all namespaces that don't otherwise have intentions defined. Wildcard intentions cannot be used when defining L7 [`Permissions`](/consul/docs/connect/config-entries/service-intentions#permissions).",
- yaml: false,
- },
- {
- name: 'Partition',
- type: `string: "default"`,
- enterprise: true,
- description:
- "Specifies the admin partition on which the configuration entry will apply. Wildcard characters (`*`) are not supported. Admin partitions must specified explicitly.",
- yaml: false,
- },
- {
- name: 'Meta',
- type: 'map: nil',
- description: 'Specifies arbitrary KV metadata pairs.',
- yaml: false,
- },
- {
- name: 'metadata',
- children: [
- {
- name: 'name',
- description:
- 'Unlike other config entries, the `metadata.name` field is not used to set the name of the service being configured. Instead, that is set in `spec.destination.name`. Thus this name can be set to anything. See [ServiceIntentions Special Case (OSS)](/consul/docs/k8s/crds#serviceintentions-special-case) or [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise) for more details.',
- },
- {
- name: 'namespace',
- description:
- 'If running Consul Open Source, the namespace is ignored (see [Kubernetes Namespaces in Consul OSS](/consul/docs/k8s/crds#consul-oss)). If running Consul Enterprise see [Kubernetes Namespaces in Consul Enterprise](/consul/docs/k8s/crds#consul-enterprise) for more details.',
- },
- ],
- hcl: false,
- },
- {
- name: 'destination',
- hcl: false,
- children: [
- {
- name: 'name',
- hcl: false,
- type: 'string: ',
- description:
- "The name of the destination service for all intentions defined in this config entry. This may be set to the wildcard character (`*`) to match all services that don't otherwise have intentions defined. Wildcard intentions cannot be used when defining L7 [`Permissions`](/consul/docs/connect/config-entries/service-intentions#permissions).",
- },
- {
- name: 'namespace',
- hcl: false,
- enterprise: true,
- type: 'string: ',
- description:
- "Specifies the namespaces the config entry will apply to. This may be set to the wildcard character (`*`) to match all services in all namespaces that don't otherwise have intentions defined. If not set, the namespace used will depend on the `connectInject.consulNamespaces` configuration. See [ServiceIntentions Special Case (Enterprise)](/consul/docs/k8s/crds#serviceintentions-special-case-enterprise) for more details. Wildcard intentions cannot be used when defining L7 [`Permissions`](/consul/docs/connect/config-entries/service-intentions#permissions).",
- },
- ],
- },
- {
- name: 'Sources',
- type: 'array',
- description: `The list of all [intention sources and the authorization granted to those sources](#sourceintention). The order of
- this list does not matter, but out of convenience Consul will always store
- this reverse sorted by intention precedence, as that is the order that they
- will be evaluated at enforcement time.`,
- },
- ]}
-/>
-
-### `SourceIntention`
-
-',
- description: {
- hcl:
- "The source of the intention. For a `Type` of `consul` this is the name of a Consul service. The service doesn't need to be registered.",
- yaml:
- "The source of the intention. For a `type` of `consul` this is the name of a Consul service. The service doesn't need to be registered.",
- },
- },
- {
- name: 'Peer',
- type: 'string: ""',
- description: {
- hcl:
- "Specifies the [peer](/consul/docs/connect/cluster-peering/index.mdx) of the source service. `Peer` is mutually exclusive with `Partition`.",
- yaml:
- "Specifies the [peer](/consul/docs/connect/cluster-peering/index.mdx) of the source service. `peer` is mutually exclusive with `partition`.",
- },
- },
- {
- name: 'Namespace',
- enterprise: true,
- type: 'string: ""',
- description: {
- hcl:
- "The namespace of the source service. If `Peer` is empty, `Namespace` defaults to the namespace of the destination service (i.e. the config entry's namespace).",
- yaml:
- 'The namespace of the source service. If `peer` is empty, `namespace` defaults to the namespace of the destination service (i.e. `spec.destination.namespace`).',
- },
- },
- {
- name: 'Partition',
- enterprise: true,
- type: 'string: ""',
- description: {
- hcl:
- "Specifies the admin partition of the source service. If `Peer` is empty, `Partition` defaults to the destination service's partition (i.e. the configuration entry's partition). `Partition` is mutually exclusive with `Peer`.",
- yaml:
- "Specifies the admin partition of the source service. If `peer` is empty, `partition` defaults to the destination service's partition (i.e. `spec.destination.partition`). `partition` is mutually exclusive with `peer`.",
- },
- },
- {
- name: 'Action',
- type: 'string: ""',
- description: {
- hcl:
- 'For an L4 intention this is required, and should be set to one of `"allow"` or `"deny"` for the action that should be taken if this intention matches a request.' +
- '
This should be omitted for an L7 intention as it is mutually exclusive with the `Permissions` field.',
- yaml:
- 'For an L4 intention this is required, and should be set to one of `"allow"` or `"deny"` for the action that should be taken if this intention matches a request.' +
- '
This should be omitted for an L7 intention as it is mutually exclusive with the `permissions` field.',
- },
- },
- {
- name: 'Permissions',
- type: 'array',
- description: {
- hcl: `The list of all [additional L7 attributes](#intentionpermission) that extend the intention match criteria.
- Permission precedence is applied top to bottom. For any given request the
- first permission to match in the list is terminal and stops further
- evaluation. As with L4 intentions, traffic that fails to match any of the
- provided permissions in this intention will be subject to the default
- intention behavior is defined by the default [ACL policy](/consul/docs/agent/config/config-files#acl_default_policy).
- This should be omitted for an L4 intention as it is mutually exclusive with
- the \`Action\` field.
- Setting \`Permissions\` is not valid if a wildcard is used for the \`Name\` or \`Namespace\` because they can only be
- applied to services with a compatible protocol.`,
- yaml: `The list of all [additional L7 attributes](#intentionpermission) that extend the intention match criteria.
- Permission precedence is applied top to bottom. For any given request the
- first permission to match in the list is terminal and stops further
- evaluation. As with L4 intentions, traffic that fails to match any of the
- provided permissions in this intention will be subject to the default
- intention behavior is defined by the default [ACL policy](/consul/docs/agent/config/config-files#acl_default_policy).
- This should be omitted for an L4 intention as it is mutually exclusive with
- the \`action\` field.
- Setting \`permissions\` is not valid if a wildcard is used for the \`spec.destination.name\` or \`spec.destination.namespace\`
- because they can only be applied to services with a compatible protocol.`,
- },
- },
- {
- name: 'Precedence',
- type: 'int: ',
- description:
- 'An [integer precedence value](/consul/docs/connect/intentions#precedence-and-match-order) computed from the source and destination naming components.',
- yaml: false,
- },
- {
- name: 'Type',
- type: 'string: "consul"',
- description: {
- hcl:
- 'The type for the `Name` value. This can be only "consul" today to represent a Consul service. If not provided, this will be defaulted to "consul".',
- yaml:
- 'The type for the `name` value. This can be only "consul" today to represent a Consul service. If not provided, this will be defaulted to "consul".',
- },
- },
- {
- name: 'Description',
- type: 'string: ""',
- description:
- 'Description for the intention. This is not used by Consul, but is presented in API responses to assist tooling.',
- },
- {
- name: 'LegacyID',
- type: 'string: ',
- description: `This is the UUID to uniquely identify
- this intention in the system. Cannot be set directly and is exposed here as
- an artifact of the config entry migration and is primarily used to allow
- legacy intention [API](/consul/api-docs/connect/intentions#update-intention-by-id)
- [endpoints](/consul/api-docs/connect/intentions#read-specific-intention-by-id) to
- continue to function for a period of time after [upgrading to 1.9.0](/consul/docs/upgrading/upgrade-specific#consul-1-9-0).`,
- yaml: false,
- },
- {
- name: 'LegacyMeta',
- type: 'map: ',
- description: `Specified arbitrary KV
- metadata pairs attached to the intention, rather than to the enclosing config
- entry. Cannot be set directly and is exposed here as an artifact of the
- config entry migration and is primarily used to allow legacy intention
- [API](/consul/api-docs/connect/intentions#update-intention-by-id)
- [endpoints](/consul/api-docs/connect/intentions#read-specific-intention-by-id) to
- continue to function for a period of time after [upgrading to 1.9.0](/consul/docs/upgrading/upgrade-specific#consul-1-9-0).`,
- yaml: false,
- },
- {
- name: 'LegacyCreateTime',
- type: 'time: optional',
- description: `The timestamp that this intention was
- created. Cannot be set directly and is exposed here as an artifact of the
- config entry migration and is primarily used to allow legacy intention
- [API](/consul/api-docs/connect/intentions#update-intention-by-id)
- [endpoints](/consul/api-docs/connect/intentions#read-specific-intention-by-id) to
- continue to function for a period of time after [upgrading to 1.9.0](/consul/docs/upgrading/upgrade-specific#consul-1-9-0).`,
- yaml: false,
- },
- {
- name: 'LegacyUpdateTime',
- type: 'time: optional',
- description: `The timestamp that this intention was
- last updated. Cannot be set directly and is exposed here as an artifact of the
- config entry migration and is primarily used to allow legacy intention
- [API](/consul/api-docs/connect/intentions#update-intention-by-id)
- [endpoints](/consul/api-docs/connect/intentions#read-specific-intention-by-id) to
- continue to function for a period of time after [upgrading to 1.9.0](/consul/docs/upgrading/upgrade-specific#consul-1-9-0).`,
- yaml: false,
- },
- ]}
-/>
-
-### `IntentionPermission`
-
-',
- description:
- 'This is one of "allow" or "deny" for the action that should be taken if this permission matches a request.',
- },
- {
- name: 'HTTP',
- type: 'IntentionHTTPPermission: ',
- description:
- 'A set of [HTTP-specific authorization criteria](#intentionhttppermission)',
- },
- ]}
-/>
-
-### `IntentionHTTPPermission`
-
- At most only one of `PathExact`, `PathPrefix`, or `PathRegex` may be configured.',
- yaml:
- 'Exact path to match on the HTTP request path.
At most only one of `pathExact`, `pathPrefix`, or `pathRegex` may be configured.',
- },
- },
- {
- name: 'PathPrefix',
- type: 'string: ""',
- description: {
- hcl:
- 'Path prefix to match on the HTTP request path.
At most only one of `PathExact`, `PathPrefix`, or `PathRegex` may be configured.',
- yaml:
- 'Path prefix to match on the HTTP request path.
At most only one of `pathExact`, `pathPrefix`, or `pathRegex` may be configured.',
- },
- },
- {
- name: 'PathRegex',
- type: 'string: ""',
- description: {
- hcl:
- 'Regular expression to match on the HTTP request path.
The syntax is [described below](#regular-expression-syntax).
At most only one of `PathExact`, `PathPrefix`, or `PathRegex` may be configured.',
- yaml:
- 'Regular expression to match on the HTTP request path.
The syntax is [described below](#regular-expression-syntax).
At most only one of `pathExact`, `pathPrefix`, or `pathRegex` may be configured.',
- },
- },
- {
- name: 'Methods',
- type: 'array',
- description:
- 'A list of HTTP methods for which this match applies. If unspecified all HTTP methods are matched. If provided the names must be a valid [method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods).',
- },
- {
- name: 'Header',
- type: 'array',
- description:
- 'A set of criteria that can match on HTTP request headers. If more than one is configured all must match for the overall match to apply.',
- children: [
- {
- name: 'Name',
- type: 'string: ',
- description: 'Name of the header to match',
- },
- {
- name: 'Present',
- type: 'bool: false',
- description: {
- hcl:
- 'Match if the header with the given name is present with any value.
At most only one of `Exact`, `Prefix`, `Suffix`, `Regex`, or `Present` may be configured.',
- yaml:
- 'Match if the header with the given name is present with any value.
At most only one of `exact`, `prefix`, `suffix`, `regex`, or `present` may be configured.',
- },
- },
- {
- name: 'Exact',
- type: 'string: ""',
- description: {
- hcl:
- 'Match if the header with the given name is this value.
At most only one of `Exact`, `Prefix`, `Suffix`, `Regex`, or `Present` may be configured.',
- yaml:
- 'Match if the header with the given name is this value.
At most only one of `exact`, `prefix`, `suffix`, `regex`, or `present` may be configured.',
- },
- },
- {
- name: 'Prefix',
- type: 'string: ""',
- description: {
- hcl:
- 'Match if the header with the given name has this prefix.
At most only one of `Exact`, `Prefix`, `Suffix`, `Regex`, or `Present` may be configured.',
- yaml:
- 'Match if the header with the given name has this prefix.
At most only one of `exact`, `prefix`, `suffix`, `regex`, or `present` may be configured.',
- },
- },
- {
- name: 'Suffix',
- type: 'string: ""',
- description: {
- hcl:
- 'Match if the header with the given name has this suffix.
At most only one of `Exact`, `Prefix`, `Suffix`, `Regex`, or `Present` may be configured.',
- yaml:
- 'Match if the header with the given name has this suffix.
At most only one of `exact`, `prefix`, `suffix`, `regex`, or `present` may be configured.',
- },
- },
- {
- name: 'Regex',
- type: 'string: ""',
- description: {
- hcl:
- 'Match if the header with the given name matches this pattern.
The syntax is [described below](#regular-expression-syntax).
At most only one of `Exact`, `Prefix`, `Suffix`, `Regex`, or `Present` may be configured.',
- yaml:
- 'Match if the header with the given name matches this pattern.
The syntax is [described below](#regular-expression-syntax).
At most only one of `exact`, `prefix`, `suffix`, `regex`, or `present` may be configured.',
- },
- },
- {
- name: 'Invert',
- type: 'bool: false',
- description: 'Inverts the logic of the match',
- },
- ],
- },
- ]}
-/>
-
-## ACLs
-
-Configuration entries may be protected by [ACLs](/consul/docs/security/acl).
-
-Reading a `service-intentions` config entry requires `intentions:read` on the resource.
-
-Creating, updating, or deleting a `service-intentions` config entry requires
-`intentions:write` on the resource.
-
-Intention ACL rules are specified as part of a `service` rule. See [Intention
-Management Permissions](/consul/docs/connect/intentions#intention-management-permissions) for
-more details.
-
-## Regular Expression Syntax
-
-The actual syntax of the regular expression fields described here is entirely
-proxy-specific.
-When using [Envoy](/consul/docs/connect/proxies/envoy) as a proxy, the syntax for
-these fields is [RE2](https://github.com/google/re2/wiki/Syntax).
+
diff --git a/website/content/docs/connect/index.mdx b/website/content/docs/connect/index.mdx
index cbd2903a3318..7c7235569d3e 100644
--- a/website/content/docs/connect/index.mdx
+++ b/website/content/docs/connect/index.mdx
@@ -5,7 +5,7 @@ description: >-
Consul’s service mesh makes application and microservice networking secure and observable with identity-based authentication, mutual TLS (mTLS) encryption, and explicit service-to-service authorization enforced by sidecar proxies. Learn how Consul’s service mesh works and get started on VMs or Kubernetes.
---
-# Consul Service Mesh
+# 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
@@ -25,30 +25,30 @@ Review the video below to learn more about Consul Connect from HashiCorp's co-fo
height="315"
>
-## Application Security
+## Application security
-Connect enables secure deployment best-practices with automatic
+Consul service mesh enables secure deployment best-practices with automatic
service-to-service encryption, and identity-based authorization.
-Connect uses the registered service identity (rather than IP addresses) to
+Consul uses the registered service identity, rather than IP addresses, to
enforce access control with [intentions](/consul/docs/connect/intentions). This
-makes it easier to reason about access control and enables services to be
-rescheduled by orchestrators including Kubernetes and Nomad. Intention
-enforcement is network agnostic, so Connect works with physical networks, cloud
+makes it easier to control access and enables services to be
+rescheduled by orchestrators, including Kubernetes and Nomad. Intention
+enforcement is network agnostic, so Consul service mesh works with physical networks, cloud
networks, software-defined networks, cross-cloud, and more.
## Observability
-One of the key benefits of Consul Connect is the uniform and consistent view it can
+One of the key benefits of Consul service mesh is the uniform and consistent view it can
provide of all the services on your network, irrespective of their different
-programming languages and frameworks. When you configure Consul Connect to use
-sidecar proxies, those proxies "see" all service-to-service traffic and can
-collect data about it. Consul Connect can configure Envoy proxies to collect
+programming languages and frameworks. When you configure Consul service mesh to use
+sidecar proxies, those proxies see all service-to-service traffic and can
+collect data about it. Consul service mesh can configure Envoy proxies to collect
layer 7 metrics and export them to tools like Prometheus. Correctly instrumented
applications can also send open tracing data through Envoy.
-## Getting Started With Consul Service Mesh
+## Getting started with Consul service mesh
-There are several ways to try Connect in different environments.
+Complete the following tutorials try Consul service mesh in different environments:
- The [Getting Started with Consul Service Mesh collection](/consul/tutorials/kubernetes-deploy/service-mesh?utm_source=docs)
walks you through installing Consul as service mesh for Kubernetes using the Helm
diff --git a/website/content/docs/connect/intentions.mdx b/website/content/docs/connect/intentions.mdx
deleted file mode 100644
index b3b0371a93a7..000000000000
--- a/website/content/docs/connect/intentions.mdx
+++ /dev/null
@@ -1,341 +0,0 @@
----
-layout: docs
-page_title: Service Mesh Intentions
-description: >-
- Intentions define communication permissions in the service mesh between microservices. Learn about configuration basics, wildcard intentions, precedence and match order, and protecting intention management with ACLs.
----
-
-# Service Mesh Intentions
-
--> **1.9.0 and later:** This guide only applies in Consul versions 1.9.0 and
-later. The documentation for the legacy intentions system is
-[here](/consul/docs/connect/intentions-legacy).
-
-Intentions define access control for services via Connect and are used to
-control which services may establish connections or make requests. Intentions
-can be managed via the API, CLI, or UI.
-
-Intentions are enforced on inbound connections or requests by the
-[proxy](/consul/docs/connect/proxies) or within a [natively integrated
-application](/consul/docs/connect/native).
-
-Depending upon the [protocol] in use by the destination service, you can define
-intentions to control Connect traffic authorization either at networking layer
-4 (e.g. TCP) and application layer 7 (e.g. HTTP):
-
-- **Identity-based** - All intentions may enforce access based on identities
- encoded within [TLS
- certificates](/consul/docs/connect/connect-internals#mutual-transport-layer-security-mtls).
- This allows for coarse all-or-nothing access control between pairs of
- services. These work with for services with any [protocol] as they only
- require awareness of the TLS handshake that wraps the opaque TCP connection.
- These can also be thought of as **L4 intentions**.
-
-- **Application-aware** - Some intentions may additionally enforce access based
- on [L7 request
- attributes](/consul/docs/connect/config-entries/service-intentions#permissions) in
- addition to connection identity. These may only be defined for services with
- a [protocol] that is HTTP-based. These can also be thought of as **L7
- intentions**.
-
-At any given point in time, between any pair of services **only one intention
-controls authorization**. This may be either an L4 intention or an L7
-intention, but at any given point in time only one of those applies.
-
-The [intention match API](/consul/api-docs/connect/intentions#list-matching-intentions)
-should be periodically called to retrieve all relevant intentions for the
-target destination. After verifying the TLS client certificate, the cached
-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 is set to `deny`, then all connections or requests will be denied by default.
-
-## Intention Basics
-
-You can define a [`service-intentions`](/consul/docs/connect/config-entries/service-intentions) configuration entry to create and manage intentions, as well as manage intentions through the Consul UI. You can also perform some intention-related tasks using the API and CLI commands. Refer to the [API](/consul/api-docs/connect/intentions) and [CLI](/consul/commands/intention) documentation for details.
-
-The following example shows a `service-intentions` configuration entry that specifies two intentions. Refer to the [`service-intentions`](/consul/docs/connect/config-entries/service-intentions) documentation for the full data model and additional examples.
-
-
-
-```hcl
-Kind = "service-intentions"
-Name = "db"
-Sources = [
- {
- Name = "web"
- Action = "deny"
- },
- {
- Name = "api"
- Action = "allow"
- }
-]
-```
-
-```json
-{
- "Kind": "service-intentions",
- "Name": "db",
- "Sources": [
- {
- "Action": "deny",
- "Name": "web"
- },
- {
- "Action": "allow",
- "Name": "api"
- }
- ]
-}
-```
-
-
-
-This configuration entry defines two intentions with a common destination of `db`. The
-first intention above is a deny intention with a source of `web`. This says
-that connections from web to db are not allowed and the connection will be
-rejected. The second intention is an allow intention with a source of `api`.
-This says that connections from api to db are allowed and connections will be
-accepted.
-
-### Wildcard Intentions
-
-You can use the `*` wildcard to match service names when defining an intention source or destination. The wildcard matches _any_ value, which enables you to set a wide initial scope when configuring intentions.
-
-The wildcard is supported in Consul Enterprise `namespace` fields (see [Namespaces](/consul/docs/enterprise/namespaces) for additional information), but it _is not supported_ in `partition` fields (see [Admin Partitions](/consul/docs/enterprise/admin-partitions) for additional information).
-
-In the following example, the `web` service cannot connect to _any_ service:
-
-
-
-```hcl
-Kind = "service-intentions"
-Name = "*"
-Sources = [
- {
- Name = "web"
- Action = "deny"
- }
-]
-```
-
-```json
-{
- "Kind": "service-intentions",
- "Name": "*",
- "Sources": [
- {
- "Action": "deny",
- "Name": "web"
- }
- ]
-}
-```
-
-
-
-The `db` service is configured to deny all connection in the following example:
-
-
-
-```hcl
-Kind = "service-intentions"
-Name = "db"
-Sources = [
- {
- Name = "*"
- Action = "deny"
- }
-]
-```
-
-```json
-{
- "Kind": "service-intentions",
- "Name": "db",
- "Sources": [
- {
- "Action": "deny",
- "Name": "*"
- }
- ]
-}
-```
-
-
-
- This example grants Prometheus access to any service in
-any namespace.
-
-
-
-```hcl
-Kind = "service-intentions"
-Name = "*"
-Namespace = "*"
-Sources = [
- {
- Name = "prometheus"
- Namespace = "monitoring"
- Action = "allow"
- }
-]
-```
-
-```json
-{
- "Kind": "service-intentions",
- "Name": "*",
- "Namespace": "*",
- "Sources": [
- {
- "Action": "allow",
- "Name": "prometheus",
- "Namespace": "monitoring"
- }
- ]
-}
-```
-
-
-
-### Enforcement
-
-For services that define their [protocol] as TCP, intentions mediate the
-ability to **establish new connections**. When an intention is modified,
-existing connections will not be affected. This means that changing a
-connection from "allow" to "deny" today _will not_ kill the connection.
-
-For services that define their protocol as HTTP-based, intentions mediate the
-ability to **issue new requests**.
-
-When an intention is modified, requests received after the modification will
-use the latest intention rules to enforce access. This means that though
-changing a connection from "allow" to "deny" today will not kill the
-connection, it will correctly block new requests from being processed.
-
-## Precedence and Match Order
-
-Intentions are matched in an implicit order based on specificity, preferring
-deny over allow. Specificity is determined by whether a value is an exact
-specified value or is the wildcard value `*`.
-The full precedence table is shown below and is evaluated
-top to bottom, with larger numbers being evaluated first.
-
-| Source Namespace | Source Name | Destination Namespace | Destination Name | Precedence |
-| ---------------- | ----------- | --------------------- | ---------------- | ---------- |
-| Exact | Exact | Exact | Exact | 9 |
-| Exact | `*` | Exact | Exact | 8 |
-| `*` | `*` | Exact | Exact | 7 |
-| Exact | Exact | Exact | `*` | 6 |
-| Exact | `*` | Exact | `*` | 5 |
-| `*` | `*` | Exact | `*` | 4 |
-| Exact | Exact | `*` | `*` | 3 |
-| Exact | `*` | `*` | `*` | 2 |
-| `*` | `*` | `*` | `*` | 1 |
-
-The precedence value can be read from a
-[field](/consul/docs/connect/config-entries/service-intentions#precedence) on the
-`service-intentions` configuration entry after it is modified. Precedence cannot be
-manually overridden today.
-
-The numbers in the table above are not stable. Their ordering will remain
-fixed but the actual number values may change in the future.
-
--> - Namespaces are an Enterprise feature. In Consul
-OSS the only allowable value for either namespace field is `"default"`. Other
-rows in this table are not applicable.
-
-## Intention Management Permissions
-
-Intention management can be protected by [ACLs](/consul/docs/security/acl).
-Permissions for intentions are _destination-oriented_, meaning the ACLs
-for managing intentions are looked up based on the destination value
-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`
-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`.
-
-
-
-```hcl
-service "web" {
- policy = "write"
-}
-```
-
-```json
-{
- "service": [
- {
- "web": [
- {
- "policy": "write"
- }
- ]
- }
- ]
-}
-```
-
-
-
-It is possible to explicitly specify intention permissions. For example,
-the following policy will allow a service to be discovered without granting
-access to read intentions for it.
-
-```hcl
-service "web" {
- policy = "read"
- intentions = "deny"
-}
-```
-
-Note that `intentions:read` is required for a token that a Connect-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.
-
-~> **Security Note:** Explicitly allowing `intentions:write` on the token you
-provide to a service instance at registration time opens up a significant
-additional vulnerability. Although you may trust the service _team_ to define
-which inbound connections they accept, using a combined token for registration
-allows a compromised instance to to redefine the intentions which allows many
-additional attack vectors and may be hard to detect. We strongly recommend only
-delegating `intentions:write` using tokens that are used by operations teams or
-orchestrators rather than spread via application config, or only manage
-intentions with management tokens.
-
-## Performance and Intention Updates
-
-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.
-
-Supported [proxies] (such as [Envoy]) also cache this data within their own
-configuration so that inbound connections or requests require no Consul agent
-involvement during authorization. All actions in the data path of connections
-happen within the proxy.
-
-Updates to intentions are propagated nearly instantly to agents since agents
-maintain a continuous blocking query in the background for intention updates
-for registered services. Proxies similarly use blocking queries to update
-their local configurations quickly.
-
-Because all the intention data is cached locally, the agents or proxies can
-fail static. Even if the agents are severed completely from the Consul servers,
-or the proxies are severed completely from their local Consul agent, inbound
-connection authorization continues to work indefinitely. Changes to intentions
-will not be picked up until the partition heals, but will then automatically
-take effect when connectivity is restored.
-
-[protocol]: /consul/docs/connect/config-entries/service-defaults#protocol
-[proxies]: /consul/docs/connect/proxies
-[envoy]: /consul/docs/connect/proxies/envoy
diff --git a/website/content/docs/connect/intentions/create-manage-intentions.mdx b/website/content/docs/connect/intentions/create-manage-intentions.mdx
new file mode 100644
index 000000000000..80e68ce890ad
--- /dev/null
+++ b/website/content/docs/connect/intentions/create-manage-intentions.mdx
@@ -0,0 +1,178 @@
+---
+layout: docs
+page_title: Create and manage service intentions
+description: >-
+ Learn how to create and manage Consul service mesh intentions using service-intentions config entries, the `consul intentions` command, and `/connect/intentions` API endpoint.
+---
+
+# Create and manage intentions
+
+This topic describes how to create and manage service intentions, which are configurations for controlling access between services in the service mesh.
+
+## Overview
+
+You can create single intentions or create them in batches using the Consul API, CLI, or UI. You can also define a service intention configuration entry that sets default intentions for all services in the mesh. Refer to [Service intentions overview](/consul/docs/connnect/intentions/intentions) for additional background information about intentions.
+
+## Requirements
+
+- At least two services must be registered in the datacenter.
+- TLS must be enabled to enforce L4 intentions. Refer to [Encryption](/consul/docs/security/encryption) for additional information.
+
+### ACL requirements
+
+Consul grants permissions for creating and managing intentions based on the destination, not the source. When ACLs are enabled, services and operators must present a token linked to a policy that grants read and write permissions to the destination service.
+
+Consul implicitly grants `intentions:read` permissions to destination services when they are configured with `service:read` or `service:write` permissions. This is so that the services can allow or deny inbound connections when they attempt to join the service mesh. Refer to [Service rules](/consul/docs/security/acl/acl-rules#service-rules) for additional information about configuring ALCs for intentions.
+
+The default ACL policy configuration determines the default behavior for intentions. If the policy is set to `deny`, then all connections or requests are denied and you must enable them explicitly. Refer to [`default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) for details.
+
+## Create an intention
+
+You can create and manage intentions one at a time using the Consul API, CLI, or UI You can specify one destination or multiple destinations in a single intention.
+
+### API
+
+Send a `PUT` request to the `/connect/intentions/exact` HTTP API endpoint and specify the following query parameters:
+
+- `source`: Service sending the request
+- `destination`: Service responding to the request
+- `ns`: Namespace of the destination service
+
+For L4 intentions, you must also specify the intention action in the request payload.
+
+The following example creates an intention that allows `web` to send request to `db`:
+
+```shell-session
+$ curl --request PUT \
+--data ' { "Action": "allow" } ' \
+http://localhost:8500/v1/connect/intentions/exact\?source\=web\&destination\=db
+```
+
+Refer to the `/connect/intentions/exact` [HTTP API endpoint documentation](/consul/api-docs/connect/intentions) for additional information request payload parameters.
+
+For L7 intentions, specify the `Permissions` in the request payload to configure attributes for dynamically enforcing intentions. In the following example payload, Consul allows HTTP GET requests if the request body is empty:
+
+
+
+```json
+{
+ "Permissions": [
+ {
+ "Action": "allow",
+ "HTTP": {
+ "Methods": ["GET"],
+ "Header": [
+ {
+ "Name": "Content-Length",
+ "Exact": "0"
+ }
+ ]
+ }
+ }
+ ]
+}
+
+```
+
+
+
+The `Permissions` object specifies a list of permissions for L7 traffic sources. The list contains one or more actions and a set of match criteria for each action. Refer to the [`Sources[].Permissions[]` parameter](/consul/connect/config-entries/service-intentions#source-permissions) in the service intentions configuration entry reference for configuration details.
+
+To apply the intention, call the endpoint and pass the configuration file containing the attributes to the endpoint:
+
+```shell-session
+$ curl --request PUT \
+--data @payload.json \
+http://localhost:8500/v1/connect/intentions/exact\?source\=svc1\&destination\=sv2
+```
+### CLI
+
+Use the `consul intention create` command according to the following syntax to create a new intention:
+
+```shell-session
+$ consul intention create -
+```
+
+The following example creates an intention that allows `web` service instances to connect to `db` service instances:
+
+```shell-session
+$ consul intention create -allow web db
+```
+
+You can use the asterisk (`*`) wildcard to specify multiple destination services. Refer to [Precedence and match order](/consul/docs/connect/intentions/create-manage-intentions#precedence-and-match-order) for additional information.
+
+### Consul UI
+
+1. Log into the Consul UI and choose **Services** from the sidebar menu.
+1. Click on a service and then click the **Intentions* tab.
+1. Click **Create** and choose the source service from the drop-down menu.
+1. You can add an optional description.
+1. Choose one of the following options:
+ 1. **Allow**: Allows the source service to send requests to the destination.
+ 1. **Deny**: Prevents the source service from sending requests to the destination.
+ 1. **Application Aware**: Enables you to specify L7 criteria for dynamically enforcing intentions. Refer to [Configure application aware settings](#configure-application-aware-settings) for additional information.
+1. Click **Save**.
+
+Repeat the procedure as necessary to create additional intentions.
+
+#### Configure application aware settings
+
+You can use the Consul UI to configure L7 permissions.
+
+1. Click **Add permission** to open the permission editor.
+1. Enable the **Allow** or **Deny** option.
+1. You can specify a path, request method, and request headers to match. All criteria must be satisfied for Consul to enforce the permission. Refer to the [`Sources[].Permissions[]` parameter](/consul/docs/connect/config-entries/service-intentions#sources-permissions) in the service intentions configuration entry reference for information about the available configuration fields.
+1. Click **Save**.
+
+Repeat the procedure as necessary to create additional permissions.
+
+## Create multiple intentions
+
+You can create a service intentions configuration entry to specify default intentions for your service mesh. You can specify default settings for L4 or L7 application-aware traffic.
+
+### Define a service intention configuration entry
+
+Configure the following fields:
+
+
+
+
+
+- [`Kind`](/consul/docs/connect/config-entries/service-intentions#kind): Declares the type of configuration entry. Must be set to `service-intentions`.
+- [`Name`](/consul/docs/connect/config-entries/service-intentions#kind): Specifies the name of the destination service for intentions defined in the configuration entry. You can use a wildcard character (*) to set L4 intentions for all services that are not protected by specific intentions. Wildcards are not supported for L7 intentions.
+- [`Sources`](/consul/docs/connect/config-entries/service-intentions#sources): Specifies an unordered list of all intention sources and the authorizations granted to those sources. Consul stores and evaluates the list in reverse order sorted by intention precedence.
+- [`Sources.Action`](/consul/docs/connect/config-entries/service-intentions#sources-action) or [`Sources.Permissions`](/consul/docs/connect/config-entries/service-intentions#sources-permissions): For L4 intentions, set the `Action` field to "allow" or "deny" so that Consul can enforce intentions that match the source service. For L7 intentions, configure the `Permissions` settings, which define a set of application-aware attributes for dynamically matching incoming requests. The `Actions` and `Permissions` settings are mutually exclusive.
+
+
+
+
+
+- [`apiVersion`](/consul/docs/connect/config-entries/service-intentions#apiversion): Specifies the Consul API version. Must be set to `consul.hashicorp.com/v1alpha1`.
+- [`kind`](/consul/docs/connect/config-entries/service-intentions#kind): Declares the type of configuration entry. Must be set to `ServiceIntentions`.
+- [`spec.destination.name`](/consul/docs/connect/config-entries/service-intentions#spec-destination-name): Specifies the name of the destination service for intentions defined in the configuration entry. You can use a wildcard character (*) to set L4 intentions for all services that are not protected by specific intentions. Wildcards are not supported for L7 intentions.
+- [`spec.sources`](/consul/docs/connect/config-entries/service-intentions#spec-sources): Specifies an unordered list of all intention sources and the authorizations granted to those sources. Consul stores and evaluates the list in reverse order sorted by intention precedence.
+- [`spec.sources.action`](/consul/docs/connect/config-entries/service-intentions#spec-sources-action) or [`spec.sources.permissions`](/consul/docs/connect/config-entries/service-intentions#spec-sources-permissions): For L4 intentions, set the `action` field to "allow" or "deny" so that Consul can enforce intentions that match the source service. For L7 intentions, configure the `permissions` settings, which define a set of application-aware attributes for dynamically matching incoming requests. The `actions` and `permissions` settings are mutually exclusive.
+
+
+
+
+
+Refer to the [service intentions configuration entry](/consul/docs/connect/config-entries/service-intentions) reference documentation for details about all configuration options.
+
+Refer to the [example service intentions configurations](/consul/docs/connect/config-entries/service-intentions#examples) for additional guidance.
+
+#### Interaction with other configuration entries
+
+L7 intentions defined in a configuration entry are restricted to destination services
+configured with an HTTP-based protocol as defined in a corresponding
+[service defaults configuration entry](/consul/docs/connect/config-entries/service-defaults)
+or globally in a [proxy defaults configuration entry](/consul/docs/connect/config-entries/proxy-defaults).
+
+### Apply the service intentions configuration entry
+
+You can apply the configuration entry using the [`consul config` command](/consul/commands/config) or by calling the [`/config` API endpoint](/consul/api-docs/config). In Kubernetes environments, apply the `ServiceIntentions` custom resource definitions (CRD) to implement and manage Consul configuration entries.
+
+Refer to the following topics for details about applying configuration entries:
+
+- [How to Use Configuration Entries](/consul/docs/agent/config-entries)
+- [Custom Resource Definitions for Consul on Kubernetes](/consul/docs/k8s/crds)
\ No newline at end of file
diff --git a/website/content/docs/connect/intentions/index.mdx b/website/content/docs/connect/intentions/index.mdx
new file mode 100644
index 000000000000..301344c64ec0
--- /dev/null
+++ b/website/content/docs/connect/intentions/index.mdx
@@ -0,0 +1,91 @@
+---
+layout: docs
+page_title: Service mesh intentions overview
+description: >-
+ Intentions are access controls that allow or deny incoming requests to services in the mesh.
+---
+
+# Service intentions overview
+
+This topic provides overview information about Consul intentions, which are mechanisms that control traffic communication between services in the Consul service mesh.
+
+
+
+## Intention types
+
+Intentions control traffic communication between services at the network layer, also called _L4_ traffic, or the application layer, also called _L7 traffic_. The protocol that the destination service uses to send and receive traffic determines the type of authorization the intention can enforce.
+
+### L4 traffic intentions
+
+If the destination service uses TCP or any non-HTTP-based protocol, then intentions can control traffic based on identities encoded in mTLS certificates. Refer to [Mutual transport layer security (mTLS)](/consul/docs/connect/connect-internals#mutual-transport-layer-security-mtls) for additional information.
+
+This implementation allows broad all-or-nothing access control between pairs of services. The only requirement is that the service is aware of the TLS handshake that wraps the opaque TCP connection.
+
+### L7 traffic intentions
+
+If the destination service uses an HTTP-based protocol, then intentions can enforce access based on application-aware request attributes, in addition to identity-based enforcement, to control traffic between services. Refer to [Service intentions configuration reference](/consul/docs/connect/config-entries/service-intentions#permissions) for additional information.
+
+## Workflow
+
+You can manually create intentions from the Consul UI, API, or CLI. You can also enable Consul to dynamically create them by defining traffic routes in service intention configuration entries. Refer to [Create and manage intentions](/consul/docs/connect/intentions/create-manage-intentions) for details.
+
+### Enforcement
+
+The [proxy](/consul/docs/connect/proxies) or [natively-integrated
+application](/consul/docs/connect/native) enforces intentions on inbound connections or requests. Only one intention can control authorization between a pair of services at any single point in time.
+
+L4 intentions mediate the ability to establish new connections. Modifying an intention does not have an effect on existing connections. As a result, changing a connection from `allow` to `deny` does not sever the connection.
+
+L7 intentions mediate the ability to issue new requests. When an intention is modified, requests received after the modification use the latest intention rules to enforce access. Changing a connection from `allow` to `deny` does not sever the connection, but doing so blocks new requests from being processed.
+
+### Caching
+
+The intentions for services registered with a Consul agent are cached locally on the agent. Supported proxies also cache intention data in their own configurations so that they can authorize inbound connections or requests without relying on the Consul agent. All actions in the data path of connections take place within the proxy.
+
+### Updates
+
+Consul propagates updates to intentions almost instantly as a result of the continuous blocking query the agent uses. A _blocking query_ is a Consul API feature that uses long polling to wait for potential changes. Refer to [Blocking Queries](/consul/api-docs/features/blocking) for additional information. Proxies also use blocking queries to quickly update their local configurations.
+
+Because all intention data is cached locally, authorizations for inbound connection persist, even if the agents are completely severed from the Consul servers or if the proxies are completely severed from their local Consul agent. If the connection is severed, Consul automatically applies changes to intentions when connectivity is restored.
+
+### Intention maintenance
+
+Services should periodically call the [intention match API](/consul/api-docs/connect/intentions#list-matching-intentions) to retrieve all relevant intentions for the target destination. After verifying the TLS client certificate, the cached intentions for each incoming connection or request determine if it should be accepted or rejected.
+
+## Precedence and match order
+
+Consul processes criteria defined in the service intention configuration entry to match incoming requests. When Consul finds a match, it applies the corresponding action specified in the configuration entry. The match criteria may include specific HTTP headers, request methods, or other attributes. Additionally, you can use regular expressions to programmatically match attributes. Refer to [Service intention configuration entry reference](/consul/docs/connect/config-entries/service-intentions) for details.
+
+Consul orders the matches based the following factors:
+
+- Specificity: Incoming requests that match attributes directly have the highest precedence. For example, intentions that are configured to deny traffic from services that send `POST` requests take precedence over intentions that allow traffic from methods configured with the wildcard value `*`.
+- Authorization: Consul enforces `deny` over `allow` if match criteria are weighted equally.
+
+The following table shows match precedence in descending order:
+
+| Precedence | Source Namespace | Source Name | Destination Namespace | Destination Name |
+| -----------| ---------------- | ------------| --------------------- | ---------------- |
+| 9 | Exact | Exact | Exact | Exact |
+| 8 | Exact | `*` | Exact | Exact |
+| 7 | `*` | `*` | Exact | Exact |
+| 6 | Exact | Exact | Exact | `*` |
+| 5 | Exact | `*` | Exact | `*` |
+| 4 | `*` | `*` | Exact | `*` |
+| 3 | Exact | Exact | `*` | `*` |
+| 2 | Exact | `*` | `*` | `*` |
+| 1 | `*` | `*` | `*` | `*` |
+
+Consul prints the precedence value to the service intentions configuration entry after it processes the matching criteria. The value is read-only. Refer to
+[`Precedence`](/consul/docs/connect/config-entries/service-intentions#precedence) for additional information.
+
+Namespaces are an Enterprise feature. In Consul OSS, the only allowable value for either namespace field is `"default"`. Other rows in the table are not applicable.
+
+The [intention match API](/consul/api-docs/connect/intentions#list-matching-intentions)
+should be periodically called to retrieve all relevant intentions for the
+target destination. After verifying the TLS client certificate, the cached
+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 is set to `deny`, then all connections or requests will be denied by default.
\ No newline at end of file
diff --git a/website/content/docs/connect/intentions-legacy.mdx b/website/content/docs/connect/intentions/legacy.mdx
similarity index 98%
rename from website/content/docs/connect/intentions-legacy.mdx
rename to website/content/docs/connect/intentions/legacy.mdx
index 0e9e991d37c5..b79d34a543ae 100644
--- a/website/content/docs/connect/intentions-legacy.mdx
+++ b/website/content/docs/connect/intentions/legacy.mdx
@@ -8,8 +8,7 @@ description: >-
# Intentions in Legacy Mode
~> **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 please use the updated
-documentation [here](/consul/docs/connect/intentions).
+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
diff --git a/website/content/docs/k8s/connect/index.mdx b/website/content/docs/k8s/connect/index.mdx
index 7e30ab2be898..00e5c8e9383e 100644
--- a/website/content/docs/k8s/connect/index.mdx
+++ b/website/content/docs/k8s/connect/index.mdx
@@ -175,18 +175,18 @@ upstream. This is analogous to the standard Kubernetes service environment varia
point instead to the correct local proxy port to establish connections via
Connect.
-We can verify access to the static text server using `kubectl exec`.
+You can verify access to the static text server using `kubectl exec`.
Because transparent proxy is enabled by default,
-we use Kubernetes DNS to connect to our desired upstream.
+use Kubernetes DNS to connect to your desired upstream.
```shell-session
$ kubectl exec deploy/static-client -- curl --silent http://static-server/
"hello world"
```
-We can control access to the server using [intentions](/consul/docs/connect/intentions).
+You can control access to the server using [intentions](/consul/docs/connect/intentions).
If you use the Consul UI or [CLI](/consul/commands/intention/create) to
-create a deny [intention](/consul/docs/connect/intentions) between
+deny communication between
"static-client" and "static-server", connections are immediately rejected
without updating either of the running pods. You can then remove this
intention to allow connections again.
diff --git a/website/content/docs/lambda/invoke-from-lambda.mdx b/website/content/docs/lambda/invoke-from-lambda.mdx
index a7ec2913865c..4c29e4b8d9cd 100644
--- a/website/content/docs/lambda/invoke-from-lambda.mdx
+++ b/website/content/docs/lambda/invoke-from-lambda.mdx
@@ -264,7 +264,7 @@ Define the following environment variables in your Lambda functions to configure
## Invoke the Lambda function
-If _intentions_ are enabled in the Consul service mesh, you must create an intention that allows the Lambda function's Consul service to invoke all upstream services prior to invoking the Lambda function. Refer to [Service Mesh Intentions](/consul/docs/connect/intentions) for additional information.
+If _intentions_ are enabled in the Consul service mesh, you must create an intention that allows the Lambda function's Consul service to invoke all upstream services prior to invoking the Lambda function. Refer to [Service mesh intentions](/consul/docs/connect/intentions) for additional information.
There are several ways to invoke Lambda functions. In the following example, the `aws lambda invoke` CLI command invokes the function:
diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx
index 3b63e327a20e..a09ffd2fc253 100644
--- a/website/content/docs/security/acl/acl-rules.mdx
+++ b/website/content/docs/security/acl/acl-rules.mdx
@@ -869,7 +869,7 @@ service "app" {
-Refer to [Intention Management Permissions](/consul/docs/connect/intentions#intention-management-permissions)
+Refer to [ACL requirements for intentions](/consul/docs/connect/intentions/create-manage-intentions#acl-requirements)
for more information about managing intentions access with service rules.
## Session Rules
diff --git a/website/data/docs-nav-data.json b/website/data/docs-nav-data.json
index f66afc94c5f1..67317ed5fa77 100644
--- a/website/data/docs-nav-data.json
+++ b/website/data/docs-nav-data.json
@@ -539,12 +539,25 @@
]
},
{
- "title": "Service-to-service permissions - Intentions",
- "path": "connect/intentions"
- },
- {
- "title": "Service-to-service permissions - Intentions (Legacy Mode)",
- "path": "connect/intentions-legacy"
+ "title": "Service intentions",
+ "routes": [
+ {
+ "title": "Overview",
+ "path": "connect/intentions"
+ },
+ {
+ "title": "Create and manage service intentions",
+ "path": "connect/intentions/create-manage-intentions"
+ },
+ {
+ "title": "Service intentions legacy mode",
+ "path": "connect/intentions/legacy"
+ },
+ {
+ "title": "Configuration",
+ "href": "/consul/docs/connect/config-entries/service-intentions"
+ }
+ ]
},
{
"title": "Transparent Proxy",
diff --git a/website/public/img/consul-connect/consul-service-mesh-intentions-overview.svg b/website/public/img/consul-connect/consul-service-mesh-intentions-overview.svg
new file mode 100644
index 000000000000..cdd7ea0ad6eb
--- /dev/null
+++ b/website/public/img/consul-connect/consul-service-mesh-intentions-overview.svg
@@ -0,0 +1 @@
+
diff --git a/website/redirects.js b/website/redirects.js
index 3e4625016505..fb9ec442c664 100644
--- a/website/redirects.js
+++ b/website/redirects.js
@@ -22,4 +22,14 @@ module.exports = [
destination: '/consul/docs/k8s/connect/cluster-peering/tech-specs',
permanent: true,
},
+ {
+ source: '/consul/docs/connect/intentions#intention-management-permissions',
+ destination: `/consul/docs/connect/intentions/create-manage-intentions#acl-requirements`,
+ permanent: true,
+ },
+ {
+ source: '/consul/docs/connect/intentions#intention-basics',
+ destination: `/consul/docs/connect/intentions`,
+ permanent: true,
+ },
]