From e09744adde0dd8600c26d79bf6e6ea56d919f08e Mon Sep 17 00:00:00 2001
From: trujillo-adam <ajosetru@gmail.com>
Date: Wed, 3 Nov 2021 15:16:42 -0700
Subject: [PATCH 1/3] changed 'segments' in this page to 'resource labels' to
 disambiguate from 'network segments'

---
 .../content/docs/security/acl/acl-rules.mdx   | 147 ++++++++----------
 1 file changed, 69 insertions(+), 78 deletions(-)

diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx
index 3063be0189..fd86af65d6 100644
--- a/website/content/docs/security/acl/acl-rules.mdx
+++ b/website/content/docs/security/acl/acl-rules.mdx
@@ -24,26 +24,26 @@ ACL rules describe the level of access to resources. A rule is composed of a res
 }
 ```
 
-### Segments
+### Resource Labels
  
-Many resources take an additional value that limits the scope of the rule to a resource _segment_. A resource segment can be the name of a specific set of resources, such as nodes configured with the same `name` value. 
+Many resources take an additional value that limits the scope of the rule to resources with the same label. A resource label can be the name of a specific set of resources, such as nodes configured with the same `name` value. 
 
-The following syntax describes how to include a resource segment in the rule:
+The following syntax describes how to include a resource label in the rule:
 
 ```hcl
