+
+
## Discoverable Resources
The vast majority of resources in Guardrails are created to represent resources in
diff --git a/docs/using/resources/index.md b/docs/using/resources/index.md
new file mode 100644
index 00000000..fa1c2c43
--- /dev/null
+++ b/docs/using/resources/index.md
@@ -0,0 +1,60 @@
+---
+title: Resources
+sidebar_label: Resources
+---
+
+# Resources
+
+**Resources** represent objects that are managed by Guardrails. Typically, these are
+mapped to resources in the cloud service, such as an AWS S3 bucket, a GCP
+compute instance, or an Azure SQL database. Information about Guardrails resources
+is stored in the CMDB.
+
+Once you [connect an integration](/guardrails/docs/guides), Guardrails will begin [discovering resources](#discovery-and-cmdb) and adding them to the CMDB.
+
+
+
+## Discovery and CMDB
+
+Discovery & CMDB controls are used in combination to find new resources and track changes to them over time.
+
+Discovery is Guardrails' method for automatically searching virtual infrastructure,
+systems or applications to build a structured, searchable data representation.
+For example, resources in an AWS Account are discovered and stored in Guardrails.
+
+Each resource type registers a `Discovery` control on it's parent type. The
+`Discovery` control is designed to find all instances of the resource types from
+the parent and upsert them into the Guardrails CMDB.
+
+The Resource type AWS > SQS > Queue defines a
+control AWS > SQS > Queue > Discovery with a target resource type of AWS > Region.
+
+
+In effect, the parent resource is responsible for creating its children.
+
+Discovered resources are always mapped to [Resource Types](#resource-types) and stored in the [Resource Hierarchy](#resource-hierarchy).
+
+
+Each resource type also registers a `CMDB` control on itself. The `CMDB` control
+queries the source for the latest and complete details about the resource.
+
+ The resource type AWS > SQS > Queue defines a
+control AWS > SQS > Queue > CMDB with a target resource type of AWS > SQS > Queue.
+
+
+In effect, a resource is considered to be an adult child, looking after itself.
+
+### Real-time Updates
+
+While Discovery and CMDB controls can find existing resources and update their details, Guardrails is designed to react in real-time to resource changes. Depending on the [integration](), you may have a choice between event handlers or event pollers for updating resources.
+
+- **Event Handlers** use the eventing system for the cloud provider to **push** updates to Turbot Guardrails whenever a create, update or delete event occurs. Event handlers typically require a bit more setup, but also more timely updates than polling.
+- **Event Pollers** query the events from the cloud providers audit log to **pull** updates in to Turbot Guardrails. Polling occurs at regular intervals. It is generally less timely than event handlers, but usually requires little to no configuration
+
+
+ The sqs.amazonaws.com:CreateQueue event is received by Guardrails and
+handled with an immediate CMDB upsert. This triggers the CMDB control for the new AWS > SQS > Queue resource, which then fetches full details using the AWS APIs.
+
+
+ The sqs.amazonaws.com:DeleteQueue event is received by Guardrails and handled with an immediate CMDB deletion. No further queries to the AWS APIs are required.
+
diff --git a/docs/concepts/resources/resource-hierarchy2.png b/docs/using/resources/resource-hierarchy2.png
similarity index 100%
rename from docs/concepts/resources/resource-hierarchy2.png
rename to docs/using/resources/resource-hierarchy2.png
diff --git a/docs/using/resources/resource_types_categories-ex.png b/docs/using/resources/resource_types_categories-ex.png
new file mode 100644
index 00000000..6b88144d
Binary files /dev/null and b/docs/using/resources/resource_types_categories-ex.png differ
diff --git a/docs/using/resources/resources-home.png b/docs/using/resources/resources-home.png
new file mode 100644
index 00000000..9388c6e6
Binary files /dev/null and b/docs/using/resources/resources-home.png differ
diff --git a/docs/using/resources/resources-lab/index.md b/docs/using/resources/resources-lab/index.md
new file mode 100644
index 00000000..24ea9e06
--- /dev/null
+++ b/docs/using/resources/resources-lab/index.md
@@ -0,0 +1,4 @@
+---
+title: Resources in 7 Minutes
+sidebar_label: Resources in 7 Minutes 🔬
+---
\ No newline at end of file
diff --git a/docs/concepts/resources/types-categories.md b/docs/using/resources/types-categories.md
similarity index 100%
rename from docs/concepts/resources/types-categories.md
rename to docs/using/resources/types-categories.md
diff --git a/docs/guides/configuring-guardrails/working-with-folders/confirm-delete-folder.png b/docs/using/resources/working-with-folders/confirm-delete-folder.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/confirm-delete-folder.png
rename to docs/using/resources/working-with-folders/confirm-delete-folder.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/confirm-to-delete.png b/docs/using/resources/working-with-folders/confirm-to-delete.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/confirm-to-delete.png
rename to docs/using/resources/working-with-folders/confirm-to-delete.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/create-folder-1.png b/docs/using/resources/working-with-folders/create-folder-1.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/create-folder-1.png
rename to docs/using/resources/working-with-folders/create-folder-1.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/create-folder-2.png b/docs/using/resources/working-with-folders/create-folder-2.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/create-folder-2.png
rename to docs/using/resources/working-with-folders/create-folder-2.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/create-resource-1.png b/docs/using/resources/working-with-folders/create-resource-1.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/create-resource-1.png
rename to docs/using/resources/working-with-folders/create-resource-1.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/create.md b/docs/using/resources/working-with-folders/create.md
similarity index 77%
rename from docs/guides/configuring-guardrails/working-with-folders/create.md
rename to docs/using/resources/working-with-folders/create.md
index be3ce569..63eea6e5 100644
--- a/docs/guides/configuring-guardrails/working-with-folders/create.md
+++ b/docs/using/resources/working-with-folders/create.md
@@ -1,6 +1,6 @@
---
title: Creating a Folder
-sidebar_label: Creating a Folder
+sidebar_label: Creating a Folder 🛠
---
# Creating a Folder
@@ -24,21 +24,21 @@ Log in to the Guardrails console using your local credentials or via SAML-based
On the **Home** page, select the **Resources** card, then navigate to the resource that will act as the `parent` of the new folder. In this example, a new folder is created at the **Turbot** level, but you can also create sub-folders under an existing folder.
-
+
On the far right, select **New**, then choose **Folder** from the **Resource Type** dropdown menu.
-
+
Enter a **Name** and **Description** for the folder. Click **Create**.
-
+
## Step 2: Review
- [ ] Validate that the folder has been created by navigating to the resource path and selecting the **Resources** tab.
-
+
That's it! The folder is created immediately and will be visible in the UI.
diff --git a/docs/guides/configuring-guardrails/working-with-folders/delete.md b/docs/using/resources/working-with-folders/delete.md
similarity index 76%
rename from docs/guides/configuring-guardrails/working-with-folders/delete.md
rename to docs/using/resources/working-with-folders/delete.md
index 73b8b6a9..3521ffb5 100644
--- a/docs/guides/configuring-guardrails/working-with-folders/delete.md
+++ b/docs/using/resources/working-with-folders/delete.md
@@ -1,6 +1,6 @@
---
title: Deleting a Folder
-sidebar_label: Deleting a Folder
+sidebar_label: Deleting a Folder 🛠
---
# Deleting a Folder
@@ -23,23 +23,23 @@ Log in to the Guardrails console using your local credentials or via SAML-based
Navigate to the **Resources** tab, locate the **folders** section, and select the folder you wish to rename.
-
+
## Step 2: Delete the Folder
Select the folder you want to delete. Select **Actions**, then choose **Remove from Turbot**.
-
+
A confirmation dialog will appear. *Read the prompt carefully*. Type the folder's **full name** to confirm the deletion, then click **Delete**.
-
+
## Step 3: Review
- [ ] Validate that the folder has been successfully deleted by navigating to the resource path and confirming that it no longer appears in the **Resources** section.
-
+
That's it! The folder is deleted immediately and will no longer be viewable in the UI.
diff --git a/docs/guides/configuring-guardrails/working-with-folders/find-folder-from-resources.png b/docs/using/resources/working-with-folders/find-folder-from-resources.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/find-folder-from-resources.png
rename to docs/using/resources/working-with-folders/find-folder-from-resources.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/folder-name-edit-1.png b/docs/using/resources/working-with-folders/folder-name-edit-1.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/folder-name-edit-1.png
rename to docs/using/resources/working-with-folders/folder-name-edit-1.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/folder-name-edit-2.png b/docs/using/resources/working-with-folders/folder-name-edit-2.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/folder-name-edit-2.png
rename to docs/using/resources/working-with-folders/folder-name-edit-2.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/folder-name-update.png b/docs/using/resources/working-with-folders/folder-name-update.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/folder-name-update.png
rename to docs/using/resources/working-with-folders/folder-name-update.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/index.md b/docs/using/resources/working-with-folders/index.md
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/index.md
rename to docs/using/resources/working-with-folders/index.md
diff --git a/docs/guides/configuring-guardrails/working-with-folders/remove-from-turbot.png b/docs/using/resources/working-with-folders/remove-from-turbot.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/remove-from-turbot.png
rename to docs/using/resources/working-with-folders/remove-from-turbot.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/rename.md b/docs/using/resources/working-with-folders/rename.md
similarity index 75%
rename from docs/guides/configuring-guardrails/working-with-folders/rename.md
rename to docs/using/resources/working-with-folders/rename.md
index 7bd0f1f0..3fb4f492 100644
--- a/docs/guides/configuring-guardrails/working-with-folders/rename.md
+++ b/docs/using/resources/working-with-folders/rename.md
@@ -1,6 +1,6 @@
---
title: Renaming a Folder
-sidebar_label: Renaming a Folder
+sidebar_label: Renaming a Folder 🛠
---
# Renaming a Folder
@@ -24,23 +24,23 @@ Log in to the Guardrails console using your local credentials or via SAML-based
Navigate to the **Resources** tab, locate the **folders** section, and select the folder you wish to rename.
-
+
## Step 2: Rename the Folder
Click **Edit**.
-
+
Enter the new folder name as required and select **Update**.
-
+
## Step 3: Review
- [ ] Validate that the folder name has been updated by navigating to the **Resources** tab and confirming the new name appears correctly in the folder section.
-
+
That's it! The folder name is updated immediately.
diff --git a/docs/guides/configuring-guardrails/working-with-folders/review-folder-delete.png b/docs/using/resources/working-with-folders/review-folder-delete.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/review-folder-delete.png
rename to docs/using/resources/working-with-folders/review-folder-delete.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/review-folder-name-edit.png b/docs/using/resources/working-with-folders/review-folder-name-edit.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/review-folder-name-edit.png
rename to docs/using/resources/working-with-folders/review-folder-name-edit.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/review-folder.png b/docs/using/resources/working-with-folders/review-folder.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/review-folder.png
rename to docs/using/resources/working-with-folders/review-folder.png
diff --git a/docs/guides/configuring-guardrails/working-with-folders/update-folder.png b/docs/using/resources/working-with-folders/update-folder.png
similarity index 100%
rename from docs/guides/configuring-guardrails/working-with-folders/update-folder.png
rename to docs/using/resources/working-with-folders/update-folder.png
diff --git a/docs/using/standard/access-logging.md b/docs/using/standard/access-logging.md
new file mode 100644
index 00000000..6949e80e
--- /dev/null
+++ b/docs/using/standard/access-logging.md
@@ -0,0 +1,137 @@
+---
+title: Access Logging Guardrails
+sidebar_label: Access Logging
+---
+
+# Access Logging Guardrails
+
+## Overview
+
+Access logging guardrails allow administrators to enable and store access
+logging information for cloud resources. Access logs are great to help
+understand the nature of requests to a particular resource, though it must be
+noted that they are
+[often not guaranteed delivery](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html).
+From a best practices security standpoint, it is almost always recommended to
+have access logging configured if there is an option to do so.
+
+Guardrails Access Logging policies can be found directly under the service in the
+hierarchy:
+
+- `{Provider} > {service} > {resource} > Access Logging`
+
+
+
+ AWS > S3 > Bucket > Access LoggingAWS > EC2 > Application Load Balancer > Access LoggingAWS > EC2 > Classic Load Balancer > Access LoggingAWS > EC2 > Network Load Balancer > Access Logging
+
+
+ AWS > Turbot > Logging > Bucket > Access LoggingAWS > Turbot > Logging > Bucket > Access Logging > BucketAWS > Turbot > Logging > Bucket > Access Logging > Key Prefix
+
+
+ # AWS > Turbot > Logging > Bucket > Access Logging
+ - Disabled
+ - Enabled
+
+
+
+ AWS > S3 > Bucket > ActiveAWS > SNS > Topic > ActiveAWS > EC2 > Instance > Active
+
+
{` # AWS > S3 > Bucket Active
+ - Skip
+ - Check: Active
+ - Enforce: Delete with 1 day warning
+ - Enforce: Delete with 3 days warning
+ - Enforce: Delete with 7 days warning
+ - Enforce: Delete with 14 days warning
+ - Enforce: Delete with 30 days warning
+ - Enforce: Delete with 60 days warning
+ - Enforce: Delete with 90 days warning
+ - Enforce: Delete with 180 days warning
+ - Enforce: Delete with 365 days warning`}
+
+
+ AWS > IAM > Access Key > Active > AgeAWS > IAM > Access Key > Active > StatusAWS > IAM > Access Key > Active > Last ModifiedAWS > IAM > Access Key > Active > Recently Used
+
+
+ AWS > S3 > Bucket > ApprovedAWS > SNS > Topic > ApprovedAWS > EC2 > Instance > Approved
+
+
+ AWS > EC2 > Instance > Approved > Instance TypesAWS > EC2 > Instance > Approved > Public IPAWS > EC2 > Instance > Approved > RegionsAWS > EC2 > Instance > Approved > UsageAWS > EC2 > Instance > Approved > Image > AMI IDsAWS > EC2 > Instance > Approved > Image > Publishers
+
+
+ AWS > VPC > Security Group > Egress Rules > ApprovedAWS > VPC > Security Group > Egress Rules > Approved > RulesAWS > VPC > Security Group > Egress Rules > Approved > Minimum BitmaskAWS > VPC > Security Group > Egress Rules > Approved > Prohibited PortsAWS > VPC > Security Group > Egress Rules > Approved > CIDR RangesAWS > VPC > Security Group > Egress Rules > Approved > Maximum Port RangeAWS > VPC > Security Group > Egress Rules > Approved > Compiled Rules
+
+
+ AWS > Redshift > Cluster > Audit LoggingAzure > PostgreSQL > Server > Audit Logging
+
+
+ # AWS > Redshift > Cluster > Audit Logging
+ - Skip
+ - Check: Disabled
+ - Check: Enabled
+ - Check: Enabled to Audit Logging > Bucket
+ - Enforce: Disabled
+ - Enforce: Enabled to Audit Logging > Bucket
+
+
+ # Azure > PostgreSQL > Server > Audit Logging
+ - Skip
+ - Check: Audit Logging > *
+ - Enforce: Audit Logging > *
+
+
+
+ AWS > EC2 > Instance > Active > BudgetAWS > RDS > DB Cluster > Active > BudgetAWS > Redshift > Cluster > Active > Budget
+
+
+ AWS > EC2 > Instance > Approved > BudgetAWS > RDS > DB Cluster > Approved > BudgetAWS > Redshift > Cluster > Approved > Budget
+
The Resource Type AWS > SQS > Queue defines a
+Control AWS > SQS > Queue > CMDB with a target Resource Type of AWS > SQS > Queue.
+
+
+### Policies to control CMDB
+
+CMDB controls have an associated policy that allows them to be enforced or
+skipped. Note, however, that if CMDB is set to `Skip` for a resource, then it
+will not exist in the CMDB, and _no controls that target it will run_.
+
+ The AWS > S3 > Bucket > CMDB policy may be set to `Skip` or `Enforce: Enabled`
+
+
+CMDB controls also use the `Region` policy associated with the resource. If
+region is not in `Regions` policy, the CMDB control should delete the resource
+from the CMDB (since we don’t want to capture any resources in that region, we
+should also cleanup).
+
+ The AWS > S3 > Bucket > CMDB will add/modify a resource in the CMDB if the resource is in region specified in AWS > S3 > Bucket > Regions, and delete it from the CMDB if it is not.
+
diff --git a/docs/using/standard/configured.md b/docs/using/standard/configured.md
new file mode 100644
index 00000000..45448499
--- /dev/null
+++ b/docs/using/standard/configured.md
@@ -0,0 +1,510 @@
+---
+title: Stacks and Configured Guardrails
+sidebar_label: Stack/Configured
+---
+
+# Stacks and the Configured Guardrails
+
+> [!IMPORTANT]
+> This document pertains to the legacy `Stack` and `Configured` controls. Consider migrating to the [Stack [Native] Controls](/guardrails/docs/concepts/guardrails/stacks) for [even more power and flexibility!](/guardrails/docs/concepts/guardrails/stacks#stack-native-controls-vs-legacy-stacks--configured-controls).
+
+
+## Overview
+
+Guardrails provides a mechanism for managing resource configuration using Terraform.
+Guardrails **Stack** and **Configured** controls allow you to define the
+configuration for a resource or set of resources using standard Terraform HCL.
+Guardrails can apply your configuration whenever resources change, enforcing your
+standards and preventing configuration drift.
+
+- A **Stack** is a set of resources configured via a terraform source from
+ Guardrails.
+- A resource can configure itself using terraform via its **Configured**
+ control.
+
+
+A resource does not need to be configured by a Guardrails stack or configured policy to be managed by other guardrails.
+
+
+### Stacks
+
+A Guardrails **Stack** is a set of resources managed by Turbot Guardrails using Terraform.
+Guardrails uses stacks to deploy, configure, and manage sets of related resources.
+
+Each stack has a single `Source` policy that specifies the Terraform
+configuration source code. When the stack control runs, resources will be
+created, modified or deleted per the `Source`.
+
+Stacks are responsible for the creation and deletion of multiple resources. Once
+created, the resources are responsible for updating themselves via the
+[Configured control](#configured-control). Changes to the underlying resources
+will trigger the resource's Configured control to run. The Configured control
+will use the `Source` from the parent stack to re-apply its configuration,
+keeping it configured per the policy.
+
+
+After being created by the AWS > Turbot > Event Handlers stack, the configuration of a the turbot_aws_api_handler SNS Topic is managed by its AWS > SNS > Topic > Configured control. If the topic is modified, the AWS > SNS > Topic > Configured control will re-apply its configuration using the terfafrom source defined in the AWS > Turbot > Event Handlers > Source policy
+
+
+#### Stack Terraform Version
+
+Guardrails Stacks supports up to the most recent
+[Terraform 0.15 version](https://github.com/hashicorp/terraform/blob/v0.15/CHANGELOG.md),
+which is 0.15.5. Using the policy family `* > * > Terraform Version`, users can
+define which version of Terraform to use. The policy
+`Turbot > Stack Terraform Version [Default]` can be used to define the Terraform
+version across all stack policies.
+
+**Notes**:
+
+- While the policy allows administrators to specify any version of Terraform,
+ only the "oldest" minor version for each patch is valid. I.e. `0.11.*` and
+ `0.11.12` are valid values, but `0.11.10` is not. In general, it is
+ recommended to use `*` in conjunction with the patch version.
+- Guardrails supports the different syntax of each version, but does NOT support the
+ use of new features or modules.
+
+Supported values for the policy `* > * > Terraform Version`:
+
+- `0.11.*` or `0.11.14`
+- `0.12.*` or `0.12.28`
+- `0.13.*` or `0.13.0-beta3`
+- `0.14.*` or `0.14.11`
+- `0.15.*` or `0.15.5`
+- `*` This value will use the latest version of Terraform.
+
+#### Guardrails-Defined Stacks
+
+Guardrails provides pre-defined stacks to assist with common setup and configuration
+tasks. Guardrails-defined stacks manage common resources required to operate Guardrails,
+as well as resources used as containers or defaults for other controls.
+
+Guardrails-defined stacks typically appear under `{provider} > Turbot` in the policy
+type hierarchy.
+
+
+Guardrails-defined stacks include:
+
+ - GCP > Turbot > Event Handlers
+ - Azure > Turbot > Event Handlers
+ - AWS > Turbot > Event Handlers
+ - AWS > Turbot > Audit Trail
+ - AWS > Turbot > Logging
+ - AWS > Turbot > OS Management
+ - AWS > Turbot > Service Roles
+
+
+The
AWS > Turbot > Logging > Bucket stack creates and manages S3 buckets used by multiple AWS services for logging. This stack is configured per the
AWS > Turbot > Logging > Bucket > Source> policy, which is generated using policies that allow you to set options to customime the bucket name, tags, and other properties:
+
+
+ - AWS > Turbot > Logging > Bucket > Default Encryption
+ - AWS > Turbot > Logging > Bucket > Name
+ - AWS > Turbot > Logging > Bucket > Name > Prefix
+ - AWS > Turbot > Logging > Bucket > Regions
+ - AWS > Turbot > Logging > Bucket > Tags
+ - AWS > Turbot > Logging > Bucket > Versioning
+
+
+Every resource in Guardrails can manage its own configuration in its own
Configured policy:
+
+ - AWS > EC2 > Instance > Configured
+ - AWS > VPC > Security Group > Configured
+ - AWS > DynamoDB > Table > Configured
+
+
+
+ AWS > DynamoDB > Table > Data Protection > Managed BackupsGCP > Compute > Disk > Data Protection > Managed Snapshots
+
+
+ AWS > EBS > Disk > Data Protection > Managed Snapshots AWS > EBS > Disk > Data Protection > Managed Snapshots > Schedule AWS > EBS > Disk > Data Protection > Managed Snapshots > Minimum Schedule
+
+
+ AWS > RDS > DB Instance > Data Protection > Managed Snapshots > CopiesAWS > RDS > DB Instance > Data Protection > Backup > Copies
+
+
+ AWS > RDS > DB Instance > Data Protection > Managed Snapshots > Copies > ScheduleAWS > RDS > DB Instance > Data Protection > Managed Snapshots > Copies > Minimum ScheduleAWS > RDS > DB Instance > Data Protection > Managed Snapshots > Copies > RegionAWS > RDS > DB Instance > Data Protection > Managed Snapshots > Copies > Encryption Key
+
The Resource Type AWS > SQS > Queue defines a
+Control AWS > SQS > Queue > Discovery with a target Resource Type of AWS > Region.
+
+
+### Policies to control Discovery
+
+Discovery controls are enforced or skipped based on the associated CMDB policy.
+
+ The AWS > S3 > Bucket > Discovery control relies on the value of the AWS > S3 > Bucket > CMDB policy for its configuration. AWS > S3 > Bucket > CMDB may be set to `Skip` or `Enforce: Enabled`
+
+
+Discovery controls also use the `Region` policy associated with the resource. If
+region is not in `Regions` policy, the CMDB control should delete the resource
+from the CMDB (since we don’t want to capture any resources in that region, we
+should also cleanup).
+
+ The AWS > S3 > Bucket > Discovery control will search for S3 buckets in a the regions specified in AWS > S3 > Bucket > Regions, and will add any buckets it finds to the CMDB as AWS > S3 > Bucket resources.
+
diff --git a/docs/using/standard/encryption-at-rest.md b/docs/using/standard/encryption-at-rest.md
new file mode 100644
index 00000000..3c939194
--- /dev/null
+++ b/docs/using/standard/encryption-at-rest.md
@@ -0,0 +1,131 @@
+---
+title: Encryption at Rest Guardrails
+sidebar_label: Encryption at Rest
+---
+
+
+# Encryption at Rest Guardrails
+
+## Overview
+
+Most corporations already have standards around data encryption. These vary from
+detailed rules that classify data by sensitivity and provide encryption
+requirements for each, to more general guidelines like "encrypt everything!".
+Guardrails provides a simple yet flexible platform for the implementation and
+auditing of these standards, whatever they may be.
+
+**Encryption at Rest** refers specifically to the encryption of data when
+written to an underlying storage system. All the major cloud vendors provide
+options for encryption of the data that they store on your behalf. Often, the
+details vary by service; within a given cloud provider, the encryption options
+may be different for their object storage, relational databases, no-sql
+databases, file servers, etc. While the details may differ, the type of options
+are generally the same:
+
+- Encryption Level: is it enabled? Is it the correct algorithm/type?
+- Key Management: what key should be used?
+
+Guardrails generally solves these with 2 policies:
+
+- `Encryption at Rest`: This policy allows you check or enforce the minimum or
+ actual level of encryption required for the service. The option values are
+ ordered from least secure to most secure. Note that in these policies, Guardrails
+ considers a customer managed key more secure than a default key managed by the
+ vendor.
+- `Encryption At Rest > Customer Managed Key`: This allows you to specify the
+ key to be used for encryption (assuming you have set the "Encryption at Rest")
+ policy to use a customer managed key.
+
+For services that support changing the encryption level and/or key, Guardrails can
+enforce your standard and change the encryption on the fly. These policies can
+be found directly under the service in the hierarchy:
+
+- `{Provider} > {Service} > {Resource} > Encryption at Rest`
+- `{Provider} > {Service} > {Resource} > Encryption at Rest > Customer Managed Key`
+
+
+
+ AWS > S3 > Bucket > Encryption at Rest AWS > S3 > Bucket > Encryption at Rest > Customer Managed KeyGCP > Storage > Bucket > Encryption at Rest GCP > Storage > Bucket > Encryption at Rest > Customer Managed Key
+
+
+ AWS > EC2 > Volume > Approved > Encryption at RestAWS > EC2 > Volume > Approved > Encryption at Rest > Customer Managed KeyGCP > BigQuery > Table > Approved > Encryption at RestGCP > BigQuery > Table > Approved > Encryption at Rest > Customer Managed Key
+
+
+ # AWS > S3 > Bucket > Encryption at Rest
+ - Skip
+ - "Check: None"
+ - "Check: None or higher"
+ - "Check: AWS SSE"
+ - "Check: AWS SSE or higher"
+ - "Check: AWS managed key"
+ - "Check: AWS managed key or higher"
+ - "Check: Customer managed key"
+ - "Check: Encryption at Rest > Customer Managed Key"
+ - "Enforce: None"
+ - "Enforce: None or higher"
+ - "Enforce: AWS SSE"
+ - "Enforce: AWS SSE or higher"
+ - "Enforce: AWS managed key"
+ - "Enforce: AWS managed key or higher"
+ - "Enforce: Customer managed key"
+ - "Enforce: Encryption at Rest > Customer Managed Key"
+
+
+
+ AWS > S3 > Bucket > Encryption in TransitAWS > Redshift > Cluster > Encryption in TransitAzure > Storage > Storage Account > Encryption in TransitAzure > PostgreSQL > Server > Encryption in Transit
+
+
+ # AWS > S3 > Bucket > Encryption in Transit
+ - Skip
+ - Check: Disabled
+ - Check: Enabled
+ - Enforce: Disabled
+ - Enforce: Enabled
+
+
+
+ AWS > Redshift > Cluster > Publicly AccessibleAWS > RDS > DB Instance > Publicly Accessible
+
+
+ # AWS > Redshift > Cluster > Cluster Publicly Accessible
+ - Skip
+ - Check: Cluster is not publicly accessible
+ - Enforce: Cluster is not publicly accessible
+
+
+
+ AWS > EC2 > Instance > Schedule AWS > EC2 > Instance > Schedule Tag
+
+
+ # AWS > EC2 > Instance > Schedule
+ - Skip
+ - Enforce: Enforce: Business hours (8:00am - 6:00pm on weekdays)
+ - Enforce: Extended business hours (7:00am - 11:00pm on weekdays)
+ - Enforce: Stop for night (stop at 10:00pm every day)
+ - Enforce: Stop for weekend (stop at 10:00pm on Friday)
+
+
+
+
+ | Stack |
+ Target |
+ Intended Purpose |
+
+
+
+
+ | AWS > Account > Stack [Native] |
+ Account |
+ Account-level settings and global services like Route53 and CloudFront. |
+
+
+ | AWS > Region > Stack [Native] |
+ Region |
+ Regional resources, like Lambda Functions, EC2 instances, SNS Topics, etc. |
+
+
+ | AWS > IAM > Stack [Native] |
+ Account |
+ IAM resources, like standard users, roles, policies, and identity providers. |
+
+
+ | AWS > VPC > Stack [Native] |
+ Region |
+ VPC resources to set your standard "landing zone" VPCs - subnets, security groups, gateways, etc. |
+
+
+ | AWS > S3 > Bucket > Stack [Native] |
+ Bucket |
+ Resources to associate with buckets such as lifecycle policies or replication configuration |
+
+
+ | AWS > VPC > VPC > Stack [Native] |
+ VPC |
+ Standard VPC resources that belong in every VPC, like security groups, gateways, NACLs, etc. |
+
+
+ | Azure > Subscription > Stack [Native] |
+ Subscription |
+ Subscription-level settings and global services |
+
+
+ | Azure > Network > Virtual Network > Stack [Native] |
+ Virtual Network |
+ Standard network resources that belong in every Virtual Network |
+
+
+ | GCP > Project > Stack [Native] |
+ Project |
+ Project-level settings and global services |
+
+
+
+
+
+
+## Example: Standard IAM policy
+
+Many organizations create standard IAM resources in their accounts, such as:
+- Standard IAM policies required for your organization
+- Roles, users, and policies for 3rd party applications such as monitoring or security tools
+- Identity providers, roles, users, and groups for federated authentication via SAML or OpenID Connect
+
+You can use the `AWS > IAM > Stack [Native]` control to simplify the creation and management of these resources across all of your AWS Accounts. Simply define the configuration for your IAM resources using OpenTofu. Guardrails can run the stack in all your accounts to create and manage these IAM resources. As your requirements change, simply modify the `Stack [Native] > Source` policy, and Guardrails will deploy the changes. If you add new AWS Accounts, Guardrails automatically runs your stack, making it consistent and compliant with your standards.
+
+
+In this example, we will deploy a standard IAM policy via the `AWS > IAM > Stack [Native]` control. This control targets the `AWS > Account`; It will run once for each account in scope. You can create these policy settings on an individual account, but more commonly, you will set them on a parent folder.
+
+
+### Step 1: Set the Source policy
+
+Create a policy setting for the `AWS > IAM > Stack [Native] > Source` policy on an account or folder. Enter the OpenTofu configuration in the `AWS > IAM > Stack [Native] > Source` policy. For example:
+
+```hcl
+resource "aws_iam_policy" "main" {
+ # Boundary policy name that will be applied to the IAM role.
+ name = "myBoundaryPolicy"
+ path = "/"
+ description = "Guardrails Managed Boundary policy to prevent actions from unapproved CIDRs"
+ policy = jsonencode({
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Action": "*"
+ "Resource": "*",
+ "Condition": {
+ "IpAddress": {
+ "aws:SourceIp": [
+ "10.0.0.0/8",
+ "172.16.0.0/12",
+ "192.168.0.0/16"
+ ]
+ }
+ }
+ }
+ ]
+ })
+}
+```
+
+### Step 2: Enforce the stack
+
+Create a policy setting for the `AWS > IAM > Stack [Native]` policy on an account or folder. Set the policy value to `Enforce: Configured`. Guardrails will apply the OpenTofu source, creating the custom role and policy and then assigning the policy to the role!
+
+
+
+## Stack Policies
+
+Stack behavior is controlled by the `Stack [Native]` policy and sub-policies.
+
+| Policy | Description
+|---------------------------------------|-----------------------------------------------------------------------
+| **Stack [Native]** | Determine whether to run the stack in check mode, enforce mode, or skip
+| **Stack [Native] > Source** | The OpenTofu HCL configuration source code that should be applied
+| **Stack [Native] > Modifier** | Additional OpenTofu HCL configuration source code that should be applied, typically used for per-instance customization such as [importing resources](https://opentofu.org/docs/language/import/)
+| **Stack [Native] > Variables** | `.tfvar`-style variable overrides
+| **Stack [Native] > Secret Variables** | `.tfvar`-style variable overrides for sensitive variables
+
+The `Stack [Native]` primary policy determines what action the control will take:
+
+| Value | Description
+| ----------------------- | -----------------------------------------------------------------------------------
+| **Skip** | The control will not run
+| **Check: Configured** | An OpenTofu plan will be generated. If the planned configuration does not match the current configuration, the control will alarm.
+| **Enforce: Configured** | An OpenTofu plan will be generated. If the planned configuration does not match the current configuration, the control will apply the configuration.
+
+The `Source` policy contains the OpenTofu configuration code that should be applied.
+
+Note that the stack expects to continuously manage any resources that were created in the stack - if you delete a resource from the OpenTofu configuration in the `Source` policy, the stack control will destroy the resource. For example, if you wish to destroy all the objects created by the stack, set the `Source` policy to `{}`, and leave the `Stack` policy set to `Enforce: Configured`.
+
+Like the The `Source` policy, the `Modifier` policy may also contain OpenTofu HCL code. While it may contain any HCL code, its purpose is to allow you to separate instance-specific configuration code, such as [resource import blocks](https://opentofu.org/docs/language/import/), from your standard source definition.
+
+
+The `Variables` policy can contain variable definitions in OpenTofu HCL, in the same way that they would use a [.tfvars file](https://opentofu.org/docs/language/values/variables/#variable-definitions-tfvars-files).
+
+Like `Variables`, the `Secret Variables` policy can contain variable definitions. This policy will be marked `secret` in Guardrails, and is meant for parameters that are sensitive or confidential.
+
+The `Variables` and `Secret Variables` policies are merged into a single set of variables that are passed as a `tfvars` file to OpenTofu by the stack control.
+
+The `Variables` and `Secret Variables` are not required, however separating the variables from the configuration will simplify using stacks in Guardrails:
+
+- As a best practice, you should avoid using a calculated policy in the `Source`. If you need to get context dynamically from the CMDB, you should instead use calculated policies to set the `Variables` or `Secret Variables` policy.
+ - This makes the source easily testable outside of Guardrails, as it is not a calculated policy
+ - Rendering the input variables in nunjucks is much simpler than rendering the whole OpenTofu source
+ - This allows you to separate your OpenTofu HCL logic in the `Source` policy from the nunjucks logic in the `Variables` policies
+
+- Using map or object variables allows you to create a map policy in the `Variables` with configuration information that can be used in all child resource stacks. If a new item is added, the variables can be updated without updating the OpenTofu configuration.
+
+
+
+## Drift Detection
+
+Native stacks offer 2 mechanisms for drift detection and correction:
+- Run the stack at regular intervals
+- Run the stack when the resources it manages are modified
+
+Native stacks can create any OpenTofu resources, and do not require that the resource that create must exist in the CMDB. This makes them more flexible and extensible than the old model, however it does have implications for trigger updates; if the resources are not in the CMDB, then the stack can't be triggered when they are modified and drift will occur. To mitigate this, we will offer an ability to run the stack at regular intervals.
+
+You may also choose to trigger the stack to run when resources change, but:
+- It will only work for supported resources (Guardrails has very good coverage though)
+- The resource types must be available in the installation. This means you must install the mods that contain the resources in your stacks, and you must enable CMDB for those resources.
+
+
+### Drift Detection Policies
+Drift detection behavior is controlled by the following sub-policies.
+
+| Policy | Description
+|---------------------------------------|-----------------------------------------------------------------------
+| **Stack [Native] > Drift Detection** | Specify the mechanism for drift detection.
+| **Stack [Native] > Drift Detection > Interval** | Specify the interval at which to run the stack, in minutes.
+
+
+The `Stack [Native] > Drift Detection` policy allows you to specify the mechanism for drift detection. You may run the stack at regular intervals to keep the resources up to date, and/or automatically trigger the stack to run whenever a resource that it created is modified. Note that resource triggering will only be available for resources that exist in the Guardrails CMDB; you may install the supporting mods and enable the CMDB for those resources.
+
+
+The `Stack [Native] > Drift Detection > Interval ` allows you to specify the interval at which to run the stack, in minutes. The default is `1440` (Once a day).
+
+
+## OpenTofu Version
+
+The `Stack [Native] > Version` policy allows you to select which OpenTofu version Turbot should use for the stack.
+
+The policy supports semver semantics, allowing you to use new versions automatically, or to pin to specific versions, depending on your preference.
+
+By default this policy uses the global default value set in the `Turbot > Stack > Native Stack Version [Default]` policy. The shared default allows you to change only a single setting to change your default version, but still migrate versions over time on a per-stack basis.
+
+Guardrails native stack containers include standard cloud [providers](https://opentofu.org/docs/language/providers/). These providers are bundled in the container image, so in practice, the provider versions are tied to the OpenTofu version. The following versions are currently supported:
+
+### Supported Versions
+| OpenTofu | AWS Provider | AzureRM Provider | Google Provider | AzureAD Provider
+|-----------|--------------|------------------|-----------------|-----------------
+| **1.8.3** | 5.72.0 | 4.9.0 | 6.10.0 | 3.0.2
+
+
+
+## Best practices
+- Avoid using calculated policies for the `Stack > Source`. Instead, calculate the `Variables` and/or `Secret Variables` and use Terraform functions and control structures for conditional logic, iteration, etc. This makes the stack easier to maintain and test.
+- Use `Secret Variables` for inputs that are secrets, like passwords or keys.
+- Use `Variables` for non-sensitive information. Using `Secret Variables` for non-sensitive inputs creates unnecessary operational complexity, as you will not be able to read the existing values.
+
+
+## Primary Regions
+
+Stack controls that target the account run in a single "primary" region. For AWS account-level stacks (`AWS > Account > Stack [Native]` and `AWS > IAM > Stack [Native]`), this region varies depending on the partition:
+
+| Partition Name | Partition Id | Region
+|----------------|--------------|---------------
+| Commercial | `aws` | `us-east-1`
+| GovCloud | `aws-gov` | `us-gov-west-1`
+| China | `aws-cn` | `cn-north-1`
+
+The `GCP > Project > Stack [Native]` stack runs in `us-east1`.
+
+
+## Stack [Native] Controls vs Legacy Stacks & Configured Controls
+
+`Stack [Native]` controls will replace the older [Stack and Configured controls](/guardrails/docs/concepts/guardrails/configured). Native stacks provide the following benefits over the previous stacks:
+
+- Native stacks use open source [OpenTofu](https://opentofu.org/). When we initially implemented the older stack controls, Terraform was open source. Hashicorp has subsequently [moved to a closed licensing model](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) which prohibits us from using newer versions. OpenTofu is open-source, community-driven, and managed by the Linux Foundation!
+- The previous stack controls only supported specific resources, and mods for all resource types in the stack definitions needed to be installed in Guardrails. Native stacks do not have this requirement (though resource level drift detection is only available for resources in the CMDB).
+- Previous stack controls were not 100% compatible with Terraform; some meta-arguments like `count` and `for_each` were not supported. Native stacks are fully compatible with OpenTofu - if you can run it on your machine, you can run it in Guardrails.
+
+### Feature Comparison Chart
+
+| Feature | Stack/Configured | Stack [Native]
+|-------------------------|---------------------------|----------------------------
+| **Version** | Terraform 0.15 and earlier | OpenTofu 1.8.3 and later
+| **Triggering** | Resource update | Resource update, interval
+| **CMDB Required?** | Yes | No
+| **Resources Supported** | Only resources supported in Guardrails | Any resource supported by the [provider](https://opentofu.org/docs/language/providers/)
+| **Support for `count`, `for_each` **| No | Yes
+
diff --git a/docs/using/standard/stacks/index.md.og b/docs/using/standard/stacks/index.md.og
new file mode 100644
index 00000000..4a5ac4ae
--- /dev/null
+++ b/docs/using/standard/stacks/index.md.og
@@ -0,0 +1,15 @@
+---
+title: Stacks
+sidebar_label: Stacks
+---
+
+# Stacks
+
+Guardrails [Stack controls](/guardrails/docs/concepts/guardrails/stacks) provides a mechanism for managing resource configuration using OpenTofu, an open-source implementation of Terraform. Guardrails can apply your configuration at regular intervals, or whenever resources change, enforcing your standards and preventing configuration drift.
+
+| Section | Description
+|-------------------|-------------------------------------------
+| [Deploy a Stack](/guardrails/docs/guides/using-guardrails/stacks/deploy) | Setting up a stack control to create and manage resources.
+| [Destroy Stack](/guardrails/docs/guides/using-guardrails/stacks/destroy) | Destroying resources managed by a stack.
+| [Import Resource](/guardrails/docs/guides/using-guardrails/stacks/import) | Import existing resources into stack.
+
diff --git a/docs/using/standard/stacks/network-stack/index.md b/docs/using/standard/stacks/network-stack/index.md
new file mode 100644
index 00000000..5b6fec34
--- /dev/null
+++ b/docs/using/standard/stacks/network-stack/index.md
@@ -0,0 +1,397 @@
+---
+title: Network Stacks
+sidebar_label: Network Stacks
+---
+
+# Managing Network Configurations with Stacks
+
+> [!IMPORTANT]
+> This document pertains to the legacy `Stack` and `Configured` controls. Consider migrating to the [Stack [Native] Controls](/guardrails/docs/concepts/guardrails/stacks) for [even more power and flexibility!](/guardrails/docs/concepts/guardrails/stacks#stack-native-controls-vs-legacy-stacks--configured-controls).
+
+
+
+## Overview
+
+Network controls and guardrails have been an essential part of Guardrails since
+Turbot Guardrails version 1.0. And with good reason - the security and reliability of the
+network are fundamentally important. The network is one of the foundational
+components on which your infrastructure (and therefore your application!)
+relies.
+
+The cloud has shifted the networking paradigm from static, hardware-driven
+configurations to dynamic, software driven approaches. In modern cloud
+platforms, entire networks can be built and destroyed in minutes, including
+routers, gateways, firewalls, VPNs... The challenge is balancing security and
+consistency with speed and agility -- How can you harness the agility of
+software-defined networks while ensuring that these networks comply with
+standards? How can you keep dozens, hundreds, or even thousands of disparate
+virtual networks configured consistently?
+
+Guardrails can help you centrally deploy, configure, and manage your cloud-based
+networks using Guardrails Stacks. WIth Guardrails network stacks, you describe your
+network configuration in Terraform, and Guardrails manages deploying and updating
+your configuration. Guardrails' real-time event triggering prevents drift by
+re-running your stack whenever a configured item is changed.
+
+### A note for Turbot Guardrails V3 customers
+
+Existing V3 customers will notice that the V5 stack capability is a departure
+from the approach in V3 and earlier.
+
+The first version of Guardrails provided a VPC configuration feature that allowed
+customers to define IP ranges and other basic configuration parameters, and
+Guardrails would create and manage those VPCs. This automated, prescriptive approach
+was useful to customers, but as more and more VPC features were added, it was
+not flexible enough for many customers.
+
+The V3 approach was more guardrail focused. V3 did not provide a mechanism for
+creating VPCs, but instead concentrated on simplifying the ongoing management of
+increasingly complex and varied configurations.
+[V3 Network Guardrails](https://support.turbot.com/hc/en-us/articles/360012565452-Network-Guardrails-for-AWS)
+defined six network security zones, and managed routing and gateway
+configuration based on theses subnet types. This abstraction provided a common
+language for network routing and simplified defining configurations.
+
+But cloud networks continue to evolve, and Guardrails must evolve with them. While
+the types of network security zones have not fundamentally changed, the ways of
+implementing and connecting them has expanded. Technologies like Transit
+Gateways and VPC sharing provide new options for existing configurations, as
+well as entirely new capabilities. As the cloud has matured, our customers have
+matured with it. Our customers often already have very specific, defined
+standards for their network configuration. The problem that Guardrails needs to
+solve has shifted from "How can Guardrails help me configure and manage **_a_**
+secure, standard VPC Configuration" to "How can Guardrails help me configure and
+manage **_my_** secure, standard VPC Configuration." We believe that network
+stack controls are the answer.
+
+## Managing Network Configurations with AWS > VPC > Stack
+
+The `AWS > VPC > Stack` control is a
+[custom stack](concepts/guardrails/configured#user-defined-stacks) that you can
+use to create and subsequently manage VPCs and related objects across your AWS
+accounts and regions.
+
+The stack control can automate the deployment and ongoing updates to your
+standard VPCs. Note that this control is NOT intended to manage existing VPCs
+that were created outside of the stack. You should leverage the other Guardrails
+standard [guardrails](concepts/guardrails) (`Active`, `Approved`, `Tags`, etc)
+to manage these resources.
+
+### Example: Setting up a VPC Network Stack
+
+The `AWS > VPC > Stack` control targets an AWS region; regardless of what level
+you set the stack policies, the control actually runs once for each region in
+scope.
+
+While you can set policies and exceptions down to the region level, you likely
+want to set your policies as high in the Guardrails Hierarchy as possible as the
+goal is to manage as many VPCs from a single, consistent configuration. It is
+often useful to test your policies at the region level before setting them at a
+higher scope, however.
+
+#### Scenario
+
+In this example, we will define a simple, standard VPC configuration with 2
+public and 2 private subnets. Because we would like to deploy this across all of
+our accounts, will use a map variable to define what ip ranges are assigned to
+which regions for each account.
+
+In this example, we will assume:
+
+- We have 4 AWS Accounts with the following AWS account aliases:
+ - gnb-aaa
+ - gnb-bbb
+ - gnb-ccc
+ - gnb-ddd
+- We have imported all accounts into a single folder named **Goliath**
+- We only use 2 regions:
+ - us-east-1
+ - us-west-2
+
+#### Set the `AWS > VPC > Stack > Source`
+
+The `Stack > Source` policy contains the Terraform configuration code that
+should be applied. This policy can contain any standard Terraform HCL. This
+Terraform configuration will be run in each region that is in scope.
+
+Note that the stack expects to continue to manage any resources that were
+created in the stack - if you delete a resource from the Terraform configuration
+in the `Source` policy, the stack control will destroy the resource. If you
+modify a resource in the `Source`, the control will modify that AWS resource
+accordingly.
+
+If you wish to destroy all the objects created by the stack, set the `Source`
+policy to `{}`, and leave the `Stack` policy set to `Enforce: Configured`.
+
+For this example, we will set the `Source` policy on the parent folder
+(**Goliath**), as we would like the configuration to apply to all accounts below
+that folder. We will navigate to the folder, and set the
+`AWS > VPC > Stack > Source` to:
+
+```hcl
+
+ variable "tag_prefix" {
+ default = ""
+ }
+
+######
+variable "ip_assignments" {
+ type = "map"
+ # map of ip addresses to assign, by account-alias, then region
+ default = {
+ account-1-us-east-1 = "1.2.3.0/24"
+ account-1-us-east-2 = "1.2.4.0/24"
+ account-2-us-west-1 = "1.2.5.0/24"
+ account-3-eu-east-1 = "1.2.6.0/24"
+ }
+}
+
+ ######
+
+# Declare the data source
+data "aws_availability_zones" "available" {
+ state = "available"
+}
+
+data "aws_region" "current" {}
+
+data "aws_iam_account_alias" "current" {}
+
+# VPC
+resource "aws_vpc" "turbot_default" {
+ cidr_block = "${lookup(var.ip_assignments, "${data.aws_iam_account_alias.current.account_alias}-${data.aws_region.current.name}")}"
+ instance_tenancy = "default"
+ enable_dns_support = true
+ enable_dns_hostnames = true
+
+ tags = {
+ Name = "${var.tag_prefix}${data.aws_iam_account_alias.current.account_alias}-${data.aws_region.current.name}"
+ }
+}
+
+resource "aws_subnet" "turbot_public_0" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ availability_zone = "${data.aws_availability_zones.available.names[0]}"
+ cidr_block = "${cidrsubnet(aws_vpc.turbot_default.cidr_block, 2, 0)}"
+ tags = {
+ Name = "${var.tag_prefix}public-${data.aws_availability_zones.available.names[0]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_subnet" "turbot_public_1" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ availability_zone = "${data.aws_availability_zones.available.names[1]}"
+ cidr_block = "${cidrsubnet(aws_vpc.turbot_default.cidr_block, 2, 1)}"
+ tags = {
+ Name = "${var.tag_prefix}public-${data.aws_availability_zones.available.names[1]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_subnet" "turbot_private_0" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ availability_zone = "${data.aws_availability_zones.available.names[0]}"
+ cidr_block = "${cidrsubnet(aws_vpc.turbot_default.cidr_block, 2, 2)}"
+ tags = {
+ Name = "${var.tag_prefix}private-${data.aws_availability_zones.available.names[0]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_subnet" "turbot_private_1" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ availability_zone = "${data.aws_availability_zones.available.names[1]}"
+ cidr_block = "${cidrsubnet(aws_vpc.turbot_default.cidr_block, 2, 3)}"
+ tags = {
+ Name = "${var.tag_prefix}private-${data.aws_availability_zones.available.names[1]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+# IGW
+resource "aws_internet_gateway" "turbot_igw" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ tags = {
+ Name = "${var.tag_prefix}igw-${data.aws_iam_account_alias.current.account_alias}-${data.aws_region.current.name}"
+ }
+}
+
+# NAT GW
+
+resource "aws_eip" "nat_eip_0" {
+ tags = {
+ Name = "${var.tag_prefix}eip-nat-${data.aws_availability_zones.available.names[0]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_eip" "nat_eip_1" {
+ tags = {
+ Name = "${var.tag_prefix}eip-nat-${data.aws_availability_zones.available.names[1]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_nat_gateway" "turbot_nat_gw_0" {
+ allocation_id = "${aws_eip.nat_eip_0.id}"
+ subnet_id = "${aws_subnet.turbot_public_0.id}"
+ depends_on = ["aws_internet_gateway.turbot_igw" ]
+
+ tags = {
+ Name = "${var.tag_prefix}natgw-${data.aws_availability_zones.available.names[0]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+
+}
+
+resource "aws_nat_gateway" "turbot_nat_gw_1" {
+ allocation_id = "${aws_eip.nat_eip_1.id}"
+ subnet_id = "${aws_subnet.turbot_public_1.id}"
+ depends_on = ["aws_internet_gateway.turbot_igw" ]
+
+ tags = {
+ Name = "${var.tag_prefix}natgw-${data.aws_availability_zones.available.names[1]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+
+}
+
+# Public route table / routes
+resource "aws_route_table" "public" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+
+ route {
+ cidr_block = "0.0.0.0/0"
+ gateway_id = "${aws_internet_gateway.turbot_igw.id}"
+ }
+ tags = {
+ Name = "${var.tag_prefix}public-rtb-${data.aws_iam_account_alias.current.account_alias}-${data.aws_region.current.name}"
+ }
+}
+
+resource "aws_route_table_association" "public_0" {
+ subnet_id = "${aws_subnet.turbot_public_0.id}"
+ route_table_id = "${aws_route_table.public.id}"
+}
+
+resource "aws_route_table_association" "public_1" {
+ subnet_id = "${aws_subnet.turbot_public_1.id}"
+ route_table_id = "${aws_route_table.public.id}"
+}
+
+# private Route Tables / Routes
+
+resource "aws_route_table" "private_0" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+ tags = {
+ Name = "${var.tag_prefix}private-rtb-${data.aws_availability_zones.available.names[0]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+
+resource "aws_route" "private_natgw_0" {
+ route_table_id = "${aws_route_table.private_0.id}"
+ destination_cidr_block = "0.0.0.0/0"
+ nat_gateway_id = "${aws_nat_gateway.turbot_nat_gw_0.id}"
+}
+
+resource "aws_route_table_association" "private_0" {
+ subnet_id = "${aws_subnet.turbot_private_0.id}"
+ route_table_id = "${aws_route_table.private_0.id}"
+}
+
+##
+
+resource "aws_route_table" "private_1" {
+ vpc_id = "${aws_vpc.turbot_default.id}"
+
+ tags = {
+ Name = "${var.tag_prefix}private-rtb-${data.aws_availability_zones.available.names[1]}-${data.aws_iam_account_alias.current.account_alias}"
+ }
+}
+resource "aws_route" "private_natgw_1" {
+ route_table_id = "${aws_route_table.private_1.id}"
+ destination_cidr_block = "0.0.0.0/0"
+ nat_gateway_id = "${aws_nat_gateway.turbot_nat_gw_1.id}"
+}
+
+resource "aws_route_table_association" "private_1" {
+ subnet_id = "${aws_subnet.turbot_private_1.id}"
+ route_table_id = "${aws_route_table.private_1.id}"
+}
+
+
+####### Outputs ###
+
+output "vpc_id" {
+ value = "${aws_vpc.turbot_default.id}"
+}
+
+output "public_subnets" {
+ value = ["${aws_subnet.turbot_public_0.id}", "${aws_subnet.turbot_public_1.id}"]
+}
+
+output "private_subnets" {
+ value = ["${aws_subnet.turbot_private_0.id}", "${aws_subnet.turbot_private_1.id}"]
+}
+
+```
+
+Note that the `Source` policy is just standard Terraform code. We use data
+providers to determine which account and region we are running in, and use that
+information to look up configuration information specific to this account/region
+in variables defined at the top of the configuration. This configuration will
+create a VPC, 2 public subnets, 2 private subnets, and 2 NAT gateways (in 2
+different availability zones), an internet gateway, and the appropriate routing
+tables.
+
+You can, of course, extend this configuration to meet your specific needs - set
+up VPN connectivity, create VPC endpoints, security groups, transit gateway
+attachments, etc, all using standard Terraform!
+
+#### Set the `AWS > VPC > Stack > Variables`
+
+The `Variables` and `Secret Variables` policies allow you to set variables to
+use when running the Terraform configuration. The `Variables` and
+`Secret Variables` policies are merged into a single set of variables that are
+passed as a
+[tfvars](https://www.terraform.io/docs/configuration/variables.html#variable-definitions-tfvars-files)
+file to Terraform by the stack control.
+
+In our `Source` policy, we look up the IP assignment information specific to
+this account/region in the `ip_assignments` variable defined at the top of the
+configuration. We will override this value in the `Variables` policy with the IP
+address assignments for our accounts/regions.
+
+For this example, we will set the `Variables` policy on the parent folder
+(**Goliath**), as we would like the configuration to apply to all accounts below
+that folder. We will navigate to the folder, and set the
+`AWS > VPC > Stack > Variables` to:
+
+```hcl
+## map of ip addresses to assign, by account-alias, then region
+ip_assignments = {
+ gnb-aaa-us-east-1 = "10.100.8.0/22"
+ gnb-aaa-us-west-2 = "10.104.8.0/22"
+ gnb-bbb-us-east-1 = "10.108.8.0/22"
+ gnb-bbb-us-west-2 = "10.112.8.0/22"
+ gnb-ccc-us-east-1 = "10.116.8.0/22"
+ gnb-ccc-us-west-2 = "10.120.8.0/22"
+ gnb-ddd-us-east-1 = "10.124.8.0/22"
+ gnb-ddd-us-east-2 = "10.128.8.0/22"
+}
+```
+
+Separating the configuration (`Source`) from the data (`Variables`) is
+considered best practice when using stacks:
+
+- This makes the source easily testable outside of Guardrails.
+- You can add new VPC IP assignments by simply editing the `Variables` - the
+ `Source` does not change.
+- At times, you may wish to use calculated policies to set the configuration
+ based on other data in the Guardrails CMDB. Rendering the input variables in
+ nunjucks is much simpler than rendering the whole Terraform source.
+
+#### Set the `AWS > VPC > Stack`
+
+At this point, we are ready to enable the stack control.
+
+For this example, we will set the `Variables` policy on the parent folder
+(**Goliath**), as we would like the configuration to apply to all accounts below
+that folder. We will navigate to the folder, and set the `AWS > VPC > Stack` to
+`Enforce: Configured`.
+
+In a few seconds, the stack control will run for each region in scope, and will
+create new VPCs in each of the regions of all accounts in scope!
diff --git a/docs/using/standard/standard_controls.png b/docs/using/standard/standard_controls.png
new file mode 100644
index 00000000..ae77b08d
Binary files /dev/null and b/docs/using/standard/standard_controls.png differ
diff --git a/docs/using/standard/tagging/calc-policy.png b/docs/using/standard/tagging/calc-policy.png
new file mode 100644
index 00000000..fa8e7a55
Binary files /dev/null and b/docs/using/standard/tagging/calc-policy.png differ
diff --git a/docs/using/standard/tagging/dynamic-tags.md b/docs/using/standard/tagging/dynamic-tags.md
new file mode 100644
index 00000000..cfa82218
--- /dev/null
+++ b/docs/using/standard/tagging/dynamic-tags.md
@@ -0,0 +1,358 @@
+---
+title: Dynamic Tags
+sidebar_label: Dynamic Tags
+---
+
+# Tag Resources with Dynamic Metadata
+
+Org control objectives often include the need to tag resources with metadata of the resource or dynamic metadata from other sources, such as a
+[Guardrails File](/guardrails/docs/guides/configuring-guardrails/files). This guide will go over three different scenarios:
+
+- Tag an S3 bucket with an attribute in the bucket metadata.
+- Tag an S3 bucket with attributes stored in a Guardrails File.
+- Tag an S3 bucket with attributes from a
+ [Guardrails Folder](concepts/resources/hierarchy#folders)
+
+
+
+## Initial Configuration
+
+For our initial configuration, let us assume we have an AWS S3 bucket called
+`turbot-test-bucket`.
+
+Assume that we have also set the policy
+[AWS > S3 > Bucket > Tags](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags)
+to `Check: Tags are correct`. This means that Guardrails will only alarm and not
+change any tags on the resource itself.
+
+Each example will be defining a calculated policy using
+[AWS > S3 > Bucket > Tags > Template](https://hub.guardrails.turbot.com/mods/aws/policies/aws-s3/bucketTagsTemplate).
+
+## Tagging Resources with CMDB Metadata
+
+This example will use the following S3 bucket metadata:
+
+
+ S3 bucket metadata
+
+```yaml
+AccelerateConfiguration:
+Status: Suspended
+Acl:
+Grants:
+ - Grantee:
+ ID: 6eb349968d9164c06c9c28123456sdfoadjf09a9ee8f79cb36157431f5e9713f
+ Type: CanonicalUser
+ Permission: FULL_CONTROL
+Owner:
+ ID: 6eb349968d9164c06c9c28123456sdfoadjf09a9ee8f79cb36157431f5e9713f
+Cors: {}
+CreationDate: '2020-07-20T17:07:32.000Z'
+Encryption:
+ServerSideEncryptionConfiguration:
+ Rules:
+ - ApplyServerSideEncryptionByDefault:
+ KMSMasterKeyID: alias/turbot/default
+ SSEAlgorithm: 'aws:kms'
+ BucketKeyEnabled: false
+Lifecycle:
+- Filter:
+ And:
+ Prefix: test
+ Tags:
+ - Key: test
+ Value: value
+ ID: new-rule
+ NoncurrentVersionTransitions: []
+ Status: Enabled
+ Transitions:
+ - Days: 9999
+ StorageClass: STANDARD_IA
+LocationConstraint: us-east-2
+Logging: {}
+Name: turbot-test-bucket
+NotificationConfiguration: {}
+Payer: BucketOwner
+Policy:
+Statement:
+ - Action: 's3:GetBucketAcl'
+ Effect: Allow
+ Principal:
+ Service: cloudtrail.amazonaws.com
+ Resource: 'arn:aws:s3:::turbot-test-bucket'
+ Sid: AWSCloudTrailAclCheck20150319
+ - Action: 's3:PutObject'
+ Condition:
+ StringEquals:
+ 's3:x-amz-acl': bucket-owner-full-control
+ Effect: Allow
+ Principal:
+ Service: cloudtrail.amazonaws.com
+ Resource: 'arn:aws:s3:::turbot-test-bucket/AWSLogs/12345678012/*'
+ Sid: AWSCloudTrailWrite20150319
+ - Action: 's3:*'
+ Effect: Allow
+ Principal:
+ Service: config.amazonaws.com
+ Resource:
+ - 'arn:aws:s3:::turbot-test-bucket'
+ - 'arn:aws:s3:::turbot-test-bucket/*'
+ Sid: ConfigRule
+ - Action: 's3:*'
+ Condition:
+ Bool:
+ 'aws:SecureTransport': 'false'
+ Effect: Deny
+ Principal: '*'
+ Resource:
+ - 'arn:aws:s3:::turbot-test-bucket'
+ - 'arn:aws:s3:::turbot-test-bucket/*'
+ Sid: MustBeEncryptedInTransit
+Version: '2012-10-17'
+PolicyStatus:
+IsPublic: false
+PublicAccessBlock:
+BlockPublicAcls: false
+BlockPublicPolicy: false
+IgnorePublicAcls: false
+RestrictPublicBuckets: false
+Replication: {}
+Tags:
+- Key: Owners
+ Value: john Doe
+- Key: Test
+ Value: ''
+- Key: environment
+ Value: DEV
+Versioning:
+MFADelete: Disabled
+Status: Suspended
+Website: {}
+```
+
+
+
+
+
+In this example, we want to ensure that the payer is a tag on the bucket, i.e.
+the key:value pair `payer`:`BucketOwner`. Let's start with the GraphQL query:
+
+```graphql
+{
+ resource {
+ payer: get(path: "Payer")
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+This gives us the following output:
+
+```json
+{
+ "resource": {
+ "region": "us-east-2",
+ "turbot": {
+ "tags": {
+ "Test": "",
+ "Owners": "john Doe",
+ "environment": "DEV"
+ }
+ }
+ }
+}
+```
+
+Note that we can use this `get: path()` function to call a specific attribute.
+This example uses `Payer` and we call the attribute `payer`.
+
+Finally, to implement the logic, we use this nunjucks template:
+
+```nunjucks
+{%- if $.resource.turbot.tags['payer'] == $.resource.payer -%}
+[]
+{%- else -%}
+- payer: '{{ $.resource.payer }}'
+{%- endif -%}
+```
+
+The `AWS > S3 > Bucket > Tags` control will go into alarm if there does not
+exist a tag `payer` with the value defined on the bucket metadata, and will
+state that their should be that tag on the bucket.
+
+### Tagging Resources with Guardrails File Data
+
+A Guardrails File is simply a json data structure that can be referenced in
+calculated policies. Let's assume the file has the following data:
+
+```json
+{
+ "dev": "john doe",
+ "prod": "greg duke",
+ "qa": "gen gomes"
+}
+```
+
+The aka of this file is `owner_env`. It is also possible to use the Guardrails ID,
+which is of the format `220880720738517`.
+
+We will be using the same calculated policy
+[AWS > S3 > Bucket > Tags > Template](https://hub.guardrails.turbot.com/mods/aws/policies/aws-s3/bucketTagsTemplate).
+as in the first example. In the query we need to not only call the resource tags
+but also the Guardrails file.
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+ tag_file: resource(id: "owner_env") {
+ data
+ }
+}
+```
+
+In this scenario, tag the resource with the name of the owner of the particular
+environment (each environment owner is defined in the File). As an
+administrator, assume we know that there can only be three values for the key
+`environment`: `qa`, `prod`, and `dev`.
+
+```nunjucks
+{%- for key, value in $.resource.turbot.tags -%}
+
+
+{%- if not $.resource.turbot.tags.environment -%}
+- environment: "missing"
+{%- elif $.resource.turbot.tags.environment == 'dev' -%}
+- owner: {{ $.tag_file.data.dev }}
+{%- elif $.resource.turbot.tags.environment == 'qa' -%}
+- owner: {{ $.tag_file.data.qa }}
+{%- elif $.resource.turbot.tags.environment == 'prod' -%}
+- owner: {{ $.tag_file.data.prod }}
+{%- else -%}
+- environment: "invalid_value"
+{%- endif -%}
+```
+
+As always, first check for the existence of the key. If the key does exist,
+check it's value to see if it matches with any of the key terms, and if it does,
+create the necessary new tag. Lastly, if the environment key does exist but it
+is not qa, prod, or dev, output that the environment key has an invalid value.
+
+### Tagging Resources with Guardrails Folder Metadata
+
+This example will detail how to pull tagging information about a Guardrails folder
+and apply that tag to all resources within it. The query response will include
+the folder that is "closest to the resource" in the Guardrails hierarchy. For
+example, if there existed folder A and folder B, with B inside of folder A, and
+a resource was inside folder B, the hierarchy would show **A > B > Resource**,
+and folder B is considered "closest."
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+ folder {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+Assume the tag `environment`:`qa` exists on the folder and this must be applied
+to all resources within it. This one is easy - we can just echo the folder tag
+value to set it.
+
+```nunjucks
+{%- if $.folder.turbot.tags.environment -%}
+- environment: {{ $.folder.turbot.tags.environment }}
+{%- else -%}
+- environment: "folder missing tag"
+{%- endif -%}
+```
+
+If the environment tag does not exist on the folder, simply output a static
+value stating there is no tag.
+
+### Tagging Resources with User who Created Resource (and Creation Time)
+
+Guardrails can automate the tagging of resources with the user who created it and
+the time at which it was created. Like these other examples, this will be a
+calculated policy, but this time our query will be a bit different!
+
+Query:
+
+```graphql
+{
+ resource {
+ creator: notifications(filter: "sort: version_id limit:1") {
+ items {
+ actor {
+ identity {
+ turbot {
+ title
+ }
+ }
+ }
+ turbot {
+ createTimestamp
+ }
+ }
+ }
+ }
+}
+```
+
+An example response might look as follows:
+
+```json
+{
+ "resource": {
+ "creator": {
+ "items": [
+ {
+ "actor": {
+ "identity": {
+ "turbot": {
+ "title": "John Doe"
+ }
+ }
+ },
+ "turbot": {
+ "createTimestamp": "2020-09-28T18:42:20.990Z"
+ }
+ }
+ ]
+ }
+ }
+}
+```
+
+In the template, we simply reference the two objects then use the nunjucks
+template to force everything lower case, as well as replacing unapproved
+characters.
+
+Template:
+
+```nunjucks
+{%- set owner = $.resource.creator.items[0].actor.identity.turbot.title -%}
+created_by: "{{ owner | lower | replace(" ", "_") }}"
+
+{%- set create_time = $.resource.creator.items[0].turbot.createTimestamp %}
+created_time: "{{ create_time | lower | replace(".", "_") | replace(":", "-") }}"
+```
+
+This policy can be applied to any resource. Be sure to test the GraphQL query to
+ensure that it is responding with the correct info! Also notice that in the
+second `set` variable line, we remove the trailing `-` to ensure that the
+`created_time` key is a new line and parsable by the policy.
diff --git a/docs/using/standard/tagging/index.md b/docs/using/standard/tagging/index.md
new file mode 100644
index 00000000..f3729833
--- /dev/null
+++ b/docs/using/standard/tagging/index.md
@@ -0,0 +1,197 @@
+---
+title: Tags in Guardrails
+sidebar_label: Tags
+---
+
+# Tags in Guardrails
+
+Tags are a fundamental concept for many organizations. Identification of cloud
+resources across many accounts is trivial, but only if tagging processes are in
+place and understood by users. With Guardrails, we can enforce tags on various
+resource types. This includes, but is not limited to, checking for the following
+scenarios:
+
+- Ensuring all resources have at least one tag.
+- Ensuring all tags are lower (or upper) case to allow for automation.
+- Specific keys must exist.
+- Specific keys AND values must exist.
+
+Guardrails can both check and remediate resources that do not have compliant tags.
+Metadata about the resource stored in CMDB or information from a
+[Guardrails File](/guardrails/docs/guides/configuring-guardrails/files) can be referenced when checking and applying tags.
+
+If you are not familiar with Calculated Policies, check out the
+[Calculated Policies FAQ](concepts/policies/calculated-faq) as well as our
+[7 minute lab](7-minute-labs/calc-policy).
+
+## Tagging Cloud Resources
+
+For any cloud resource that can be tagged, an associated policy in Guardrails exists
+(note that tags are called "Labels" in Google Cloud):
+
+- `AWS > Service > Resource > Tags`
+- `Azure > Service > Resource > Tags`
+- `GCP > Service > Resource > Labels`
+
+For example, if an administrator wanted to enforce tags on an AWS EC2 instance,
+the policy would become `AWS > EC2 > Instance > Tags`. This set of policies is
+the driving mechanism to determine if tags should be checked for violations by
+Guardrails, and if action should be taken when a resource is found to not have the
+correct set of tags.
+
+## Tag Value Reserved Strings
+
+Guardrails uses tag values of `null` and `undefined` as indicators that a tag key
+should be removed. If a user sets these reserved keywords as tag values, in some
+cases this can result in unintentional tag key removal. For this to happen, the
+following conditions must be met:
+
+- Tags policy is set to `Enforce`.
+- The tag key most be specified in the Tags Template policy.
+- The tag value set by the user is `null` or `undefined`. If the tag keys aren't
+ specified in the template, then Guardrails will ignore them.
+
+## Tagging Templates
+
+Tagging templates allow flexibility in assigning tags for various resources
+across a wide number of accounts. A policy will check all resources within the
+scope for the correct tags. If a tag exists but should not, it is removed. Tags
+that do not exist but should will be added by Guardrails.
+
+A basic tagging template is a YAML list with static values. Consider the policy
+`AWS > EC2 > Instance > Tags > Template`. In this example, instances are
+required to have a `Cost Center`, `Environment`, and `Account Owner` tags. These
+tags do not change throughout the account, and thus the policy can be set at the
+folder level of which the AWS account is a child of (recommended) or on the AWS
+account within Guardrails.
+
+```yaml
+- Cost Center: "Security"
+- Environment: "Dev"
+- Account Owner: "John Doe"
+```
+
+If the policy `AWS > EC2 > Instance > Tags` is set to `Enforce: Set tags`,
+Guardrails will take action on any EC2 instance without the required set of tags.
+
+## Add, Update or Remove Tags using Tagging Templates
+
+Adding, updating or removing tags can be done in a straightforward way. The tags
+template asserts which tags that should or should not be set on the resource.
+NOTE: If a resource has tags that are not described in the Tags Template, then
+Guardrails will ignore those tags. Only tags defined in the template are processed.
+
+### Add
+
+To add a new tag, specify it in the template. If the tag already exists on the
+resource, then Guardrails will update that tag to the specified value.
+
+```yaml
+- SomeTag: ReallyImportantTagValueV1
+```
+
+### Remove Tag
+
+To remove a tag, set the value to `null`.
+
+```yaml
+- SomeTag: null
+```
+
+### Update Tag Value
+
+Updating a tag value on a resource is done by updating the tag value in the tags
+template. The approach is the same as adding a new tag.
+
+```yaml
+- SomeTag: ReallyImportantTagValueV2
+```
+
+### Update Tag Key
+
+To change a tag key, one must destroy the old tag then create a new one. Use the
+approach described in "Remove Tag" to proceed.
+
+```yaml
+- SomeTag: null
+- SomeNewTag: NewReallyImportantTagValue
+```
+
+## Dynamic Tagging
+
+Using the tagging template example above, it becomes trivial to enforce a set of
+tags on a variety of resources. However, many organizations have more complex
+tagging requirements, such as not only ensuring that AWS IAM users have an email
+tag, but also validating that the tag is in fact an email.
+
+Continuing to use the above example, the
+`AWS > EC2 > Instance > Tags > Template` in the new policy view has the option
+to `Switch to calculated mode`. The policy window then changes to allow users to
+write custom [Calculated Policies](/guardrails/docs/concepts/policies/calculated-faq).
+
+### Examples
+
+For all the examples, use the following query in the calculated policy, using
+`AWS > EC2 > Instance > Tags > Template`:
+
+```grapqhql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+### Alarm if key does not exist
+
+If the key `cost_center` does not exist, output `cost_center`:`missing_tag`.
+Else, simply output a blank array. Guardrails will alarm if the tag is not correct.
+
+Template:
+
+```nunjucks
+{%- if 'cost_center' not in $.resource.turbot.tags -%} {# Check for the key cost_center #}
+- cost_center: 'missing_tags'
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+### Alarm if key:value pair does not exist
+
+If the key:value pair `cost_center`:`Security` does not exist, output
+`cost_center`:`Security`. Else, simply output a blank array. Guardrails will alarm
+if the tag is not correct.
+
+Template:
+
+```nunjucks
+{%- if 'costcenter' not in $.resource.turbot.tags-%} {# Check for the key cost_center #}
+- cost_center: 'Security'
+{%- elif 'Security' != $.resource.turbot.tags.costcenter -%} {# Check for the value of key cost_center #}
+- cost_center: 'Security'
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+### Alarm if a Resource has no Tags
+
+A simple use case for Guardrails tagging controls is to check resources for the
+existence of tags.
+
+Template:
+
+```nunjucks
+{# Checks if there are any tags #}
+{% if $.resource.turbot.tags | length == 0 -%}
+"tag_compliance": "untagged_resource" {# temp placeholder to mark it untagged #}
+{% else -%}
+[] {# if there are tags, do nothing #}
+{%- endif %}
+```
+
+If there are tags, the template policy returns a blank array (`[]`). If there
+are no tags, the tagging control will alarm saying that a new tag must be added.
diff --git a/docs/using/standard/tagging/require-keys.md b/docs/using/standard/tagging/require-keys.md
new file mode 100644
index 00000000..a385dc1d
--- /dev/null
+++ b/docs/using/standard/tagging/require-keys.md
@@ -0,0 +1,173 @@
+---
+title: Require Keys
+sidebar_label: Require Keys
+---
+
+# Requiring Tag Keys with Guardrails Tagging Guardrails
+
+Requiring specific tags on cloud resources is a fundamental control objective
+for many organizations. This guide will overview some basics when it comes to
+verifying specific keys exist. The first scenario is requiring a key with any
+value except `null`, and the second is requiring specific keys with specific
+values.
+
+
+
+## Initial Configuration
+
+For our initial configuration, let us assume we have an AWS S3 bucket called
+`turbot-test-bucket` with the following tags:
+
+| Key | Value |
+| ----------- | -------- |
+| Test | `null` |
+| environment | DEV |
+| owner | john Doe |
+
+Assume that we have also set the policy
+[AWS > S3 > Bucket > Tags](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags)
+to `Check: Tags are correct`. This means that Guardrails will only alarm and not
+change any tags on the resource itself.
+
+## Tagging with Guardrails
+
+For both scenarios, we will be setting a calculated policy using
+[AWS > S3 > Bucket > Tags > Template](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags--template).
+
+We will also use the same GraphQL query for both calculated policies:
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+### Require Specific Keys with Any Value Except `null`
+
+This is a simple test as an empty string is functionally equivalent to `null`,
+so we only need to test for the existence of a value. This can be accomplished
+via the following Nunjucks template:
+
+```nunjucks
+{%- if $.resource.turbot.tags['Test'] -%}
+[]
+{%- else -%}
+- Test: not approved
+{%- endif -%}
+```
+
+Note that this test is case sensitive! We can, however, reference our
+[guide that ignores casing on tags](concepts/guardrails/tagging/tag-casing) and
+adjust our template:
+
+```nunjucks
+{%- set approved = 'no' -%}
+
+{%- for key,value in $.resource.turbot.tags -%}
+ {%- if r/test/.test(key | lower) -%}
+ {%- if $.resource.turbot.tags[key] %}
+ {%- set approved = 'yes' -%}
+ {%- endif %}
+ {%- endif -%}
+{%- endfor -%}
+
+{%- if approved == 'no' -%}
+- Test: not approved
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+Applying these template policies will check the S3 bucket for the tag `Test`,
+with the bottom template ignoring casing, and the control will alarm if the tag
+`Test` has a `null` value or the key `Test` does not exist.
+
+### Require Specific Keys with Specific Values
+
+This is very similar to the above example, and in fact we can reuse the
+templates with a very slight modification. Let's assume we want to check for the
+key: value pair `Test`:`example`.
+
+For the case sensitive scenario:
+
+```nunjucks
+{%- if $.resource.turbot.tags['Test'] == 'example' -%}
+[]
+{%- else -%}
+- Test: not approved
+{%- endif -%}
+```
+
+To ignore casing in the key:
+
+```nunjucks
+{%- set approved = 'no' -%}
+
+{%- for key,value in $.resource.turbot.tags -%}
+ {%- if r/test/.test(key | lower) -%}
+ {%- if $.resource.turbot.tags[key] == 'example' %}
+ {%- set approved = 'yes' -%}
+ {%- endif %}
+ {%- endif -%}
+{%- endfor -%}
+
+{%- if approved == 'no' -%}
+- Test: not approved
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+Further, we can ignore casing in the key _and_ value:
+
+```nunjucks
+{%- set approved = 'no' -%}
+
+{%- for key,value in $.resource.turbot.tags -%}
+ {%- if r/test/.test(key | lower) -%}
+ {%- if r/example/.test(value | lower) %}
+ {%- set approved = 'yes' -%}
+ {%- endif %}
+ {%- endif -%}
+{%- endfor -%}
+
+{%- if approved == 'no' -%}
+- Test: not approved
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+### Require a Specific Selection of Values
+
+This example will allow an array of values that a key can be, and if the key
+either does not exist or the value is not in the list, we will set the value to
+be `Non-Compliant Tag`. This example is very similar to our
+[Calculated Policy 7 minute lab](7-minute-labs/calc-policy).
+
+Our query will remain the same as in the other examples:
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+For the sake of this example, we simply want to have the key `Environment` set
+to `QA`, `Prod`, `Dev`, or `Temp`. If the existing value is none of those, set
+the tag value to `Non-Compliant Tag`. Note how we can use logical expressions
+within the quotes. This can be expanded upon to as many tags as required.
+
+```nunjucks
+Environment: "{% if $.bucket.turbot.tags['Environment'] in ['Dev', 'QA', 'Prod', 'Temp'] %}{{ $.bucket.turbot.tags['Environment'] }}{% else %}Non-Compliant Tag{% endif %}"
+```
diff --git a/docs/using/standard/tagging/tag-casing.md b/docs/using/standard/tagging/tag-casing.md
new file mode 100644
index 00000000..cc52cf5c
--- /dev/null
+++ b/docs/using/standard/tagging/tag-casing.md
@@ -0,0 +1,156 @@
+---
+title: Tag Casing
+sidebar_label: Tag Casing
+---
+
+# Resource Tagging and Handling Key:Value Casing
+
+Upper and lower case characters can lead to false positives. With Guardrails, we can
+use calculated policies to check for tags regardless of casing, reducing false
+positives and allowing users and administrators to focus on real business
+improvements. Additionally, a calculated policy can be written to automatically
+fix values that should be either all lower or all upper case. Note that existing
+keys CANNOT be changed (this is done to protect any existing tag).
+
+
+
+## Initial Configuration
+
+For our initial configuration, let us assume we have an AWS S3 bucket called
+`turbot-test-bucket` with the following tags:
+
+| Key | Value |
+| ----------- | -------- |
+| Test | Tag |
+| environment | DEV |
+| owner | john Doe |
+
+Assume that we have also set the policy
+[AWS > S3 > Bucket > Tags](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags)
+to `Check: Tags are correct`. This means that Guardrails will only alarm and not
+change any tags on the resource itself.
+
+## Tagging with Guardrails
+
+### Check Tags, Ignoring Casing
+
+Using Guardrails, we can define a policy
+[AWS > S3 > Bucket > Tags > Template](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags--template)
+with logic that is case agnostic.
+
+First, let's start with the GraphQL query. We want to just pull in the resource
+tags:
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+If our template looked like the following:
+
+```nunjucks
+{%- if $.resource.turbot.tags['owner'] == 'john doe' -%}
+[]
+{%- else -%}
+- 'owner': 'invalid_tag'
+{%- endif -%}
+```
+
+Guardrails would evaluate the control `AWS > S3 > Bucket > Tags` to `Alarm` due to
+the casing on the tag value `john Doe`. To get around this, we use
+[RegEx](guides/nunjucks#regex) to evaluate the string. If we are confident in
+the casing of the key, it is possible to do something simple like so:
+
+```nunjucks
+{%- if r/john doe/.test($.resource.turbot.tags['owner'] | lower) -%}
+[]
+{%- else -%}
+- 'owner': 'invalid_tag'
+{%- endif -%}
+```
+
+However, real applications are usually not so trivial. To account for the casing
+differences with the key AND value, we need to add some additional lines of
+code:
+
+
+
+```nunjucks
+{%- set approved = 'no' -%}
+
+{%- for key,value in $.resource.turbot.tags -%}
+ {%- if r/owners/.test(key | lower) -%}
+ {%- if r/john doe/.test(value | lower) %}
+ {%- set approved = 'yes' -%}
+ {%- endif %}
+ {%- endif -%}
+{%- endfor -%}
+
+{%- if approved == 'no' -%}
+- owner: 'Missing_tag'
+{%- else -%}
+[]
+{%- endif -%}
+```
+
+First, set a variable that is used to denote if the key: value pair exists.
+Then, parse out the key and value pairs using a for loop, check for the key
+first, and if the key exists, check for the value. If both the key and value if
+statement evaluate to true, we set the dummy variable to `yes` and in the final
+if statement, simply pass an empty array denoting the tags are approved. Because
+our bucket has the key:value pair `Owners`:`john Doe`, it passes with flying
+colors!
+
+### Check Tags, Change Casing
+
+Using Guardrails, we can define a policy
+[AWS > S3 > Bucket > Tags > Template](/guardrails/docs/mods/aws/aws-s3/policy#aws--s3--bucket--tags--template)
+with logic that is case agnostic.
+
+As above, let's start with the GraphQL query. We want to just pull in the
+resource tags:
+
+```graphql
+{
+ resource {
+ turbot {
+ tags
+ }
+ }
+}
+```
+
+We want to check to make sure the key `owner` exists, then change the value to
+be all lower case.
+
+```nunjucks
+{%- set regExp = r/owners/ -%}
+{%- set set_key = 0 -%}
+
+{%- for key, value in $.resource.turbot.tags -%}
+{%- set lower_value = (value | lower) -%}
+{%- if regExp.test(key | lower) and lower_value != value -%}
+ - {{ key }}: {{ lower_value }}
+ {%- set set_key = 1 -%}
+{%- endif -%}
+{%- endfor -%}
+
+{%- if set_key == 0 -%}
+[]
+{%- endif -%}
+```
+
+In this template, set a variable that can be used as a boolean that changes
+value only if the lower case tag change is necessary. If there is no change, we
+want to be sure to output a blank array. We can utilize Regex to test the key to
+ensure we are looking at the right one, then test the existing value with
+another string that has had the `lower` function applied. If those strings don't
+match, the result of the template is to change the current value with the lower
+case value.
diff --git a/docs/using/standard/tagging/tagging-helpers.md b/docs/using/standard/tagging/tagging-helpers.md
new file mode 100644
index 00000000..3d02b24d
--- /dev/null
+++ b/docs/using/standard/tagging/tagging-helpers.md
@@ -0,0 +1,469 @@
+---
+title: Tagging Helpers
+sidebar_label: Tagging Helpers
+---
+
+# Tagging Helpers
+
+To help with complex tagging use cases, Guardrails offers additional functionality to assist in writing calculated policies for tagging. Collectively, these improvements are known as "Tagging Helpers".
+
+## createdBy and createTimestamp
+
+A common tagging requirement is to tag a resource with the identity of the creator and the time it was created. Here is an example graphql query for the resource metadata (which includes the creation information).
+```graphql
+{
+ resource {
+ metadata
+ }
+}
+```
+Query results:
+```yaml
+metadata:
+ aws:
+ accountId: 012345678912
+ partition: aws
+ region: us-east-1
+ createTimestamp: 2023-01-28T05:31:46.000Z
+ createdBy: "arn:aws:sts::013122550996:user/dwight"
+```
+
+### createdBy data source
+
+Guardrails populates the createdBy attribute based on the identity found in the creation event. For resources that exist prior to Guardrails discovering them, createdBy will be set to null. The format for the createdBy value varies by cloud provider:
+
+**AWS**
+- userIdentity.arn: The full ARN of the identity that created the resource.
+
+**Azure**
+- initiatedBy.userPrincipalName (Active Directory resources)
+- caller (Azure resources)
+
+**GCP**
+- authenticationInfo.principalEmail
+
+### Example of how to use createdBy and createTimestamp
+
+This example shows a generic `template_input` and `template` that will work for any AWS, Azure or GCP resource type.
+
+template_input:
+```graphql
+{
+ resource {
+ metadata
+ turbot{ tags }
+ }
+}
+```
+
+```nunjucks
+{# As createdBy and createTimestamp can be null, it's important to test that they are available. -#}
+{% if $.resource.metadata.createdBy %}
+- "creator": "{{ $.resource.metadata.createdBy }}"
+{% endif %}
+{% if $.resource.metadata.createTimestamp %}
+- "createTimestamp": "{{ $.resource.metadata.createTimestamp }}"
+{% endif %}
+```
+
+## Tag Maps with setAttribute
+
+In more complex tagging scenarios, accumulating tag key:value pairs into a map can assist in writing clean readable code. Nunjucks does not natively supply a way to create mutable dictionaries. To overcome this limitation, the `setAttribute()` function can help. The function accepts a dictionary object and two string parameters.
+
+**Template**
+```nunjucks
+{% set currentTags = {"Key1":"Value1"} -%}
+{% set currentTags = setAttribute(currentTags, "Key2", "ValueTwo") %}
+{% set currentTags = setAttribute(currentTags, "Key1", "ValueOne") %}
+{% for key,value in currentTags -%}
+- "{{key}}": "{{value}}"
+{% endfor -%}
+```
+
+**Output**
+With output of:
+```yaml
+- "Key1": "ValueOne"
+- "Key2": "ValueTwo"
+```
+
+Note: Appending to arrays is not supported by this function but can be accomplished in other ways.
+
+## Rectify and cleanup bad keys and values
+
+Fixing incorrect keys and values is the most common tagging use case. The `transformMap` function can be used in calculated policies to easily process rules across all tags on any given resource.
+
+### transformMap(tags_map, rules) -> transformed_map
+
+Transforms `tags_map` based on `rules` and returns `transformed_map`; the `tags_map` paramater and the `transformed_map` return value are simple arrays of `key:value` pairs e.g.:
+
+```json
+{
+ "foo": "bar",
+ "fizz": "buzz",
+ "crop": "beets"
+}
+```
+or
+```yaml
+- foo: bar,
+- fizz: buzz,
+- crop: beets
+```
+
+The `rules` object must conform to a specific schema which will be outlined in a series of examples. All examples will use the following starting `tags_map` (the current tags on the resource):
+
+```yaml
+- Env: prd,
+- CostCenter: scranton-1138,
+- owner: dwight
+```
+
+### Example: Create remediated tags while preserving existing tags
+
+**Rules**
+```yaml
+environment:
+ incorrectKeys:
+ - Env
+```
+
+**Transformed Tags**
+```yaml
+- "CostCenter": "scranton-1138"
+- "Env": "prd"
+- "environment": "prd"
+- "owner": "dwight"
+```
+
+### Example: Replace an incorrect tag key.
+
+**Rules**
+```yaml
+environment:
+ incorrectKeys:
+ - Env
+ replacementValue: undefined
+cost_center:
+ incorrectKeys:
+ - CostCenter
+ replacementValue: undefined
+```
+
+_Reminder: "undefined" is a reserved value in Guardrails to indicate a tag that should be removed!_
+
+**Transformed Tags**
+```yaml
+- "cost_center": "scranton-1138"
+- "environment": "prd"
+- "owner": "dwight"
+```
+
+### Example: Replace an incorrect tag value.
+
+**Rules**
+```yaml
+owner:
+ values:
+ dwight.schrute@dmi.com:
+ incorrectValues:
+ - dwight
+ - dks
+ - dwight.schrute
+ pam.beasly@dmi.com:
+ incorrectValues:
+ - Beasly
+ - pam
+```
+
+**Transformed Tags**
+```yaml
+- "CostCenter": "scranton-1138"
+- "Env": "prd"
+- "owner": "dwight.schrute@dmi.com"
+```
+
+### Example: Combine value and key replacement.
+
+**Rules**
+```yaml
+environment:
+ incorrectKeys:
+ - Env
+ replacementValue: undefined
+ values:
+ production:
+ incorrectValues:
+ - prod
+ - prd
+ - PROD
+ development:
+ incorrectValues:
+ - dev
+ - DEV
+cost_center:
+ incorrectKeys:
+ - CostCenter
+ replacementValue: undefined
+ values:
+ SCR1138:
+ incorrectValues:
+ - scranton-1138
+ NSH1234:
+ incorrectValues:
+ - nashua-1234
+owner:
+ values:
+ dwight.schrute@dmi.com:
+ incorrectValues:
+ - dwight
+ - dks
+ - dwight.schrute
+ pam.beasly@dmi.com:
+ incorrectValues:
+ - Beasly
+ - pam
+```
+
+**Transformed Tags**
+```yaml
+- "cost_center": "SCR1138"
+- "environment": "production"
+- "owner": "dwight.schrute@dmi.com"
+```
+
+### Example: Using regex matches
+
+Regular expressions can be used in `incorrectValues` and `incorrectKeys` are identified by this regex:
+```
+^/((?:\\/|[^/])*)/([dgimsuy]*)$
+```
+Malformed regexes are treated as string literals.
+
+**Rules**
+```yaml
+environment:
+ incorrectKeys:
+ - /env.*/gi
+ replacementValue: undefined
+ values:
+ production:
+ incorrectValues:
+ - /pr.*/gi
+ development:
+ incorrectValues:
+ - /dev.*/gi
+cost_center:
+ incorrectKeys:
+ - /cost.*cent.*/gi
+ replacementValue: undefined
+ values:
+ SCR1138:
+ incorrectValues:
+ - /.*1138.*/
+ NSH1234:
+ incorrectValues:
+ - /.*1234.*/
+```
+
+**Transformed Tags**
+```yaml
+- "cost_center": "SCR1138"
+- "environment": "production"
+- "owner": "dwight"
+```
+
+### Edge Cases
+- If there are multiple matches for an incorrect value then the first alphabetical match for the correct key will be used.
+- Malformed regexes are treated as string literals.
+- If there is no match for the incorrectKeys or in incorrectValues, the output map will match the input.
+- Multiple matches for an incorrect value will result in the the first alphabetical match being used.
+
+## Rules Schema
+
+### Structure of the Rules YAML
+
+The transformMap function expects a JSON object with the following structure:
+
+```json
+{
+ "key1": {
+ "incorrectKeys": [
+ "badkey1a",
+ "badkey1b"
+ ],
+ "replacementValue": "newKey1",
+ "values": {
+ "value1": {
+ "incorrectValues": [
+ "badValue1a",
+ "badValue1b"
+ ]
+ }
+ }
+ },
+ "key2": {
+ "incorrectKeys": [
+ "badkey2a",
+ "badkey2b"
+ ],
+ "replacementValue": "newKey2",
+ "values": {
+ "value2": {
+ "incorrectValues": [
+ "badValue2a",
+ "badValue2b"
+ ]
+ }
+ }
+ }
+}
+```
+
+The rules object can be stored in Guardrails using the policy `Turbot > Tags > Transform Rules`. When setting this policy via the Guardrails console yaml format can be used in addition to json:
+
+```yaml
+key1:
+ incorrectKeys:
+ - badkey1a
+ - badkey1b
+ replacementValue: newKey1
+ values:
+ value1:
+ incorrectValues:
+ - badValue1a
+ - badValue1b
+key2:
+ incorrectKeys:
+ - badkey2a
+ - badkey2b
+ replacementValue: newKey2
+ values:
+ value2:
+ incorrectValues:
+ - badValue2a
+ - badValue2b
+```
+
+## Storing rules in a Guardrails File
+
+The recommended way of managing transform rules as code, is to store them in a `Guardrails File`. Here is an example terraform template for creating a Guardrails file.
+
+```hcl
+resource "turbot_file" "tag_rules" {
+ parent = "tmod:@turbot/turbot#/"
+ title = "Tag Transform Rules"
+ akas = ["tag_rules"]
+ content = <<-EOT
+ {
+ "key1": {
+ "incorrectKeys": [
+ "badkey1a",
+ "badkey1b"
+ ],
+ "replacementValue": "newKey1",
+ "values": {
+ "value1": {
+ "incorrectValues": [
+ "badValue1a",
+ "badValue1b"
+ ]
+ }
+ }
+ },
+ "key2": {
+ "incorrectKeys": [
+ "badkey2a",
+ "badkey2b"
+ ],
+ "replacementValue": "newKey2",
+ "values": {
+ "value2": {
+ "incorrectValues": [
+ "badValue2a",
+ "badValue2b"
+ ]
+ }
+ }
+ }
+ }
+ EOT
+}
+```
+
+Guardrails Files only accept JSON, but YAML can still be used for the rules here by using the built-in YAML and JSON encode and decode functions in Terraform:
+
+```hcl
+locals {
+ yaml_string = <<-EOT
+ key1:
+ incorrectKeys:
+ - badkey1a
+ - badkey1b
+ replacementValue: newKey1
+ values:
+ value1:
+ incorrectValues:
+ - badValue1a
+ - badValue1b
+ key2:
+ incorrectKeys:
+ - badkey2a
+ - badkey2b
+ replacementValue: newKey2
+ values:
+ value2:
+ incorrectValues:
+ - badValue2a
+ - badValue2b
+ EOT
+}
+
+resource "turbot_file" "tag_rules" {
+ parent = "tmod:@turbot/turbot#/"
+ title = "Tag Transform Rules"
+ akas = ["tag_rules"]
+ content = jsonencode(yamldecode(local.yaml_string))
+}
+```
+
+## Example Calculated Policy
+
+The example creates a Policy Pack, sets the `AWS > S3 > Bucket > Tags` guardrail to `Enforce: Set tags`, and creates our calculated policy that reads the rules from the Guardrails File specified in the previous section.
+
+```hcl
+resource "turbot_policy_pack" "tag_transform_example" {
+ parent = "tmod:@turbot/turbot#/"
+ title = "Tagging Transformation Example"
+}
+
+resource "turbot_policy_setting" "aws_s3_bucket_tags" {
+ resource = turbot_policy_pack.tag_transform_example.id
+ type = "tmod:@turbot/aws-s3#/policy/types/bucketTags"
+ value = "Enforce: Set tags"
+}
+
+resource "turbot_policy_setting" "aws_s3_bucket_tags_template" {
+ resource = turbot_policy_pack.tag_transform_example.id
+ type = "tmod:@turbot/aws-s3#/policy/types/bucketTagsTemplate"
+ template_input = <<-EOT
+ {
+ rules: resource(id:"tag_rules") {
+ data
+ }
+ resource {
+ turbot {
+ tags
+ }
+ }
+ }
+ EOT
+ template = <<-EOT
+ {%- set tags_map = $.resource.turbot.tags -%}
+ {%- set rules = $.rules.data -%}
+ {% for key,value in transformMap(tags_map, rules) -%}
+ - "{{key}}": "{{value}}"
+ {% endfor -%}
+ EOT
+}
+```
diff --git a/docs/using/standard/trusted-access.md b/docs/using/standard/trusted-access.md
new file mode 100644
index 00000000..fe58b271
--- /dev/null
+++ b/docs/using/standard/trusted-access.md
@@ -0,0 +1,248 @@
+---
+title: Trusted Access Guardrails
+sidebar_label: Trusted Access
+---
+
+# Trusted Access Guardrails
+
+## Overview
+
+Trusted Access guardrails allow you to define whom and what you trust and
+enforce those limitations on your cloud resources. With Guardrails Trusted Access
+policies, you can define which accounts, services, and organizations are allowed
+to be granted access your resources. The Trusted Access control can audit or
+enforce those policies, giving centralized control over trusted boundaries.
+
+Many examples here will list AWS, but these policies also are available for
+Azure and GCP resources.
+
+## Policies and Controls
+
+Trusted Access controls are generally divided into two patterns:
+
+- [Simple List Pattern](#simple-list-pattern)
+
+- [IAM Resource Policy Pattern](#iam-resource-policy-pattern)
+
+## Default Policies
+
+Default policies at the account level allow administrators to define trusted
+boundaries centrally for all services. However, these can be overrode by either
+defining resource type specific Trusted Access policies, or by setting an
+exception for the default policy.
+
+### Account-level Defaults
+
+The value for all of the account-level default policies is to allow everything:
+`*`
+
+| Policy | Description |
+| ------------------------------------------------------ | ------------------------------ |
+| `AWS > Account > Trusted Accounts [Default]` | A list of AWS account IDs |
+| `AWS > Account > Trusted Organizations [Default]` | A list of AWS organization IDs |
+| `AWS > Account > Trusted Identity Providers [Default]` | A list of Identity providers |
+| `AWS > Account > Trusted Service [Default]` | A list of AWS services |
+
+### Service-level Defaults
+
+The value for all of the service-level default policies is to allow everything:
+`*`
+
+| Policy | Description |
+| -------------------------------------------------------- | ------------------------------ |
+| `AWS > {Service} > Trusted Accounts [Default]` | A list of AWS account IDs |
+| `AWS > {Service} > Trusted Organizations [Default]` | A list of AWS organization IDs |
+| `AWS > {Service} > Trusted Identity Providers [Default]` | A list of Identity providers |
+| `AWS > {Service} > Trusted Service [Default]` | A list of AWS services |
+
+### Simple List Pattern
+
+Some resource types allow you to grant access to other accounts.
+
+Guardrails solves this with two policies:
+
+- `Trusted Access`: Allows you check or enforce whether the sharing is allowed
+ or not, and to which accounts. Allows administrators to configure if Guardrails
+ will check or enforce Trusted Access.
+- `Trusted Access > Accounts`: Allows you to specify the list of AWS account IDs
+ that are trusted.
+
+For resources that support cross account access, Guardrails can check or enforce to
+the list of AWS accounts. These policies can be found directly under the service
+in the hierarchy:
+
+- `{Provider} > {Service} > {Resource} > Trusted Access`
+- `{Provider} > {Service} > {Resource} > Trusted Access > Accounts`
+
+
+
Example: Trusted Access policies for EC2 Snapshots:
+
+ AWS > EC2 > Snapshot > Trusted Account AWS > EC2 > Snapshot > Trusted Account > Accounts
+
+
Example: S3 Trusted Access policy family:
+
+ AWS > S3 > Bucket > Policy > Trusted AccessAWS > S3 > Bucket > Policy > Trusted Access > AccountsAWS > S3 > Bucket > Policy > Trusted Access > Organization RestrictionAWS > S3 > Bucket > Policy > Trusted Access > Identity ProvidersAWS > S3 > Bucket > Policy > Trusted Access > CloudFront Origin Access IdentitiesAWS > S3 > Bucket > Policy > Trusted Access > Services
+
+
+ AWS > EC2 > Instance > Usage GCP > Network > Firewall > Usage
+
+
+ AWS > EC2 > Instance > Usage > LimitGCP > Network > Firewall > Usage > Limit
+
+ Assume the organization wants to be notified at 50 instances, but this is a soft limit. The following policies could be set:
+
+ AWS > EC2 > Instance > Usage > Limit set to 50.AWS > EC2 > Instance > Usage set to Check: Usage <= 100% of limit
+ When the number of EC2 instances within said account reaches 50, the Usage control will generate an alert.
+
+ Assume the organization wants to be notified at 50 instances, and accounts must not have more than this limit at any one time (aka hard limit). The following policies could be set:
+
+ AWS > EC2 > Instance > Usage > Limit set to 50.AWS > EC2 > Instance > Usage set to Check: Usage<= 85% of limit
+ When the number of EC2 instances within said account reaches 43, the Usage control will generate an alert. This allows administrators to monitor the account prior to reaching the organizational restriction of 50 instances per account.
+
