rollback link updates to intentions overview

website/content/api-docs/api-structure.mdx

@@ -116,7 +116,7 @@ header `X-Consul-Default-ACL-Policy` set to either "allow" or "deny" which
 mirrors the current value of the agent's
 [`acl.default_policy`](/consul/docs/agent/config/config-files#acl_default_policy) option.
 
-This is also the default [intention](/consul/docs/connect/intentions/intentions) enforcement
+This is also the default [intention](/consul/docs/connect/intentions) enforcement
 action if no intention matches.
 
 This is returned even if ACLs are disabled.

website/content/api-docs/connect/intentions.mdx

@@ -9,7 +9,7 @@ description: |-
 # Intentions - Connect HTTP API
 
 The `/connect/intentions` endpoint provide tools for managing
-[intentions](/consul/docs/connect/intentions/intentions).
+[intentions](/consul/docs/connect/intentions).
 
 -> **1.9.0 and later:** Reading and writing intentions has been
 migrated to the

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 [service mesh intentions](/consul/docs/connect/intentions/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.

website/content/commands/intention/index.mdx

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

website/content/docs/connect/cluster-peering/index.mdx

@@ -25,7 +25,7 @@ Cluster peering leverages several components of Consul's architecture to enforce
 - A _peering token_ contains an embedded secret that securely establishes communication when shared symetrically between datacenters. Sharing this token enables each datacenter's server agents to recognize requests from authorized peers, similar to how the [gossip encryption key secures agent LAN gossip](/consul/docs/security/encryption#gossip-encryption).
 - A _mesh gateway_ encrypts outgoing traffic, decrypts incoming traffic, and directs traffic to healthy services. Consul's service mesh features must be enabled in order to use mesh gateways. Mesh gateways support the specific admin partitions they are deployed on. Refer to [Mesh gateways](/consul/docs/connect/gateways/mesh-gateway) for more information.
 - An _exported service_ communicates with downstreams deployed in other admin partitions. They are explicitly defined in an [`exported-services` configuration entry](/consul/docs/connect/config-entries/exported-services).
-- A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.
+- A _service intention_ secures [service-to-service communication in a service mesh](/consul/docs/connect/intentions). Intentions enable identity-based access between services by exchanging TLS certificates, which the service's sidecar proxy verifies upon each request.
 
 ### Compared with WAN federation
 

website/content/docs/connect/config-entries/index.mdx

@@ -27,7 +27,7 @@ The following configuration entries are supported:
   defaults for all the instances of a given service
 
 - [Service Intentions](/consul/docs/connect/config-entries/service-intentions) - defines
-  the [intentions](/consul/docs/connect/intentions/intentions) for a destination service
+  the [intentions](/consul/docs/connect/intentions) for a destination service
 
 - [Service Resolver](/consul/docs/connect/config-entries/service-resolver) - matches
   service instances with a specific Connect upstream discovery requests

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/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/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.    
 

website/content/docs/connect/config-entries/service-intentions.mdx

@@ -7,7 +7,7 @@ description: >-
 
 # Service intentions configuration entry reference
 
-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/intentions) for additional information.
+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.
 
 ## Configuration model
 

website/content/docs/connect/connect-internals.mdx

@@ -39,7 +39,7 @@ The destination service verifies the client certificate against the [public CA
 bundle](/consul/api-docs/connect/ca#list-ca-root-certificates). After verifying the
 certificate, the next step depends upon the configured application protocol of
 the destination service. TCP (L4) services must authorize incoming _connections_
-against the configured set of Consul [intentions](/consul/docs/connect/intentions/intentions),
+against the configured set of Consul [intentions](/consul/docs/connect/intentions),
 whereas HTTP (L7) services must authorize incoming _requests_ against those same
 intentions. If the intention check responds successfully, the
 connection/request is established. Otherwise the connection/request is
@@ -98,7 +98,7 @@ A sidecar proxy's [upstream configuration](/consul/docs/connect/registration/ser
 may specify an alternative datacenter or a prepared query that can address services
 in multiple datacenters (such as the [geo failover](/consul/tutorials/developer-discovery/automate-geo-failover) pattern).
 
-[Intentions](/consul/docs/connect/intentions/intentions) verify connections between services by
+[Intentions](/consul/docs/connect/intentions) verify connections between services by
 source and destination name seamlessly across datacenters.
 
 Connections can be made via gateways to enable communicating across network

website/content/docs/connect/dev.mdx

@@ -15,7 +15,7 @@ for this task on any machine with access to a Consul agent (local or remote).
 
 Restricting access to services only via Connect ensures that the only way to
 connect to a service is through valid authorization of the
-[intentions](/consul/docs/connect/intentions/intentions). This can extend to developers
+[intentions](/consul/docs/connect/intentions). This can extend to developers
 and operators, too.
 
 ## Connecting to Connect-only Services

website/content/docs/connect/index.mdx

@@ -30,7 +30,7 @@ Review the video below to learn more about Consul Connect from HashiCorp's co-fo
 Consul service mesh enables secure deployment best-practices with automatic
 service-to-service encryption, and identity-based authorization.
 Consul uses the registered service identity, rather than IP addresses, to
-enforce access control with [intentions](/consul/docs/connect/intentions/intentions). This
+enforce access control with [intentions](/consul/docs/connect/intentions). This
 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

website/content/docs/connect/proxies/envoy.mdx

@@ -92,7 +92,7 @@ responsibility for correctly configuring Envoy and ensuring version support etc.
 
 ## Intention Enforcement
 
-[Intentions](/consul/docs/connect/intentions/intentions) are enforced using Envoy's RBAC filters. Depending on the
+[Intentions](/consul/docs/connect/intentions) are enforced using Envoy's RBAC filters. Depending on the
 configured [protocol](/consul/docs/connect/config-entries/service-defaults#protocol) of the proxied service, intentions are either enforced
 per-connection (L4) using a network filter, or per-request (L7) using an HTTP
 filter.

website/content/docs/connect/security.mdx

@@ -31,7 +31,7 @@ of Consul.
 Consul must be configured to use ACLs with a default deny policy. This forces
 all requests to have explicit anonymous access or provide an ACL token. The
 configuration also forces all service-to-service communication to be explicitly
-allowed via an allow [intention](/consul/docs/connect/intentions/intentions).
+allowed via an allow [intention](/consul/docs/connect/intentions).
 
 To learn how to enable ACLs, please see the
 [tutorial on ACLs](/consul/tutorials/security/access-control-setup-production).

website/content/docs/connect/transparent-proxy.mdx

@@ -40,7 +40,7 @@ Your network must meet the following environment and software requirements to us
 * Transparent proxy is available for Kubernetes environments.
 * Consul 1.10.0+
 * Consul Helm chart 0.32.0+. If you want to use the Consul CNI plugin to redirect traffic, Helm chart 0.48.0+ is required. Refer to [Enable the Consul CNI plugin](#enable-the-consul-cni-plugin) for additional information.
-* [Service intentions](/consul/docs/connect/intentions/intentions) must be configured to allow communication between intended services.
+* [Service intentions](/consul/docs/connect/intentions) must be configured to allow communication between intended services.
 * The `ip_tables` kernel module must be running on all worker nodes within a Kubernetes cluster. If you are using the `modprobe` Linux utility, for example, issue the following command:
 
   `$ modprobe ip_tables`

website/content/docs/k8s/connect/index.mdx

@@ -165,7 +165,7 @@ spec:
 By default when ACLs are enabled or when ACLs default policy is `allow`,
 Consul will automatically configure proxies with all upstreams from the same datacenter.
 When ACLs are enabled with default `deny` policy,
-you must supply an [intention](/consul/docs/connect/intentions/intentions) to tell Consul which upstream you need to talk to.
+you must supply an [intention](/consul/docs/connect/intentions) to tell Consul which upstream you need to talk to.
 
 When upstreams are specified explicitly with the
 [`consul.hashicorp.com/connect-service-upstreams` annotation](/consul/docs/k8s/annotations-and-labels#consul-hashicorp-com-connect-service-upstreams),
@@ -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/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/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.
@@ -536,7 +536,7 @@ There are three options available:
 
 When [transparent proxy](/consul/docs/connect/transparent-proxy) is enabled and ACLs are disabled,
 the upstreams will be configured automatically across Consul namespaces.
-When ACLs are enabled, you must configure it by specifying an [intention](/consul/docs/connect/intentions/intentions),
+When ACLs are enabled, you must configure it by specifying an [intention](/consul/docs/connect/intentions),
 allowing services across Consul namespaces to talk to each other.
 
 If you wish to specify an upstream explicitly via the `consul.hashicorp.com/connect-service-upstreams` annotation,

website/content/docs/k8s/connect/ingress-gateways.mdx

@@ -153,7 +153,7 @@ If TLS is enabled, use [https://localhost:8501/ui/dc1/services/ingress-gateway/i
 
 ## Defining an Intention
 
-If ACLs are enabled (via the `global.acls.manageSystemACLs` setting), you must define an [intention](/consul/docs/connect/intentions/intentions)
+If ACLs are enabled (via the `global.acls.manageSystemACLs` setting), you must define an [intention](/consul/docs/connect/intentions)
 to allow the ingress gateway to route to the upstream services defined in the `IngressGateway` resource (in the example above the upstream service is `static-server`).
 
 To create an intention that allows the ingress gateway to route to the service `static-server`, create a [`ServiceIntentions`](/consul/docs/connect/config-entries/service-intentions)

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/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:
 

website/content/docs/troubleshoot/troubleshoot-services.mdx

@@ -42,7 +42,7 @@ For more information about using Envoy proxies with Consul, refer to [Envoy prox
 
 When troubleshooting service-to-service communication issues, be aware of the following constraints:
 
-- The troubleshooting tool does not check service intentions. For more information about intentions, including precedence and match order, refer to [service mesh intentions](/consul/docs/connect/intentions/intentions).
+- The troubleshooting tool does not check service intentions. For more information about intentions, including precedence and match order, refer to [service mesh intentions](/consul/docs/connect/intentions).
 - The troubleshooting tool validates one direct connection between a downstream service and an upstream service. You must run the `consul troubleshoot` command with the Envoy ID for an individual upstream service. It does support validating multiple connections simultaneously.
 - The troubleshooting tool only validates Envoy configurations for sidecar proxies. As a result, the troubleshooting tool does not validate Envoy configurations on upstream proxies such as mesh gateways and terminating gateways.
 

website/content/docs/upgrading/upgrade-specific.mdx

@@ -624,7 +624,7 @@ namespace with a query parameter of `?ns=*`.
 #### Migration
 
 Upgrading to Consul 1.9.0 will trigger a one-time background migration of
-[intentions](/consul/docs/connect/intentions/intentions) into an equivalent set of
+[intentions](/consul/docs/connect/intentions) into an equivalent set of
 [`service-intentions`](/consul/docs/connect/config-entries/service-intentions) config
 entries. This process will wait until all of the Consul servers in the primary
 datacenter are running Consul 1.9.0+.