-<resource> "<segment>" {
+<resource> "<label>" {
   policy = "<policy disposition>"
 }
 ``` 
 
-Segmentation provides operators with more granular control over access to the resouce. Some resources, however, do not take a segment value. The following resource areas _can not_ be segmented:
+Labels provide operators with more granular control over access to the resouce, but the following resource types do not take a label:
  
 * `acl`  
 * `keyring` 
 * `mesh`
 * `operator` 
 
-Use the following syntax to create rules for non-segmented resources: 
+Use the following syntax to create rules for these resources: 
 
 ```hcl
 <resource> = "<policy disposition>"
@@ -57,20 +57,20 @@ Use the `policy` keyword and one of the following access levels to set a policy
 - `write`: Allows the resource to be read and modified.
 - `deny`: Denies access to the resource.
 
-You can also use a special `list` access level to allows access to all keys under a segment in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`.
+The special `list` access level provices access to all keys with the specified resource label in the Consul KV. The `list` access level can only be used with the `key_prefix` resource. The [`acl.enable_key_list_policy`](/docs/agent/options#acl_enable_key_list_policy) setting must be set to `true`.
 
 ### Matching and Prefix Values
 
-You can define rules for resource segments based on exact matches or by using resource prefixes to match several resource segments beginning with the same value. Matching segments on exact values is described in the [Segments](#segments) section.  
+You can define rules for labeled resources based on exact matches or by using resource prefixes to match several resource labels beginning with the same value. Matching resource labels on exact values is described in the [Resource Labels](#resource-labels) section.  
 
-The following example rule is an exact match that denies access to `web-prod` service segments:
+The following example rule is an exact match that denies access to services labeled `web-prod`:
 
 ```hcl
 service "web-prod" {
   policy = "deny"
 }
 ```
-You can append the resource with `_prefix` to match all resource segments beginning with the same value. The following example rule allows `write` access to all service segments that begin with "web":
+You can append the resource with `_prefix` to match all resource labels beginning with the same value. The following example rule allows `write` access to all services with labels that begin with "web":
 
 ```hcl
 service_prefix "web" {
@@ -78,7 +78,7 @@ service_prefix "web" {
 }
 ```
 
-Prefix-based resource segments can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows `read` access to all `service` resources:
+Prefix-based resource labels can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows `read` access to all `service` resources:
 
 ```hcl
 service_prefix "" {
@@ -88,7 +88,7 @@ service_prefix "" {
 
 When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, a combination of rules would be combined to create a flexible policy. Each team or business unit would use tokesn based on polcies that enforce several rules, for example: 
 
-* A rule that denies access to a specific resource segment
+* A rule that denies access to a specific resource label
 * A prefix-based rule that allows write access to a class of resources 
 * An empty prefix that grants read-only access to all resource within the declared class 
 
@@ -202,7 +202,7 @@ This will grant the rules provided to the [bearer of that token](/api#authentica
 
 The following table provides an overview of the resources you can use to create ACL rules.
 
-| Resource                      | Description                                                                                                                                              | Segments |
+| Resource                      | Description                                                                                                                                              | Labels |
 |-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|----------|
 | `acl`                         | Controls access to ACL operations in the [ACL API](/api/acl/acl). <br/>See [ACL Resource Rules](#acl-resource-rules) for details.                        | No       |
 | `admin_partition`<br/>`admin_partition_prefix` | <EnterpriseAlert inline /> Controls access to one or more admin partitions. <br/>See [Admin Partition Rules](#admin-partition-rules) for details. | Yes      |
@@ -210,7 +210,7 @@ The following table provides an overview of the resources you can use to create
 | `event`<br/>`event_prefix`    | Controls access to event operations in the [Event API](/api/event), such as firing and listing events. <br/>See [Event Rules](#event-rules) for details. | Yes      |
 | `key`<br/>`key_prefix` &nbsp; | Controls access to key/value store operations in the [KV API](/api/kv). <br/>Can also use the `list` access level when setting the policy disposition. <br/>Has additional value options in Consul Enterprise for integrating with [Sentinel](https://docs.hashicorp.com/sentinel/consul).  <br/>See [Key/Value Rules](#key-value-rules) for details. | Yes      |
 | `keyring` &nbsp; &nbsp; &nbsp; | Controls access to keyring operations in the [Keyring API](/api/keyring). <br/>See [Keyring Rules](#keyring-rules) for details. | No      |
-| `mesh` &nbsp; &nbsp; &nbsp; | Provides operator-level permissions for resources in the admin partition, such as ingress gateways or mesh proxy defaults. See [Mesh Rules](#mesh-rulres) for details.  | No      |
+| `mesh` &nbsp; &nbsp; &nbsp; | Provides operator-level permissions for resources in the admin partition, such as ingress gateways or mesh proxy defaults. See [Mesh Rules](#mesh-rules) for details.  | No      |
 | `namespace`<br/>`namespace_prefix` | <EnterpriseAlert inline /> Controls access to one or more namespaces. <br/>See [Namespace Rules](#namespace-rules) for details. | Yes      |
 | `node`<br/>`node_prefix` &nbsp; | Controls access to node-level registration and read access to the [Catalog API](/api/catalog). <br/>See [Node Rules](#node-rules) for details. | Yes      |
 | `operator` &nbsp; &nbsp; &nbsp; | Controls access to cluster-level operations available in the [Operator API](/api/operator) excluding keyring API endpoints. <br/>See [Operator Rules](#operator-rules) for details. | No      |
@@ -226,7 +226,7 @@ The `acl` resource controls access to ACL operations in the [ACL API](/api/acl/a
 
 The `acl = "write"` rule is also required to create snapshots. This is because all token secrets are contained within the snapshot.
 
-Rules for ACL resources are non-segmented. 
+Rules for ACL resources do not use labels. 
 
 In the following example, `write` access to the ACL API. The rule enables the operator to read or write ACLs, as well as discover the secret ID of any token. 
 
@@ -307,7 +307,7 @@ event "deploy" {
 }
 ```
 
-Event rules are segmented by the event name they apply to. In the example above, the rules allow
+Event rules are labeled with the event name they apply to. In the example above, the rules allow
 read-only access to any event, and firing of the "deploy" event.
 
 The [`consul exec`](/commands/exec) command uses events with the "\_rexec" prefix during
@@ -332,7 +332,7 @@ key "bar" {
 }
 ```
 
-Key rules are segmented by the key name they apply to. In the example above, the rules allow read-only access
+Key rules are labeled with the key name they apply to. In the example above, the rules allow read-only access
 to any key name with the empty prefix rule, allow read-write access to the "foo" key, and deny access to the "bar" key.
 
 #### List Policy for Keys
@@ -396,10 +396,13 @@ dispositions. In the example above, the keyring may be read and updated.
 
 ### Mesh Rules
 
-The `mesh` resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. 
+The `mesh` resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. The following rule grants read and write access:
 
-See [Admin Partition Rules](#admin-partition-rules) for an example rule that uses the `mesh` resource. 
- 
+```hcl
+mesh = "write"
+```
+
+See [Admin Partition Rules](#admin-partition-rules) for another example rule that uses the `mesh` resource.  
 
 ### Namespace Rules <EnterpriseAlert inline />
 
@@ -421,13 +424,15 @@ namespace_prefix "" {
   node_prefix "" {
     policy = "read"
   }
+  # grants permission to create and edit all namespace
+   policy = "write"  
 }
 
 namespace "foo" {
   # grants permission to manage ACLs only for the foo namespace
   acl = "write"
 
-  # grants permission to rename the foo namespace
+  # grants permission to create and edit the foo namespace
   policy = "write"
 
   # grants write permissions to the KV for namespace foo
@@ -475,11 +480,16 @@ specific namespace are prevented from accessing resources in another namespace.
 
 ### Node Rules
 
-The `node` and `node_prefix` resources controls node-level registration and read access to the [Catalog API](/api/catalog),
-service discovery with the [Health API](/api/health), and filters results in [Agent API](/api/agent)
-operations like fetching the list of cluster members.
+The `node` and `node_prefix` resources control access to the following API behaviors:
 
-Node rules look like this:
+* node-level registration and read access to the [Catalog API](/api/catalog)
+* service discovery with the [Health API](/api/health) 
+* filtering results in [Agent API](/api/agent) operations, such as fetching the list of cluster members.
+
+You can use resource labels to scope the rule to a specific resource or set of resources.
+
+The following example rule uses an empty prefix label, which provides read-only access to all nodes. 
+The rule also provides read-write access to the `app` node and denies all access to the `admin` node:
 
 ```hcl
 node_prefix "" {
@@ -493,41 +503,30 @@ node "admin" {
 }
 ```
 
-Node rules are segmented by the node name they apply to. In the example above, the rules allow read-only access to any node name with the empty prefix, allow
-read-write access to the "app" node, and deny all access to the "admin" node.
+#### Registering and Querying Node Information
 
-Agents need to be configured with an [`acl.tokens.agent`](/docs/agent/options#acl_tokens_agent)
-with at least "write" privileges to their own node name in order to register their information with
-the catalog, such as node metadata and tagged addresses. If this is configured incorrectly, the agent
-will print an error to the console when it tries to sync its state with the catalog.
+Agents must be configured with `write` or `read` privileges for their own node name so that the agent can register their node metadata, tagged addresses, and other information in the catalog. 
+If configured incorrectly, the agent will print an error to the console when it tries to sync its state with the catalog.
+Configure `write` or `read` access in the [`acl.tokens.agent`](/docs/agent/options#acl_tokens_agent) parameter.  
 
-Consul's DNS interface is also affected by restrictions on node rules. If the
-[`acl.token.default`](/docs/agent/options#acl_tokens_default) used by the agent does not have "read" access to a
-given node, then the DNS interface will return no records when queried for it.
+The [`acl.token.default`](/docs/agent/options#acl_tokens_default) used by the agent should have `read` access to a given node so that the DNS interface can be queried.
 
-When reading from the catalog or retrieving information from the health endpoints, node rules are
-used to filter the results of the query. This allows for configurations where a token has access
-to a given service name, but only on an allowed subset of node names.
+Node rules are used to filter query results when reading from the catalog or retrieving information from the health endpoints. This allows for configurations where a token has access to a given service name, but only on an allowed subset of node names.
 
-Node rules come into play when using the [Agent API](/api/agent) to register node-level
-checks. The agent will check tokens locally as a check is registered, and Consul also performs
-periodic [anti-entropy](/docs/internals/anti-entropy) syncs, which may require an
-ACL token to complete. To accommodate this, Consul provides two methods of configuring ACL tokens
-to use for registration events:
+Consul agents check tokens locally when health checks are registered and when Consul performs periodic [anti-entropy](/docs/internals/anti-entropy) syncs.
+These actions may required an ACL token to complete. Use the following methods to configure ACL tokens for registration events:
 
-1. Using the [acl.tokens.default](/docs/agent/options#acl_tokens_default) configuration
-   directive. This allows a single token to be configured globally and used
-   during all check registration operations.
-2. Providing an ACL token with service and check definitions at
-   registration time. This allows for greater flexibility and enables the use
-   of multiple tokens on the same agent. Examples of what this looks like are
-   available for both [services](/docs/agent/services) and
-   [checks](/docs/agent/checks). Tokens may also be passed to the
-   [HTTP API](/api) for operations that require them.
+* Configure a global token in the [acl.tokens.default](/docs/agent/options#acl_tokens_default) parameter. 
+This allows a single token to be used during all check registration operations.
+* Provide an ACL token with service and check definitions at registration time. 
+This allows for greater flexibility and enables the use of multiple tokens on the same agent. 
+Refer to the [services](/docs/agent/services) and [checks](/docs/agent/checks) documentation for examples.
+Tokens may also be passed to the [HTTP API](/api) for operations that require them.
 
-In addition to ACLs, in Consul 0.9.0 and later, the agent must be configured with
-[`enable_script_checks`](/docs/agent/options#_enable_script_checks) set to `true` in order to enable
-script checks.
+
+-> **Script checks are required for Consul 0.9.0 and later**. In addition to ACLs, the agent must be configured with
+[`enable_script_checks`](/docs/agent/options#_enable_script_checks) set to `true` to enable
+script checks in Consul 0.9.0 and later0.
 
 ### Operator Rules
 
@@ -547,10 +546,9 @@ diagnostic purposes but not make any changes.
 ### Prepared Query Rules
 
 The `query` and `query_prefix` resources control access to create, update, and delete prepared queries in the
-[Prepared Query API](/api/query). Executing queries is subject to `node`/`node_prefix` and `service`/`service_prefix`
-policies, as will be explained below.
-
-Query rules look like this:
+[Prepared Query API](/api/query). Specify the resource label in query rules to determine the scope of the rule. 
+The resource label in the following example is empty. As a result, the rules allow read-only access to query resources with any name. 
+The rules also grant read-write access to the query named `foo`, which allows control of the query namespace to be delegated based on ACLs:
 
 ```hcl
 query_prefix "" {
@@ -561,9 +559,8 @@ query "foo" {
 }
 ```
 
-Query rules are segmented by the query name they apply to. In the example above, the rules allow read-only
-access to any query name with the empty prefix, and allow read-write access to the query named "foo".
-This allows control of the query namespace to be delegated based on ACLs.
+Executing queries is subject to `node`/`node_prefix` and `service`/`service_prefix`
+policies.
 
 There are a few variations when using ACLs with prepared queries, each of which uses ACLs in one of two
 ways: open, protected by unguessable IDs or closed, managed by ACL policies. These variations are covered
@@ -618,8 +615,8 @@ Capturing ACL Tokens is analogous to
 `SECURITY DEFINER` attribute which can be set on functions, and using the client's ACL
 Token is similar to the complementary `SECURITY INVOKER` attribute.
 
-Prepared queries were originally introduced in Consul 0.6.0, and ACL behavior remained
-unchanged through version 0.6.3, but was then changed to allow better management of the
+Prepared queries were originally introduced in Consul 0.6.0. The ACL behavior remained
+unchanged through version 0.6.3, but versions after 0.6.3 included changes that improve management of the
 prepared query namespace.
 
 These differences are outlined in the table below:
@@ -635,10 +632,10 @@ These differences are outlined in the table below:
 
 ### Service Rules
 
-The `service` and `service_prefix` resources control service-level registration and read access to the [Catalog API](/api/catalog)
-and service discovery with the [Health API](/api/health).
-
-Service rules look like this:
+The `service` and `service_prefix` resources control service-level registration and read access to the [Catalog API](/api/catalog) and service discovery with the [Health API](/api/health). 
+Specify the resource label in service rules to set the scope of the rule. 
+The resource label in the following example is empty. As a result, the rules allow read-only access to any service name with the empty prefix. 
+The rules also allow read-write access to the `app` service and deny all access to the `admin` service:
 
 ```hcl
 service_prefix "" {
@@ -652,12 +649,8 @@ service "admin" {
 }
 ```
 
-Service rules are segmented by the service name they apply to. In the example above, the rules allow read-only
-access to any service name with the empty prefix, allow read-write access to the "app" service, and deny all
-access to the "admin" service.
-
 Consul's DNS interface is affected by restrictions on service rules. If the
-[`acl.tokens.default`](/docs/agent/options#acl_tokens_default) used by the agent does not have "read" access to a
+[`acl.tokens.default`](/docs/agent/options#acl_tokens_default) used by the agent does not have `read` access to a
 given service, then the DNS interface will return no records when queried for it.
 
 When reading from the catalog or retrieving information from the health endpoints, service rules are
@@ -706,7 +699,9 @@ for more information about managing intentions access with service rules.
 
 The `session` and `session_prefix` resources controls access to [Session API](/api/session) operations.
 
-Session rules look like this:
+Specify the resource label in session rules to set the scope of the rule. 
+The resource label in the following example is empty. As a result, the rules allow read-only access to all sessions. 
+The rules also allow creating sessions on the node named `app` and deny all access to any sessions on the `admin` node:
 
 ```hcl
 session_prefix "" {
@@ -718,8 +713,4 @@ session "app" {
 session "admin" {
   policy = "deny"
 }
-```
-
-Session rules are segmented by the node name they apply to. In the example above, the rules allow read-only
-access to sessions on node name with the empty prefix, allow creating sessions on the node named "app",
-and deny all access to any sessions on the "admin" node.
+```
\ No newline at end of file

From b4abd242e81c5639d4c1c4dcd52560c2724d6f60 Mon Sep 17 00:00:00 2001
From: trujillo-adam <ajosetru@gmail.com>
Date: Fri, 5 Nov 2021 09:30:28 -0700
Subject: [PATCH 2/3] applied feedback

---
 website/content/docs/agent/options.mdx          | 8 ++++----
 website/content/docs/security/acl/acl-rules.mdx | 9 ++-------
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/website/content/docs/agent/options.mdx b/website/content/docs/agent/options.mdx
index 305598721a..86e954bad7 100644
--- a/website/content/docs/agent/options.mdx
+++ b/website/content/docs/agent/options.mdx
@@ -228,6 +228,7 @@ The options below are all specified on the command-line.
   Like [`enable_script_checks`](#_enable_script_checks), but only enable them when
   they are defined in the local configuration files. Script checks defined in HTTP
   API registrations will still not be allowed.
+  
 
 - `-encrypt` ((#\_encrypt)) - Specifies the secret key to use for encryption
   of Consul network traffic. This key must be 32-bytes that are Base64-encoded. The
@@ -1468,10 +1469,9 @@ bind_addr = "{{ GetPrivateInterfaces | include \"network\" \"10.0.0.0/8\" | attr
 
 - `enable_script_checks` Equivalent to the [`-enable-script-checks` command-line flag](#_enable_script_checks).
 
-  ~> **Security Warning:** Enabling script checks in some configurations may
-  introduce a remote execution vulnerability which is known to be targeted by
-  malware. We strongly recommend `enable_local_script_checks` instead. See [this
-  blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
+  ACLs must be enabled for agents and the `enable_script_checks` option must be set to `true` to enable script checks in Consul 0.9.0 and later. See [Registering and Querying Node Information](/docs/security/acl/acl-rules#registering-and-querying-node-information) for related information.
+
+  ~> **Security Warning:** Enabling script checks in some configurations may introduce a known remote execution vulnerability targeted by malware. We strongly recommend `enable_local_script_checks` instead. Refer to the following article for additional guidance: [_Protecting Consul from RCE Risk in Specific Configurations_](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
   for more details.
 
 - `enable_local_script_checks` Equivalent to the [`-enable-local-script-checks` command-line flag](#_enable_local_script_checks).
diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx
index fd86af65d6..0abe9dd1df 100644
--- a/website/content/docs/security/acl/acl-rules.mdx
+++ b/website/content/docs/security/acl/acl-rules.mdx
@@ -505,9 +505,9 @@ node "admin" {
 
 #### Registering and Querying Node Information
 
-Agents must be configured with `write` or `read` privileges for their own node name so that the agent can register their node metadata, tagged addresses, and other information in the catalog. 
+Agents must be configured with `write` privileges for their own node name so that the agent can register their node metadata, tagged addresses, and other information in the catalog. 
 If configured incorrectly, the agent will print an error to the console when it tries to sync its state with the catalog.
-Configure `write` or `read` access in the [`acl.tokens.agent`](/docs/agent/options#acl_tokens_agent) parameter.  
+Configure `write` access in the [`acl.tokens.agent`](/docs/agent/options#acl_tokens_agent) parameter.  
 
 The [`acl.token.default`](/docs/agent/options#acl_tokens_default) used by the agent should have `read` access to a given node so that the DNS interface can be queried.
 
@@ -523,11 +523,6 @@ This allows for greater flexibility and enables the use of multiple tokens on th
 Refer to the [services](/docs/agent/services) and [checks](/docs/agent/checks) documentation for examples.
 Tokens may also be passed to the [HTTP API](/api) for operations that require them.
 
-
--> **Script checks are required for Consul 0.9.0 and later**. In addition to ACLs, the agent must be configured with
-[`enable_script_checks`](/docs/agent/options#_enable_script_checks) set to `true` to enable
-script checks in Consul 0.9.0 and later0.
-
 ### Operator Rules
 
 The `operator` resource controls access to cluster-level operations in the

From 9333fad1e3a335e958231fc774a9de7fe9b57c9f Mon Sep 17 00:00:00 2001
From: trujillo-adam <ajosetru@gmail.com>
Date: Tue, 9 Nov 2021 18:19:04 -0800
Subject: [PATCH 3/3] added json versions for all hcl examples

---
 .../content/docs/security/acl/acl-rules.mdx   | 531 ++++++++++++++++--
 1 file changed, 494 insertions(+), 37 deletions(-)

diff --git a/website/content/docs/security/acl/acl-rules.mdx b/website/content/docs/security/acl/acl-rules.mdx
index 0abe9dd1df..311b401ba8 100644
--- a/website/content/docs/security/acl/acl-rules.mdx
+++ b/website/content/docs/security/acl/acl-rules.mdx
@@ -18,24 +18,56 @@ This topic describes how to configure rules for Consul's access control list (AC
 
 ACL rules describe the level of access to resources. A rule is composed of a resource declaration and an access level defined with the `policy` keyword and a [policy disposition](#policy-dispositions). The following syntax describes the basic structure of a rule:
 
+<CodeTabs heading="Basic syntax for configuring an ACL rule">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 <resource> {
   policy = "<policy disposition>"
-}
+  }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"<resource>": [{
+  "policy": "<policy disposition>" 
+  }]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
 ### Resource Labels
  
 Many resources take an additional value that limits the scope of the rule to resources with the same label. A resource label can be the name of a specific set of resources, such as nodes configured with the same `name` value. 
 
 The following syntax describes how to include a resource label in the rule:
 
+<CodeTabs heading="Syntax for applying an ACL rule to named resources">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 <resource> "<label>" {
   policy = "<policy disposition>"
 }
 ``` 
 
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"<resource>": [{
+  "<label>": [{ 
+    "policy": "<policy disposition>"
+  }]
+}]
+``` 
+
+</CodeBlockConfig>
+</CodeTabs>
+
 Labels provide operators with more granular control over access to the resouce, but the following resource types do not take a label:
  
 * `acl`  
@@ -45,10 +77,23 @@ Labels provide operators with more granular control over access to the resouce,
 
 Use the following syntax to create rules for these resources: 
 
+<CodeTabs heading="Syntax for resources that take ACL rule configurations directly">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 <resource> = "<policy disposition>"
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"<resource>": "<policy disposition>"
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
 ### Policy Dispositions
 
 Use the `policy` keyword and one of the following access levels to set a policy disposition:
@@ -65,26 +110,74 @@ You can define rules for labeled resources based on exact matches or by using re
 
 The following example rule is an exact match that denies access to services labeled `web-prod`:
 
+<CodeTabs heading="Example rule that denies access to services named 'web-prod'">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 service "web-prod" {
   policy = "deny"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"service": [{
+  "web-prod" : [{
+    "policy" : "deny"
+  }]
+}]
+```
+</CodeBlockConfig>
+</CodeTabs>
+
 You can append the resource with `_prefix` to match all resource labels beginning with the same value. The following example rule allows `write` access to all services with labels that begin with "web":
 
+<CodeTabs heading="Example rule that grants read and write access to services with names beginning with 'web'">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 service_prefix "web" {
   policy = "write"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"service_prefix": [{
+  "web" : [{
+    "policy" : "write"
+  }]
+}] 
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 Prefix-based resource labels can also contain an empty string, which configures the rule to apply to all resources of the declared type. The following example rule allows `read` access to all `service` resources:
 
+<CodeTabs heading="Example rule that grants read access to all services">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 service_prefix "" {
   policy = "read"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"service_prefix" : [{
+  "" : [{
+  "policy" :"read"
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 When using prefix-based rules, the most specific prefix match determines the action. In a real-world scenario, a combination of rules would be combined to create a flexible policy. Each team or business unit would use tokesn based on polcies that enforce several rules, for example: 
 
@@ -105,9 +198,10 @@ Exact matching rules will only apply to the exact resource specified. The order
 Define rules using the
 [HashiCorp Configuration Language (HCL)](https://github.com/hashicorp/hcl/). 
 HCL is human readable and interoperable with JSON, making it easy to automate rule generation. 
-The following examples show the same rule formatted in HCL and JSON:
+The following examples show the same rules formatted in HCL and JSON:
 
-#### HCL
+<CodeTabs heading="Example rules">
+<CodeBlockConfig lineNumbers>
 
 ```hcl
 # These control access to the key/value store.
@@ -129,30 +223,50 @@ key "foo/bar/secret" {
 operator = "read"
 ```
 
-#### JSON
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
 
 ```json
 {
-  "key_prefix": {
-    "": {
-      "policy": "read"
-    },
-    "foo/": {
-      "policy": "write"
-    },
-    "foo/private/": {
-      "policy": "deny"
+  "key": [
+    {
+      "foo/bar/secret": [
+        {
+          "policy": "deny"
+        }
+      ]
     }
-  },
-  "key": {
-    "foo/bar/secret": {
-      "policy": "deny"
+  ],
+  "key_prefix": [
+    {
+      "": [
+        {
+          "policy": "read"
+        }
+      ]
+    },
+    {
+      "foo/": [
+        {
+          "policy": "write"
+        }
+      ]
+    },
+    {
+      "foo/private/": [
+        {
+          "policy": "deny"
+        }
+      ]
     }
-  },
+  ],
   "operator": "read"
 }
 ```
 
+</CodeBlockConfig>
+</CodeTabs>
+
 ## Defining Rules with the ACL API
 
 You can configure ACLs remotely by calling the ACL HTTP API endpoint and including rules in the payload. The endpoint takes data formatted in HCL or JSON. Refer to the [ACL HTTP API endpoint documentation](/api/acl/acl) for details about the API.
@@ -230,10 +344,23 @@ Rules for ACL resources do not use labels.
 
 In the following example, `write` access to the ACL API. The rule enables the operator to read or write ACLs, as well as discover the secret ID of any token. 
 
+<CodeTabs heading="Example acl rule">
+<CodeBlockConfig>
+
 ```hcl
 acl = "write"
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"acl" : "write"
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
 ### Admin Partition Rules <EnterpriseAlert inline />
 
 The `admin_partition` and `admin_partition_prefix` resource controls access to one or more admin partitions. 
@@ -242,6 +369,9 @@ You can include any number of namespace rules inside the admin partition.
 In the following example, the agent has write access to the `ex-namespace` namespace, as well as namespaces prefixed with `ex-` in the `example` partition.
 The `mesh` resource is also scoped to the admin partition rule, which grants `write` access to mesh-level resources in the partition:
 
+<CodeTabs heading="Example admin partition rules">
+<CodeBlockConfig lineNumbers>
+
 ```hcl
 admin_partition "example" {  
   mesh = "write"
@@ -261,13 +391,66 @@ admin_partition_prefix "ex-" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+{
+  "admin_partition": [{
+	"example": [{
+	  "mesh": "write",
+	  "node": [{
+		"my-node": [{
+		  "policy": "write"
+		}],
+		"namespace": [{
+		  "ex-namespace": [{
+			"policy": "read"
+		  }]
+		}],
+		"namespace_prefix": [{
+		  "exns-": [{
+			"policy": "read"
+		  }]
+		}]
+	  }]
+	}]
+  }]
+},
+{
+  "admin_partition_prefix": [{
+	  "": [{
+		  "policy": "read"
+	  }],
+	  "example": [{
+		"mesh": "read",
+		"node": [{
+		  "my-node": [{
+			  "policy": "read"
+		  }]
+		}],
+		"namespace": [{
+		  "ex-namespace": [{
+			  "policy": "read"
+		   }]
+		  }]
+	  }]
+	}]
+}
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
+
 ### Agent Rules
 
 The `agent` and `agent_prefix` resources control access to the utility operations in the [Agent API](/api/agent),
 such as join and leave. All of the catalog-related operations are covered by the [`node` or `node_prefix`](#node-rules)
 and [`service` or `service_prefix`](#service-rules) policies instead.
 
-Agent rules look like this:
+<CodeTabs heading="Example agent rules">
+<CodeBlockConfig lineNumbers>
 
 ```hcl
 agent_prefix "" {
@@ -281,6 +464,28 @@ agent_prefix "bar" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig lineNumbers>
+
+```json
+"agent_prefix" : [{
+  "" : [{
+    "policy" : "read"
+    }],
+  "bar" : [{
+    "policy" : "deny"
+    }]
+  }],
+"agent" : [{
+  "foo" : [{
+    "policy" : "write"
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
 Agent rules are keyed by the node name they apply to. In the example above the rules
 allow read-only access to any node name by using the empty prefix, read-write access to
 the node with the _exact_ name `foo`, and denies all access to any node name that starts
@@ -296,7 +501,8 @@ write access to these operations even if no ACL resolution capability is availab
 The `event` and `event_prefix` resources control access to event operations in the [Event API](/api/event), such as
 firing events and listing events.
 
-Event rules look like this:
+<CodeTabs heading="Example event rules">
+<CodeBlockConfig>
 
 ```hcl
 event_prefix "" {
@@ -306,6 +512,24 @@ event "deploy" {
   policy = "write"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"event_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }]
+}],
+"event" : [{
+  "deploy" : [{
+    "policy" : "write"
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 Event rules are labeled with the event name they apply to. In the example above, the rules allow
 read-only access to any event, and firing of the "deploy" event.
@@ -317,8 +541,10 @@ give agents a token with access to this event prefix, in addition to configuring
 
 ### Key/Value Rules
 
-The `key` and `key_prefix` resources control access to key/value store operations in the [KV API](/api/kv). Key
-rules look like this:
+The `key` and `key_prefix` resources control access to key/value store operations in the [KV API](/api/kv). 
+
+<CodeTabs heading="Example key rules">
+<CodeBlockConfig>
 
 ```hcl
 key_prefix "" {
@@ -331,15 +557,38 @@ key "bar" {
   policy = "deny"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"key_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }]
+}],
+"key" : [{
+  "foo" : [{
+    "policy" : "write"
+  }],  
+  "bar" : [{
+    "policy" : "deny"
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 Key rules are labeled with the key name they apply to. In the example above, the rules allow read-only access
 to any key name with the empty prefix rule, allow read-write access to the "foo" key, and deny access to the "bar" key.
 
 #### List Policy for Keys
 
-Consul 1.0 introduces a new `list` policy for keys that is only enforced when opted in via the boolean config param "acl.enable_key_list_policy".
-`list` controls access to recursively list entries and keys, and enables more fine grained policies. With "acl.enable_key_list_policy",
-recursive reads via [the KV API](/api/kv#recurse) with an invalid token result in a 403. Example:
+Enable the `list` policy disposition (Consul 1.0+) by setting the `acl.enable_key_list_policy` parameter to `true`. The disposition provides recursive access to `key` entries. Refer to the [KV API](/api/kv#recurse) documentation for additional information. In the following example, `key` resources that start with `bar` are listed.
+
+
+<CodeTabs heading="Example 'key' rules">
+<CodeBlockConfig>
 
 ```hcl
 key_prefix "" {
@@ -355,6 +604,26 @@ key_prefix "baz" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"key_prefix" : [{
+  "" : [{
+    "policy" : "deny"
+  }],
+  "bar" : [{
+    "policy" : "list"
+  }],
+  "baz" : [{
+    "policy" : "read"    
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
+
 In the example above, the rules allow reading the key "baz", and only allow recursive reads on the prefix "bar".
 
 A token with `write` access on a prefix also has `list` access. A token with `list` access on a prefix also has `read` access on all its suffixes.
@@ -362,8 +631,7 @@ A token with `write` access on a prefix also has `list` access. A token with `li
 #### Sentinel Integration <EnterpriseAlert inline />
 
 Consul Enterprise supports additional optional fields for key write policies for
-[Sentinel](https://docs.hashicorp.com/sentinel/consul/) integration. An example key rule with a
-Sentinel code policy looks like this:
+[Sentinel](https://docs.hashicorp.com/sentinel/consul/) integration. 
 
 ```hcl
 key "foo" {
@@ -382,25 +650,43 @@ For more detailed information, see the [Consul Sentinel documentation](/docs/age
 
 ### Keyring Rules
 
-The `keyring` resource controls access to keyring operations in the
-[Keyring API](/api/operator/keyring).
+The `keyring` resource controls access to keyring operations in the [Keyring API](/api/operator/keyring). Only one keyring policy is allowed per rule set. The value is set to one of the policy dispositions, but may be read and updated.
 
-Keyring rules look like this:
+<CodeTabs heading="Example keyring rule">
+<CodeBlockConfig>
 
 ```hcl
 keyring = "write"
 ```
 
-There's only one keyring policy allowed per rule set, and its value is set to one of the policy
-dispositions. In the example above, the keyring may be read and updated.
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json 
+"keyring" : "write"
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 ### Mesh Rules
 
 The `mesh` resource controls access to ingress gateways, terminating gateways, and mesh configuration entries. The following rule grants read and write access:
 
+<CodeTabs heading="Example mesh rule">
+<CodeBlockConfig>
+
 ```hcl
 mesh = "write"
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json 
+"mesh" : "write"
+```
+</CodeBlockConfig>
+</CodeTabs>
 
 See [Admin Partition Rules](#admin-partition-rules) for another example rule that uses the `mesh` resource.  
 
@@ -412,6 +698,9 @@ The `namespace` and `namespace_prefix` resource controls access to Consul namesp
 
 The following examples describe how namespace rules can be defined in a policy:
 
+<CodeTabs heading="Example namespace rules">
+<CodeBlockConfig>
+
 ```hcl
 namespace_prefix "" {
 
@@ -456,6 +745,57 @@ namespace "foo" {
   }
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+{
+	"namespace": [{
+		"foo": [{
+			"acl": "write",
+			"key_prefix": [{
+				"": [{
+					"policy": "write"
+				}]
+			}],
+			"node_prefix": [{
+				"": [{
+					"policy": "read"
+				}]
+			}],
+			"policy": "write",
+			"service_prefix": [{
+				"": [{
+					"policy": "write"
+				}]
+			}],
+			"session_prefix": [{
+				"": [{
+					"policy": "write"
+				}]
+			}]
+		}]
+	}],
+	"namespace_prefix": [{
+		"": [{
+			"node_prefix": [{
+				"": [{
+					"policy": "read"
+				}]
+			}],
+			"policy": "write",
+			"service_prefix": [{
+				"": [{
+					"policy": "read"
+				}]
+			}]
+		}]
+	}]
+}
+```
+
+</CodeBlockConfig>
+</CodeTabs>
 
 #### Restrictions
 
@@ -491,6 +831,9 @@ You can use resource labels to scope the rule to a specific resource or set of r
 The following example rule uses an empty prefix label, which provides read-only access to all nodes. 
 The rule also provides read-write access to the `app` node and denies all access to the `admin` node:
 
+<CodeTabs heading="Example node rules">
+<CodeBlockConfig>
+
 ```hcl
 node_prefix "" {
   policy = "read"
@@ -503,6 +846,25 @@ node "admin" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"node_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }],
+  "app" : [{
+    "policy" : "write"
+  }],
+  "admin" : [{
+    "policy" : "deny"
+  }]
+}]
+```
+</CodeBlockConfig>
+</CodeTabs>
+
 #### Registering and Querying Node Information
 
 Agents must be configured with `write` privileges for their own node name so that the agent can register their node metadata, tagged addresses, and other information in the catalog. 
@@ -528,15 +890,24 @@ Tokens may also be passed to the [HTTP API](/api) for operations that require th
 The `operator` resource controls access to cluster-level operations in the
 [Operator API](/api/operator), other than the [Keyring API](/api/operator/keyring).
 
-Operator rules look like this:
+Only one operator rule allowed per rule set. In the following example, the token may be used to query the operator endpoints for
+diagnostic purposes but it will not make changes.
+
+<CodeTabs heading="Example operator rule">
+<CodeBlockConfig>
 
 ```hcl
 operator = "read"
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"operator" : "read"
+```
+</CodeBlockConfig>
+</CodeTabs>
 
-There's only one operator rule allowed per rule set, and its value is set to one of the policy
-dispositions. In the example above, the token could be used to query the operator endpoints for
-diagnostic purposes but not make any changes.
 
 ### Prepared Query Rules
 
@@ -545,6 +916,9 @@ The `query` and `query_prefix` resources control access to create, update, and d
 The resource label in the following example is empty. As a result, the rules allow read-only access to query resources with any name. 
 The rules also grant read-write access to the query named `foo`, which allows control of the query namespace to be delegated based on ACLs:
 
+<CodeTabs heading="Example query rules">
+<CodeBlockConfig>
+
 ```hcl
 query_prefix "" {
   policy = "read"
@@ -554,6 +928,24 @@ query "foo" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"query_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }]  
+}],
+"query" : [{
+  "foo" : [{
+    "policy" : "write"
+  }]
+}]
+```
+</CodeBlockConfig>
+</CodeTabs>
+
 Executing queries is subject to `node`/`node_prefix` and `service`/`service_prefix`
 policies.
 
@@ -632,6 +1024,9 @@ Specify the resource label in service rules to set the scope of the rule.
 The resource label in the following example is empty. As a result, the rules allow read-only access to any service name with the empty prefix. 
 The rules also allow read-write access to the `app` service and deny all access to the `admin` service:
 
+<CodeTabs heading="Example service rules">
+<CodeBlockConfig>
+
 ```hcl
 service_prefix "" {
   policy = "read"
@@ -643,6 +1038,26 @@ service "admin" {
   policy = "deny"
 }
 ```
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"service_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }]
+}],
+"service" : [{
+  "app" : [{
+    "policy" : "write"
+  }],
+  "admin" : [{
+    "policy" : "deny"
+  }]
+}]
+```
+</CodeBlockConfig>
+</CodeTabs>
 
 Consul's DNS interface is affected by restrictions on service rules. If the
 [`acl.tokens.default`](/docs/agent/options#acl_tokens_default) used by the agent does not have `read` access to a
@@ -680,6 +1095,9 @@ Service rules are also used to grant read or write access to intentions. The
 following policy provides read-write access to the "app" service, and explicitly
 grants `intentions:read` access to view intentions associated with the "app" service.
 
+<CodeTabs heading="Example service rule with intentions">
+<CodeBlockConfig>
+
 ```hcl
 service "app" {
   policy = "write"
@@ -687,6 +1105,20 @@ service "app" {
 }
 ```
 
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"service" : [{
+  "app" : [{
+    "policy" : "write"
+  }],
+  "intentions" : "read"
+}]
+```
+</CodeBlockConfig>
+</CodeTabs>
+
 Refer to [Intention Management Permissions](/docs/connect/intentions#intention-management-permissions)
 for more information about managing intentions access with service rules.
 
@@ -698,6 +1130,9 @@ Specify the resource label in session rules to set the scope of the rule.
 The resource label in the following example is empty. As a result, the rules allow read-only access to all sessions. 
 The rules also allow creating sessions on the node named `app` and deny all access to any sessions on the `admin` node:
 
+<CodeTabs heading="Example session rules">
+<CodeBlockConfig>
+
 ```hcl
 session_prefix "" {
   policy = "read"
@@ -708,4 +1143,26 @@ session "app" {
 session "admin" {
   policy = "deny"
 }
-```
\ No newline at end of file
+```
+
+</CodeBlockConfig>
+<CodeBlockConfig>
+
+```json
+"session_prefix" : [{
+  "" : [{
+    "policy" : "read"
+  }]
+}],
+"session" : [{
+  "app" : [{
+    "policy" : "write"
+  }],
+  "admin" : [{
+    "policy" : "deny"
+  }]
+}]
+```
+
+</CodeBlockConfig>
+</CodeTabs>
\ No newline at end of file