From 656df780ee1b6ca76df7eb5da16b27e8d1426954 Mon Sep 17 00:00:00 2001
From: Luke Kysow <1034429+lkysow@users.noreply.github.com>
Date: Wed, 9 Nov 2022 10:26:10 -0800
Subject: [PATCH] Add description for anon token policy (#15311)

---
 .../multi-cluster/vms-and-kubernetes.mdx      | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx
index a0530d8e1..09a07a001 100644
--- a/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx
+++ b/website/content/docs/k8s/deployment-configurations/multi-cluster/vms-and-kubernetes.mdx
@@ -258,6 +258,51 @@ You'll need:
      }
    }
    ```
+1. If ACLs are enabled you'll also need to modify the [anonymous token](/consul/docs/security/acl/acl-tokens#anonymous-token) policy to have the following permissions:
+
+   ```hcl
+   node_prefix "" {
+      policy = "read"
+   }
+   service_prefix "" {
+      policy = "read"
+   }
+   ```
+
+   With Consul Enterprise, use:
+   
+   ```hcl
+   partition_prefix "" {
+     namespace_prefix "" {
+       node_prefix "" {
+         policy = "read"
+       }
+       service_prefix "" {
+         policy = "read"
+       }
+     }
+   }
+   ```
+   
+   These permissions are needed to allow cross-datacenter requests. To make a cross-dc request the sidecar proxy in the originating DC needs to know about the
+   services running in the remote DC. To do so, it needs an ACL token that allows it to look up the services in the remote DC. The way tokens are created in
+   Kubernetes, the sidecar proxies have local ACL tokens–i.e tokens that are only valid in the local DC. When a request goes from one DC to another, if the
+   request has a local token, it is stripped from the request because the remote DC won't be able to validate it. When the request lands in the other DC,
+   it has no ACL token and so will be subject to the anonymous token policy. This is why the anonymous token policy must be configured to allow read access
+   to all services. When the Kubernetes DC is the primary, this is handled automatically, but when the primary DC is on VMs, this must be configured manually.
+   
+   To configure the anonymous token policy, first create a policy with the above rules, then attach it to the anonymous token. For example using the CLI:
+   
+   ```sh
+   echo 'node_prefix "" {
+      policy = "read"
+   }
+   service_prefix "" {
+      policy = "read"
+   }' | consul acl policy create -name anonymous -rules -
+   
+   consul acl token update -id 00000000-0000-0000-0000-000000000002 -policy-name anonymous
+   ```
 
 1. If gossip encryption is enabled, you'll need the key.