FAST: add example of custom org policy condition to bootstrap README

fast/stages/0-bootstrap/README.md

@@ -14,18 +14,22 @@ Use the following diagram as a simple high level reference for the following sec
   <img src="diagram.svg" alt="Organization-level diagram">
 </p>
 
-## Table of contents
-
+<!-- BEGIN TOC -->
 - [Design overview and choices](#design-overview-and-choices)
   - [User groups](#user-groups)
   - [Organization-level IAM](#organization-level-iam)
+  - [Organization policies and tag-based conditions](#organization-policies-and-tag-based-conditions)
   - [Automation project and resources](#automation-project-and-resources)
   - [Billing account](#billing-account)
   - [Organization-level logging](#organization-level-logging)
   - [Naming](#naming)
   - [Workload Identity Federation and CI/CD](#workload-identity-federation-and-cicd)
 - [How to run this stage](#how-to-run-this-stage)
   - [Prerequisites](#prerequisites)
+    - [Standalone billing account](#standalone-billing-account)
+    - [Preventing creation of billing-related IAM bindings](#preventing-creation-of-billing-related-iam-bindings)
+    - [Groups](#groups)
+    - [Configure variables](#configure-variables)
   - [Output files and cross-stage variables](#output-files-and-cross-stage-variables)
   - [Running the stage](#running-the-stage)
 - [Customizations](#customizations)
@@ -35,6 +39,10 @@ Use the following diagram as a simple high level reference for the following sec
   - [Names and naming convention](#names-and-naming-convention)
   - [Workload Identity Federation](#workload-identity-federation)
   - [CI/CD repositories](#cicd-repositories)
+- [Files](#files)
+- [Variables](#variables)
+- [Outputs](#outputs)
+<!-- END TOC -->
 
 ## Design overview and choices
 
@@ -76,6 +84,38 @@ Management of the rest of the tag hierarchy is delegated to the resource managem
 
 The organization policy tag key and values managed by this stage have been added to the `0-bootstrap.auto.tfvars` stage, so that IAM can be delegated to the resource management or successive stages via their ids.
 
+The following example shows an example on how to define an additional tag value, and use it in a boolean constraint rule.
+
+This snippet defines a new tag value under the `org-policies` tag key via the `org_policies_config` variable, and assigns the permission to bind it to a group.
+
+```hcl
+# stage 0 custom tfvars
+org_policies_config = {
+  tag_values = {
+    compute-require-oslogin-false = {
+      description = "Bind this tag to set oslogin to false."
+      iam = {
+        "roles/resourcemanager.tagUser" = [
+          "group:[email protected]"
+        ]
+      }
+    }
+  }
+}
+# tftest skip
+```
+
+The above tag can be used to define a constraint condition via the `data/org-policies/compute.yaml` or similar factory file. The id in the condition is the organization id, followed by the name of the organization policy tag key (defaults to `org-policies`).
+
+```yaml
+compute.requireOsLogin:
+  rules:
+  - enforce: true
+  - enforce: false
+    condition:
+      expression: resource.matchTag('12345678/org-policies-config', 'compute-require-oslogin-false')
+```
+
 ### Automation project and resources
 
 One other design choice worth mentioning here is using a single automation project for all foundational stages. We trade off some complexity on the API side (single source for usage quota, multiple service activation) for increased flexibility and simpler operations, while still effectively providing the same degree of separation via resource-level IAM.

fast/stages/0-bootstrap/organization.tf

@@ -191,7 +191,9 @@ module "organization" {
       description = "Organization policy conditions."
       iam         = {}
       values = merge(
-        { allowed-policy-member-domains-all = {} },
+        {
+          allowed-policy-member-domains-all = {}
+        },
         var.org_policies_config.tag_values
       )
     }