From 15487078d438e5fd13a7b32427db7bda7dad7392 Mon Sep 17 00:00:00 2001
From: James D'Alfonso
Date: Mon, 13 Feb 2023 10:00:50 +0100
Subject: [PATCH 01/44] add missing iam properties to factory_subnets
---
modules/net-vpc/subnets.tf | 3 +++
1 file changed, 3 insertions(+)
diff --git a/modules/net-vpc/subnets.tf b/modules/net-vpc/subnets.tf
index ae094ecfa0..7c03bfca3b 100644
--- a/modules/net-vpc/subnets.tf
+++ b/modules/net-vpc/subnets.tf
@@ -31,6 +31,9 @@ locals {
flow_logs_config = try(v.flow_logs, null)
ipv6 = try(v.ipv6, null)
secondary_ip_ranges = try(v.secondary_ip_ranges, null)
+ iam_groups = try(v.iam_groups, [])
+ iam_users = try(v.iam_users, [])
+ iam_service_accounts = try(v.iam_service_accounts, [])
}
}
_factory_subnets_iam = [
From ebc4bc51a519247f4a900d021e4d913bebd4e8d9 Mon Sep 17 00:00:00 2001
From: lcaggio
Date: Mon, 13 Feb 2023 15:25:24 +0100
Subject: [PATCH 02/44] Workaround to mitigate issue 9164
---
blueprints/data-solutions/data-playground/main.tf | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/blueprints/data-solutions/data-playground/main.tf b/blueprints/data-solutions/data-playground/main.tf
index b87e8e7301..548bee37d1 100644
--- a/blueprints/data-solutions/data-playground/main.tf
+++ b/blueprints/data-solutions/data-playground/main.tf
@@ -217,6 +217,11 @@ resource "google_notebooks_instance" "playground" {
service_account = module.service-account-notebook.email
+ # Remove once terraform-provider-google/issues/9164 is fixed
+ lifecycle {
+ ignore_changes = [disk_encryption, kms_key]
+ }
+
#TODO Uncomment once terraform-provider-google/issues/9273 is fixed
# tags = ["ssh"]
depends_on = [
From 7bbeac805e1dde5d1c14e52368606073755342a9 Mon Sep 17 00:00:00 2001
From: lcaggio
Date: Tue, 14 Feb 2023 08:43:15 +0100
Subject: [PATCH 03/44] Add 'max_time_travel_hours ' on BQ module
---
modules/bigquery-dataset/README.md | 9 +++++----
modules/bigquery-dataset/main.tf | 2 +-
modules/bigquery-dataset/variables.tf | 13 +++++--------
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/modules/bigquery-dataset/README.md b/modules/bigquery-dataset/README.md
index 381ffab7ce..6dbd120c20 100644
--- a/modules/bigquery-dataset/README.md
+++ b/modules/bigquery-dataset/README.md
@@ -67,6 +67,7 @@ module "bigquery-dataset" {
default_table_expiration_ms = 3600000
default_partition_expiration_ms = null
delete_contents_on_destroy = false
+ max_time_travel_hours = 168
}
}
# tftest modules=1 resources=1
@@ -178,7 +179,7 @@ module "bigquery-dataset" {
| name | description | type | required | default |
|---|---|:---:|:---:|:---:|
| [id](variables.tf#L69) | Dataset id. | string
| ✓ | |
-| [project_id](variables.tf#L100) | Id of the project where datasets will be created. | string
| ✓ | |
+| [project_id](variables.tf#L97) | Id of the project where datasets will be created. | string
| ✓ | |
| [access](variables.tf#L17) | Map of access rules with role and identity type. Keys are arbitrary and must match those in the `access_identities` variable, types are `domain`, `group`, `special_group`, `user`, `view`. | map(object({…}))
| | {}
|
| [access_identities](variables.tf#L33) | Map of access identities used for basic access roles. View identities have the format 'project_id\|dataset_id\|table_id'. | map(string)
| | {}
|
| [dataset_access](variables.tf#L39) | Set access in the dataset resource instead of using separate resources. | bool
| | false
|
@@ -188,9 +189,9 @@ module "bigquery-dataset" {
| [iam](variables.tf#L63) | IAM bindings in {ROLE => [MEMBERS]} format. Mutually exclusive with the access_* variables used for basic roles. | map(list(string))
| | {}
|
| [labels](variables.tf#L74) | Dataset labels. | map(string)
| | {}
|
| [location](variables.tf#L80) | Dataset location. | string
| | "EU"
|
-| [options](variables.tf#L86) | Dataset options. | object({…})
| | {…}
|
-| [tables](variables.tf#L105) | Table definitions. Options and partitioning default to null. Partitioning can only use `range` or `time`, set the unused one to null. | map(object({…}))
| | {}
|
-| [views](variables.tf#L133) | View definitions. | map(object({…}))
| | {}
|
+| [options](variables.tf#L86) | Dataset options. | object({…})
| | {}
|
+| [tables](variables.tf#L102) | Table definitions. Options and partitioning default to null. Partitioning can only use `range` or `time`, set the unused one to null. | map(object({…}))
| | {}
|
+| [views](variables.tf#L130) | View definitions. | map(object({…}))
| | {}
|
## Outputs
diff --git a/modules/bigquery-dataset/main.tf b/modules/bigquery-dataset/main.tf
index 47f8fcb53b..f832cd85c3 100644
--- a/modules/bigquery-dataset/main.tf
+++ b/modules/bigquery-dataset/main.tf
@@ -42,7 +42,7 @@ resource "google_bigquery_dataset" "default" {
delete_contents_on_destroy = var.options.delete_contents_on_destroy
default_table_expiration_ms = var.options.default_table_expiration_ms
default_partition_expiration_ms = var.options.default_partition_expiration_ms
-
+ max_time_travel_hours = var.options.max_time_travel_hours
dynamic "access" {
for_each = var.dataset_access ? local.access_domain : {}
content {
diff --git a/modules/bigquery-dataset/variables.tf b/modules/bigquery-dataset/variables.tf
index 5f8028abfb..b44b66585b 100644
--- a/modules/bigquery-dataset/variables.tf
+++ b/modules/bigquery-dataset/variables.tf
@@ -86,15 +86,12 @@ variable "location" {
variable "options" {
description = "Dataset options."
type = object({
- default_table_expiration_ms = number
- default_partition_expiration_ms = number
- delete_contents_on_destroy = bool
+ default_table_expiration_ms = optional(number, null)
+ default_partition_expiration_ms = optional(number, null)
+ delete_contents_on_destroy = optional(bool, false)
+ max_time_travel_hours = optional(number, 168)
})
- default = {
- default_table_expiration_ms = null
- default_partition_expiration_ms = null
- delete_contents_on_destroy = false
- }
+ default = {}
}
variable "project_id" {
From 742b5bab62ab29f573f707cd9f43d417893f91e0 Mon Sep 17 00:00:00 2001
From: Julio Castillo
Date: Tue, 14 Feb 2023 11:29:19 +0200
Subject: [PATCH 04/44] Fix tfvars sample for fast bootstrap stage
---
fast/stages/0-bootstrap/terraform.tfvars.sample | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fast/stages/0-bootstrap/terraform.tfvars.sample b/fast/stages/0-bootstrap/terraform.tfvars.sample
index 66710ba4a6..a134f8dc5d 100644
--- a/fast/stages/0-bootstrap/terraform.tfvars.sample
+++ b/fast/stages/0-bootstrap/terraform.tfvars.sample
@@ -1,15 +1,14 @@
# use `gcloud beta billing accounts list`
# if you have too many accounts, check the Cloud Console :)
billing_account = {
- id = "012345-67890A-BCDEF0"
- organization_id = 1234567890
+ id = "012345-67890A-BCDEF0"
}
# use `gcloud organizations list`
organization = {
- domain = "example.org"
- id = 1234567890
- customer_id = "C000001"
+ domain = "example.org"
+ id = 1234567890
+ customer_id = "C000001"
}
outputs_location = "~/fast-config"
From e8334857ff46b12c2396214675bb8e15c6284eec Mon Sep 17 00:00:00 2001
From: Chema Polo
Date: Wed, 15 Feb 2023 06:28:47 +0100
Subject: [PATCH 05/44] Update main.tf (#1158)
replaced .secondary_pod_range by var.pod_range.secondary_pod_range that is the object which contins create, cidr an name attributes.
---
modules/gke-nodepool/main.tf | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/modules/gke-nodepool/main.tf b/modules/gke-nodepool/main.tf
index ad0c053f35..9ae4cf2844 100644
--- a/modules/gke-nodepool/main.tf
+++ b/modules/gke-nodepool/main.tf
@@ -115,9 +115,9 @@ resource "google_container_node_pool" "nodepool" {
dynamic "network_config" {
for_each = var.pod_range != null ? [""] : []
content {
- create_pod_range = var.pod_range.create
- pod_ipv4_cidr_block = var.pod_range.cidr
- pod_range = var.pod_range.name
+ create_pod_range = var.pod_range.secondary_pod_range.create
+ pod_ipv4_cidr_block = var.pod_range.secondary_pod_range.cidr
+ pod_range = var.pod_range.secondary_pod_range.name
}
}
From 36a7347744b84fe38e463feff18d785d890afc32 Mon Sep 17 00:00:00 2001
From: Ludovico Magnocavallo
Date: Wed, 15 Feb 2023 06:42:14 +0100
Subject: [PATCH 06/44] FAST stage docs cleanup (#1145)
* top-level and stage 0
* stage 1
* net peering
* networking
* networking
* security
* gke, dp
* checks
---
fast/stage-links.sh | 5 +
fast/stages/0-bootstrap/README.md | 111 ++++++-----
fast/stages/1-resman/README.md | 74 +++++---
fast/stages/2-networking-a-peering/README.md | 170 ++++++++++-------
fast/stages/2-networking-b-vpn/README.md | 166 ++++++++++-------
fast/stages/2-networking-c-nva/README.md | 173 +++++++++++-------
.../2-networking-d-separate-envs/README.md | 163 ++++++++++-------
fast/stages/2-security/README.md | 82 +++++----
fast/stages/3-data-platform/dev/README.md | 103 ++++++-----
fast/stages/3-gke-multitenant/dev/README.md | 108 ++++++-----
fast/stages/CLEANUP.md | 14 +-
fast/stages/COMPANION.md | 56 +++---
fast/stages/FAQ.md | 42 ++---
13 files changed, 740 insertions(+), 527 deletions(-)
diff --git a/fast/stage-links.sh b/fast/stage-links.sh
index 79d1973fa1..52c9e5ae6d 100755
--- a/fast/stage-links.sh
+++ b/fast/stage-links.sh
@@ -78,6 +78,11 @@ case $STAGE_NAME in
TFVARS="tfvars/0-bootstrap.auto.tfvars.json
tfvars/1-resman.auto.tfvars.json"
;;
+"2-security"*)
+ PROVIDER="providers/2-security-providers.tf"
+ TFVARS="tfvars/0-bootstrap.auto.tfvars.json
+ tfvars/1-resman.auto.tfvars.json"
+ ;;
*)
# check for a "dev" stage 3
echo "no stage found, trying for parent stage 3..."
diff --git a/fast/stages/0-bootstrap/README.md b/fast/stages/0-bootstrap/README.md
index 2cab11510d..e1bb2948a4 100644
--- a/fast/stages/0-bootstrap/README.md
+++ b/fast/stages/0-bootstrap/README.md
@@ -14,6 +14,28 @@ Use the following diagram as a simple high level reference for the following sec
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [User groups](#user-groups)
+ - [Organization-level IAM](#organization-level-iam)
+ - [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)
+ - [Output files and cross-stage variables](#output-files-and-cross-stage-variables)
+ - [Running the stage](#running-the-stage)
+- [Customizations](#customizations)
+ - [Group names](#group-names)
+ - [IAM](#iam)
+ - [Log sinks and log destinations](#log-sinks-and-log-destinations)
+ - [Names and naming convention](#names-and-naming-convention)
+ - [Workload Identity Federation](#workload-identity-federation)
+ - [CI/CD repositories](#cicd-repositories)
+
## Design overview and choices
As mentioned above, this stage only does the bare minimum required to bootstrap automation, and ensure that base audit and billing exports are in place from the start to provide some measure of accountability, even before the security configurations are applied in a later stage.
@@ -80,7 +102,7 @@ The convention is used in its full form only for specific resources with globall
The [Customizations](#names-and-naming-convention) section on names below explains how to configure tokens, or implement a different naming convention.
-## Workload Identity Federation and CI/CD
+### Workload Identity Federation and CI/CD
This stage also implements initial support for two interrelated features
@@ -124,7 +146,7 @@ To quickly self-grant the above roles, run the following code snippet as the ini
export FAST_BU=$(gcloud config list --format 'value(core.account)')
# find and set your org id
-gcloud organizations list --filter display_name:$partofyourdomain
+gcloud organizations list
export FAST_ORG_ID=123456
# set needed roles
@@ -139,25 +161,6 @@ done
Then make sure the same user is also part of the `gcp-organization-admins` group so that impersonating the automation service account later on will be possible.
-#### Billing account in a different organization
-
-If you are using a billing account belonging to a different organization (e.g. in multiple organization setups), some initial configurations are needed to ensure the identities running this stage can assign billing-related roles.
-
-If the billing organization is managed by another version of this stage, we leverage the `organizationIamAdmin` role created there, to allow restricted granting of billing roles at the organization level.
-
-If that's not the case, an equivalent role needs to exist, or the predefined `resourcemanager.organizationAdmin` role can be used if not managed authoritatively. The role name then needs to be manually changed in the `billing.tf` file, in the `google_organization_iam_binding` resource.
-
-The identity applying this stage for the first time also needs two roles in billing organization, they can be removed after the first `apply` completes successfully:
-
-```bash
-export FAST_BILLING_ORG_ID=789012
-export FAST_ROLES=(roles/billing.admin roles/resourcemanager.organizationAdmin)
-for role in $FAST_ROLES; do
- gcloud organizations add-iam-policy-binding $FAST_BILLING_ORG_ID \
- --member user:$FAST_BU --role $role
-done
-```
-
#### Standalone billing account
If you are using a standalone billing account, the identity applying this stage for the first time needs to be a billing account administrator:
@@ -187,7 +190,7 @@ Please note that FAST also supports an additional group for users with permissio
Then make sure you have configured the correct values for the following variables by providing a `terraform.tfvars` file:
- `billing_account`
- an object containing `id` as the id of your billing account, derived from the Cloud Console UI or by running `gcloud beta billing accounts list`, and `organization_id` as the id of the organization owning it, or `null` to use the billing account in isolation
+ an object containing `id` as the id of your billing account, derived from the Cloud Console UI or by running `gcloud beta billing accounts list`, and the `is_org_level` flag that controls whether organization or account-level bindings are used, and a billing export project and dataset are created
- `groups`
the name mappings for your groups, if you're following the default convention you can leave this to the provided default
- `organization.id`, `organization.domain`, `organization.customer_id`
@@ -202,7 +205,6 @@ You can also adapt the example that follows to your needs:
# if you have too many accounts, check the Cloud Console :)
billing_account = {
id = "012345-67890A-BCDEF0"
- organization_id = 1234567890
}
# use `gcloud organizations list`
@@ -237,18 +239,18 @@ Below is the outline of the output files generated by all stages, which is ident
```bash
[path specified in outputs_location]
├── providers
-│ ├── 00-bootstrap-providers.tf
-│ ├── 01-resman-providers.tf
-│ ├── 02-networking-providers.tf
-│ ├── 02-security-providers.tf
-│ ├── 03-project-factory-dev-providers.tf
-│ ├── 03-project-factory-prod-providers.tf
-│ └── 99-sandbox-providers.tf
+│ ├── 0-bootstrap-providers.tf
+│ ├── 1-resman-providers.tf
+│ ├── 2-networking-providers.tf
+│ ├── 2-security-providers.tf
+│ ├── 3-project-factory-dev-providers.tf
+│ ├── 3-project-factory-prod-providers.tf
+│ └── 9-sandbox-providers.tf
└── tfvars
-│ ├── 00-bootstrap.auto.tfvars.json
-│ ├── 01-resman.auto.tfvars.json
-│ ├── 02-networking.auto.tfvars.json
-│ └── 02-security.auto.tfvars.json
+│ ├── 0-bootstrap.auto.tfvars.json
+│ ├── 1-resman.auto.tfvars.json
+│ ├── 2-networking.auto.tfvars.json
+│ └── 2-security.auto.tfvars.json
└── workflows
└── [optional depending on the configured CI/CD repositories]
```
@@ -267,17 +269,34 @@ terraform apply \
> If you see an error related to project name already exists, please make sure the project name is unique or the project was not deleted recently
-Once the initial `apply` completes successfully, configure a remote backend using the new GCS bucket, and impersonation on the automation service account for this stage. To do this you can use the generated `providers.tf` file if you have configured output files as described above, or extract its contents from Terraform's output, then migrate state with `terraform init`:
+Once the initial `apply` completes successfully, configure a remote backend using the new GCS bucket, and impersonation on the automation service account for this stage. To do this you can use the generated `providers.tf` file from either
+
+- the local filesystem if you have configured output files as described above
+- the GCS bucket where output files are always stored
+- Terraform outputs (not recommended as it's more complex)
+
+The following two snippets show how to leverage the `stage-links.sh` script in the root FAST folder to fetch the commands required for output files linking or copying, using either the local output folder configured via Terraform variables, or the GCS bucket which can be derived from the `automation` output.
+
+```bash
+../../stage-links.sh ~/fast-config
+
+# copy and paste the following commands for '0-bootstrap'
+
+ln -s ~/fast-config/providers/0-bootstrap-providers.tf ./
+```
+
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '0-bootstrap'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/0-bootstrap-providers.tf ./
+```
+
+Copy/paste the command returned by the script to link or copy the provider file, then migrate state with `terraform init` and run `terraform apply`:
```bash
-# if using output files via the outputs_location and set to `~/fast-config`
-ln -s ~/fast-config/providers/00-bootstrap* ./
-# or from outputs if not using output files
-terraform output -json providers | jq -r '.["00-bootstrap"]' \
- > providers.tf
-# migrate state to GCS bucket configured in providers file
terraform init -migrate-state
-# run terraform apply to remove the bootstrap_user iam binding
terraform apply
```
@@ -334,7 +353,7 @@ You can customize organization-level logs through the `log_sinks` variable in tw
- creating additional log sinks to capture more logs
- changing the destination of captured logs
-By default, all logs are exported to Bigquery, but FAST can create sinks to Cloud Logging Buckets, GCS, or PubSub.
+By default, all logs are exported to a log bucket, but FAST can create sinks to BigQuery, GCS, or PubSub.
If you need to capture additional logs, please refer to GCP's documentation on [scenarios for exporting logging data](https://cloud.google.com/architecture/exporting-stackdriver-logging-for-security-and-access-analytics), where you can find ready-made filter expressions for different use cases.
@@ -400,12 +419,6 @@ cicd_repositories = {
name = "my-gh-org/fast-bootstrap"
type = "github"
}
- cicd = {
- branch = null
- identity_provider = "github-sample"
- name = "my-gh-org/fast-cicd"
- type = "github"
- }
resman = {
branch = "main"
identity_provider = "github-sample"
diff --git a/fast/stages/1-resman/README.md b/fast/stages/1-resman/README.md
index c2091eb50a..971c69633d 100644
--- a/fast/stages/1-resman/README.md
+++ b/fast/stages/1-resman/README.md
@@ -13,6 +13,22 @@ The following diagram is a high level reference of the resources created and man
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [Multitenancy](#multitenancy)
+ - [Workload Identity Federation and CI/CD](#workload-identity-federation-and-cicd)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+- [Customizations](#customizations)
+ - [Team folders](#team-folders)
+ - [Organization Policies](#organization-policies)
+ - [IAM](#iam)
+ - [Additional folders](#additional-folders)
+
## Design overview and choices
Despite its simplicity, this stage implements the basics of a design that we've seen working well for a variety of customers, where the hierarchy is laid out following two conceptually different approaches:
@@ -54,51 +70,49 @@ It's of course possible to run this stage in isolation, but that's outside the s
Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-### Providers configuration
-
-The default way of making sure you have the right permissions, is to use the identity of the service account pre-created for this stage during bootstrap, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
+### Provider and Terraform variables
-To simplify setup, the previous stage pre-configures a valid providers file in its output, and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
-If you have set a valid value for `outputs_location` in the bootstrap stage (see the [bootstrap stage README](../0-bootstrap/#output-files-and-cross-stage-variables) for more details), simply link the relevant `providers.tf` file from this stage's folder in the path you specified:
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/01-resman-providers.tf .
-```
+../../stage-links.sh ~/fast-config
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage's outputs:
+# copy and paste the following commands for '1-resman'
-```bash
-cd ../0-bootstrap
-terraform output -json providers | jq -r '.["01-resman"]' \
- > ../1-resman/providers.tf
+ln -s ~/fast-config/providers/1-resman-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
```
-If you want to continue to rely on `outputs_location` logic, create a `terraform.tfvars` file and configure it as described [here](../0-bootstrap/#output-files-and-cross-stage-variables).
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
-### Variable configuration
+# copy and paste the following commands for '1-resman'
-There are two broad sets of variables you will need to fill in:
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/1-resman-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+```
-- variables shared by other stages (org id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
+### Impersonating the automation service account
-To avoid the tedious job of filling in the first group of variable with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
-If you configured a valid path for `outputs_location` in the bootstrap stage, simply link the relevant `*.auto.tfvars.json` files from the outputs folder. For this stage, you need the `globals.auto.tfvars.json` file containing global values compiled manually for the bootstrap stage, and `0-bootstrap.auto.tfvars.json` containing values derived from resources managed by the bootstrap stage:
+### Variable configuration
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json .
-```
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
+
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` file linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-A second set of variables is specific to this stage, they are all optional so if you need to customize them, create an extra `terraform.tfvars` file.
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
-Refer to the [Variables](#variables) table at the bottom of this document, for a full list of variables, their origin (e.g. a stage or specific to this one), and descriptions explaining their meaning. The sections below also describe some of the possible customizations. For billing configurations, refer to the [Bootstrap documentation on billing](../0-bootstrap/README.md#billing-account) as the `billing_account` variable is identical across all stages.
+### Running the stage
-Once done, you can run this stage:
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
```bash
terraform init
@@ -139,9 +153,9 @@ This allows to centralize the minimum set of resources to delegate control of ea
### Organization policies
-Organization policies are laid out in an explicit manner in the `organization.tf` file, so it's fairly easy to add or remove specific policies.
+Organization policies leverage -- with one exception -- the built-in factory implemented in the organization module, and configured via the yaml files in the `data` folder. To edit organization policies, check and edit the files there.
-For policies where additional data is needed, a root-level `organization_policy_configs` variable allows passing in specific data. Its built-in use to add additional organizations to the [Domain Restricted Sharing](https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains) policy, can be taken as an example on how to leverage it for additional customizations.
+The one exception is [Domain Restricted Sharing](https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domains), which is made dynamic and implemented in code so as to auto-add the current organization's customer id. The `organization_policy_configs` variable allow to easily add ids from third party organizations if needed.
### IAM
diff --git a/fast/stages/2-networking-a-peering/README.md b/fast/stages/2-networking-a-peering/README.md
index 7966ce80bb..c066423cdd 100644
--- a/fast/stages/2-networking-a-peering/README.md
+++ b/fast/stages/2-networking-a-peering/README.md
@@ -15,6 +15,33 @@ The following diagram illustrates the high-level design, and should be used as a
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [VPC design](#vpc-design)
+ - [External connectivity](#external-connectivity)
+ - [Internal connectivity](#internal-connectivity)
+ - [IP ranges, subnetting, routing](#ip-ranges-subnetting-routing)
+ - [Internet egress](#internet-egress)
+ - [VPC and Hierarchical Firewall](#vpc-and-hierarchical-firewall)
+ - [DNS](#dns)
+- [Stage structure and files layout](#stage-structure-and-files-layout)
+ - [VPCs](#vpcs)
+ - [VPNs](#vpns)
+ - [Routing and BGP](#routing-and-bgp)
+ - [Firewall](#firewall)
+ - [DNS architecture](#dns-architecture)
+ - [Private Google Access](#private-google-access)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+ - [Post-deployment activities](#post-deployment-activities)
+- [Customizations](#customizations)
+ - [Changing default regions](#changing-default-regions)
+ - [Adding an environment](#adding-an-environment)
+
## Design overview and choices
### VPC design
@@ -44,13 +71,13 @@ As mentioned initially, there are of course other ways to implement internal con
This is a summary of the main options:
-- [HA VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies) (implemented by [02-networking-vpn](../2-networking-b-vpn/))
+- [HA VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies) (implemented by [2-networking-vpn](../2-networking-b-vpn/))
- Pros: simple compatibility with GCP services that leverage peering internally, better control on routes, avoids peering groups shared quotas and limits
- Cons: additional cost, marginal increase in latency, requires multiple tunnels for full bandwidth
- [VPC Peering](https://cloud.google.com/vpc/docs/vpc-peering) (implemented here)
- Pros: no additional costs, full bandwidth with no configurations, no extra latency, total environment isolation
- Cons: no transitivity (e.g. to GKE masters, Cloud SQL, etc.), no selective exchange of routes, several quotas and limits shared between VPCs in a peering group
-- [Multi-NIC appliances](https://cloud.google.com/architecture/best-practices-vpc-design#multi-nic) (implemented by [02-networking-nva](../2-networking-c-nva/))
+- [Multi-NIC appliances](https://cloud.google.com/architecture/best-practices-vpc-design#multi-nic) (implemented by [2-networking-nva](../2-networking-c-nva/))
- Pros: additional security features (e.g. IPS), potentially better integration with on-prem systems by using the same vendor
- Cons: complex HA/failover setup, limited by VM bandwidth and scale, additional costs for VMs and licenses, out of band management of a critical cloud component
@@ -120,58 +147,7 @@ From cloud, the `example.com` domain (used as a placeholder) is forwarded to on-
This configuration is battle-tested, and flexible enough to lend itself to simple modifications without subverting its design, for example by forwarding and peering root zones to bypass Cloud DNS external resolution.
-## How to run this stage
-
-This stage is meant to be executed after the [resman](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-
-It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-
-Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-
-### Providers configuration
-
-The default way of making sure you have the right permissions, is to use the identity of the service account pre-created for this stage during the [resource management](../1-resman) stage, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
-
-To simplify setup, the previous stage pre-configures a valid providers file in its output, and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
-
-If you have set a valid value for `outputs_location` in the bootstrap stage, simply link the relevant `providers.tf` file from this stage's folder in the path you specified:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/02-networking-providers.tf .
-```
-
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage's outputs:
-
-```bash
-cd ../1-resman
-terraform output -json providers | jq -r '.["02-networking"]' \
- > ../02-networking/providers.tf
-```
-
-### Variable configuration
-
-There are two broad sets of variables you will need to fill in:
-
-- variables shared by other stages (org id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
-
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
-
-If you have set a valid value for `outputs_location` in the bootstrap and in the resman stage, simply link the relevant `*.auto.tfvars.json` files from this stage's folder in the path you specified.
-The `*` above is set to the name of the stage that produced it, except for `globals.auto.tfvars.json` which is also generated by the bootstrap stage, containing global values compiled manually for the bootstrap stage.
-For this stage, link the following files:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-```
-
-A second set of variables is specific to this stage, they are all optional so if you need to customize them, create an extra `terraform.tfvars` file.
-
-Please refer to the [Variables](#variables) table below for a map of the variable origins, and to the sections below on how to adapt this stage to your networking configuration.
+## Stage structure and files layout
### VPCs
@@ -224,27 +200,64 @@ DNS queries sent to the on-premises infrastructure come from the `35.199.192.0/1
The [Inbound DNS Policy](https://cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-in) defined in module `landing-vpc` ([`landing.tf`](./landing.tf)) automatically reserves the first available IP address on each created subnet (typically the third one in a CIDR) to expose the Cloud DNS service so that it can be consumed from outside of GCP.
-### Private Google Access
+## How to run this stage
-[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-For PGA to work:
+It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-- Private Google Access should be enabled on the subnet. \
-Subnets created by the `net-vpc` module are PGA-enabled by default.
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
-Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC (e.g. see `landing-vpc` in [`landing.tf`](./landing.tf)) has explicit routes set in case the `0.0.0.0/0` route is changed.
+### Provider and Terraform variables
-- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf)
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
+
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
+
+```bash
+../../stage-links.sh ~/fast-config
-### Preliminar activities
+# copy and paste the following commands for '2-networking-a-peering'
-Before running `terraform apply` on this stage, make sure to adapt all of `variables.tf` to your needs, to update all reference to regions (e.g. `europe-west1` or `ew1`) in the whole directory to match your preferences.
+ln -s ~/fast-config/providers/2-networking-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json ./
+```
+
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
-If you're not using FAST, you'll also need to create a `providers.tf` file to configure the GCS backend and the service account to use to run the deployment.
+# copy and paste the following commands for '2-networking-a-peering'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+```
-You're now ready to run `terraform init` and `apply`.
+### Impersonating the automation service account
+
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
+
+### Variable configuration
+
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
+
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` and `1-resman.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
+
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
+
+### Running the stage
+
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
+
+```bash
+terraform init
+terraform apply
+```
### Post-deployment activities
@@ -252,8 +265,29 @@ You're now ready to run `terraform init` and `apply`.
- On-prem routers should accept BGP sessions from their cloud peers.
- On-prem DNS servers should have forward zones for GCP-managed ones.
+#### Private Google Access
+
+[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+
+For PGA to work:
+
+- Private Google Access should be enabled on the subnet. \
+Subnets created by the `net-vpc` module are PGA-enabled by default.
+
+- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
+Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC (e.g. see `landing-vpc` in [`landing.tf`](./landing.tf)) has explicit routes set in case the `0.0.0.0/0` route is changed.
+
+- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf)
+
## Customizations
+### Changing default regions
+
+Regions are defined via the `regions` variable which sets up a mapping between the `regions.primary` and `regions.secondary` logical names and actual GCP region names. If you need to change regions from the defaults:
+
+- change the values of the mappings in the `regions` variable to the regions you are going to use
+- change the regions in the factory subnet files in the `data` folder
+
### Adding an environment
To create a new environment (e.g. `staging`), a few changes are required.
@@ -262,10 +296,10 @@ Create a `spoke-staging.tf` file by copying `spoke-prod.tf` file,
and adapt the new file by replacing the value "prod" with the value "staging".
Running `diff spoke-dev.tf spoke-prod.tf` can help to see how environment files differ.
-The new VPC requires a set of dedicated CIDRs, one per region, added to variable `custom_adv` (for example as `spoke_staging_ew1` and `spoke_staging_ew4`).
+The new VPC requires a set of dedicated CIDRs, one per region, added to variable `custom_adv` (for example as `spoke_staging_primary` and `spoke_staging_secondary`).
>`custom_adv` is a map that "resolves" CIDR names to actual addresses, and will be used later to configure routing.
>
-Variables managing L7 Interal Load Balancers (`l7ilb_subnets`) and Private Service Access (`psa_ranges`) should also be adapted, and subnets and firewall rules for the new spoke should be added as described above.
+Variables managing L7 Internal Load Balancers (`l7ilb_subnets`) and Private Service Access (`psa_ranges`) should also be adapted, and subnets and firewall rules for the new spoke should be added as described above.
DNS configurations are centralised in the `dns-*.tf` files. Spokes delegate DNS resolution to Landing through DNS peering, and optionally define a private zone (e.g. `dev.gcp.example.com`) which the landing peers to. To configure DNS for a new environment, copy one of the other environments DNS files [e.g. (dns-dev.tf](dns-dev.tf)) into a new `dns-*.tf` file suffixed with the environment name (e.g. `dns-staging.tf`), and update its content accordingly. Don't forget to add a peering zone from the landing to the newly created environment private zone.
diff --git a/fast/stages/2-networking-b-vpn/README.md b/fast/stages/2-networking-b-vpn/README.md
index 2177f3113b..7a8983d81b 100644
--- a/fast/stages/2-networking-b-vpn/README.md
+++ b/fast/stages/2-networking-b-vpn/README.md
@@ -15,6 +15,33 @@ The following diagram illustrates the high-level design, and should be used as a
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [VPC design](#vpc-design)
+ - [External connectivity](#external-connectivity)
+ - [Internal connectivity](#internal-connectivity)
+ - [IP ranges, subnetting, routing](#ip-ranges-subnetting-routing)
+ - [Internet egress](#internet-egress)
+ - [VPC and Hierarchical Firewall](#vpc-and-hierarchical-firewall)
+ - [DNS](#dns)
+- [Stage structure and files layout](#stage-structure-and-files-layout)
+ - [VPCs](#vpcs)
+ - [VPNs](#vpns)
+ - [Routing and BGP](#routing-and-bgp)
+ - [Firewall](#firewall)
+ - [DNS architecture](#dns-architecture)
+ - [Private Google Access](#private-google-access)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+ - [Post-deployment activities](#post-deployment-activities)
+- [Customizations](#customizations)
+ - [Changing default regions](#changing-default-regions)
+ - [Adding an environment](#adding-an-environment)
+
## Design overview and choices
### VPC design
@@ -45,10 +72,10 @@ This is a summary of the main options:
- [HA VPN](https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies) (implemented here)
- Pros: simple compatibility with GCP services that leverage peering internally, better control on routes, avoids peering groups shared quotas and limits
- Cons: additional cost, marginal increase in latency, requires multiple tunnels for full bandwidth
-- [VPC Peering](https://cloud.google.com/vpc/docs/vpc-peering) (implemented by [02-networking-peering](../2-networking-a-peering/))
+- [VPC Peering](https://cloud.google.com/vpc/docs/vpc-peering) (implemented by [2-networking-peering](../2-networking-a-peering/))
- Pros: no additional costs, full bandwidth with no configurations, no extra latency
- Cons: no transitivity (e.g. to GKE masters, Cloud SQL, etc.), no selective exchange of routes, several quotas and limits shared between VPCs in a peering group
-- [Multi-NIC appliances](https://cloud.google.com/architecture/best-practices-vpc-design#multi-nic) (implemented by [02-networking-nva](../2-networking-c-nva/))
+- [Multi-NIC appliances](https://cloud.google.com/architecture/best-practices-vpc-design#multi-nic) (implemented by [2-networking-nva](../2-networking-c-nva/))
- Pros: additional security features (e.g. IPS), potentially better integration with on-prem systems by using the same vendor
- Cons: complex HA/failover setup, limited by VM bandwidth and scale, additional costs for VMs and licenses, out of band management of a critical cloud component
@@ -126,58 +153,7 @@ From cloud, the `example.com` domain (used as a placeholder) is forwarded to on-
This configuration is battle-tested, and flexible enough to lend itself to simple modifications without subverting its design, for example by forwarding and peering root zones to bypass Cloud DNS external resolution.
-## How to run this stage
-
-This stage is meant to be executed after the [resman](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-
-It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-
-Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-
-### Providers configuration
-
-The default way of making sure you have the right permissions, is to use the identity of the service account pre-created for this stage during the [resource management](../1-resman) stage, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
-
-To simplify setup, the previous stage pre-configures a valid providers file in its output, and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
-
-If you have set a valid value for `outputs_location` in the bootstrap stage, simply link the relevant `providers.tf` file from this stage's folder in the path you specified:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/02-networking-providers.tf .
-```
-
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage's outputs:
-
-```bash
-cd ../1-resman
-terraform output -json providers | jq -r '.["02-networking"]' \
- > ../02-networking/providers.tf
-```
-
-### Variable configuration
-
-There are two broad sets of variables you will need to fill in:
-
-- variables shared by other stages (org id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
-
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
-
-If you have set a valid value for `outputs_location` in the bootstrap and in the resman stage, simply link the relevant `*.auto.tfvars.json` files from this stage's folder in the path you specified.
-The `*` above is set to the name of the stage that produced it, except for `globals.auto.tfvars.json` which is also generated by the bootstrap stage, containing global values compiled manually for the bootstrap stage.
-For this stage, link the following files:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-```
-
-A second set of variables is specific to this stage, they are all optional so if you need to customize them, create an extra `terraform.tfvars` file.
-
-Please refer to the [Variables](#variables) table below for a map of the variable origins, and to the sections below on how to adapt this stage to your networking configuration.
+## Stage structure and files layout
### VPCs
@@ -238,27 +214,64 @@ DNS queries sent to the on-premises infrastructure come from the `35.199.192.0/1
The [Inbound DNS Policy](https://cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-in) defined in module `landing-vpc` ([`landing.tf`](./landing.tf)) automatically reserves the first available IP address on each created subnet (typically the third one in a CIDR) to expose the Cloud DNS service so that it can be consumed from outside of GCP.
-### Private Google Access
+## How to run this stage
-[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-For PGA to work:
+It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-- Private Google Access should be enabled on the subnet. \
-Subnets created by the `net-vpc` module are PGA-enabled by default.
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
-Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC (e.g. see `landing-vpc` in [`landing.tf`](./landing.tf)) has explicit routes set in case the `0.0.0.0/0` route is changed.
+### Provider and Terraform variables
+
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
+
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
+
+```bash
+../../stage-links.sh ~/fast-config
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+ln -s ~/fast-config/providers/2-networking-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json ./
+```
+
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+```
+
+### Impersonating the automation service account
+
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
+
+### Variable configuration
-- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in [dns-landing.tf](./dns-landing.tf)
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
-### Preliminary activities
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` and `1-resman.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-Before running `terraform apply` on this stage, make sure to adapt all of `variables.tf` and `vpn-variables.tf` to your needs, to update all references to regions (e.g. `europe-west1` or `ew1`) in the whole directory to match your preferences.
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
-If you're not using FAST, you'll also need to create a `providers.tf` file to configure the GCS backend and the service account to use to run the deployment.
+### Running the stage
-You're now ready to run `terraform init` and `apply`.
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
+
+```bash
+terraform init
+terraform apply
+```
### Post-deployment activities
@@ -266,8 +279,29 @@ You're now ready to run `terraform init` and `apply`.
- On-prem routers should accept BGP sessions from their cloud peers.
- On-prem DNS servers should have forward zones for GCP-managed ones.
+#### Private Google Access
+
+[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+
+For PGA to work:
+
+- Private Google Access should be enabled on the subnet. \
+Subnets created by the `net-vpc` module are PGA-enabled by default.
+
+- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
+Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC (e.g. see `landing-vpc` in [`landing.tf`](./landing.tf)) has explicit routes set in case the `0.0.0.0/0` route is changed.
+
+- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf)
+
## Customizations
+### Changing default regions
+
+Regions are defined via the `regions` variable which sets up a mapping between the `regions.primary` and `regions.secondary` logical names and actual GCP region names. If you need to change regions from the defaults:
+
+- change the values of the mappings in the `regions` variable to the regions you are going to use
+- change the regions in the factory subnet files in the `data` folder
+
### Adding an environment
To create a new environment (e.g. `staging`), a few changes are required.
diff --git a/fast/stages/2-networking-c-nva/README.md b/fast/stages/2-networking-c-nva/README.md
index 425e1d195e..d0e62fd62a 100644
--- a/fast/stages/2-networking-c-nva/README.md
+++ b/fast/stages/2-networking-c-nva/README.md
@@ -21,6 +21,34 @@ The final number of subnets, and their IP addressing will depend on the user-spe
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [Multi-regional deployment](#multi-regional-deployment)
+ - [VPC design](#vpc-design)
+ - [External connectivity](#external-connectivity)
+ - [Internal connectivity](#internal-connectivity)
+ - [IP ranges, subnetting, routing](#ip-ranges-subnetting-routing)
+ - [Internet egress](#internet-egress)
+ - [VPC and Hierarchical Firewall](#vpc-and-hierarchical-firewall)
+ - [DNS](#dns)
+- [Stage structure and files layout](#stage-structure-and-files-layout)
+ - [VPCs](#vpcs)
+ - [VPNs](#vpns)
+ - [Routing and BGP](#routing-and-bgp)
+ - [Firewall](#firewall)
+ - [DNS architecture](#dns-architecture)
+ - [Private Google Access](#private-google-access)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+ - [Post-deployment activities](#post-deployment-activities)
+- [Customizations](#customizations)
+ - [Changing default regions](#changing-default-regions)
+ - [Adding an environment](#adding-an-environment)
+
## Design overview and choices
### Multi-regional deployment
@@ -190,58 +218,7 @@ In GCP, a forwarding zone in the landing project is configured to forward querie
This configuration is battle-tested, and flexible enough to lend itself to simple modifications without subverting its design.
-## How to run this stage
-
-This stage is meant to be executed after the [resman](../1-resman) stage has run. It leverages the automation service account and the storage bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-
-It's possible to run this stage in isolation, but that's outside of the scope of this document. Please, refer to the previous stages for the environment requirements.
-
-Before running this stage, you need to make sure you have the correct credentials and permissions. You'll also need identify the module variables and make sure you assign them the values that match your configuration.
-
-### Providers configuration
-
-The default way of making sure you have the right permissions, is to use the identity of the service account pre-created for this stage, during the [resource management](../1-resman) stage, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
-
-To simplify the setup, the previous stage pre-configures a valid providers file in its output and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
-
-If you have set a valid value for `outputs_location` in the bootstrap stage, simply link the relevant `providers.tf` file from this stage folder in the path you selected:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/02-networking-providers.tf .
-```
-
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage outputs:
-
-```bash
-cd ../1-resman
-terraform output -json providers | jq -r '.["02-networking"]' \
- > ../2-networking-c-nva/providers.tf
-```
-
-### Variable configuration
-
-There are two broad sets of variables you will need to fill in:
-
-- variables shared by other stages (org id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
-
-To avoid the tedious job of filling in the first group of variables with values derived from other stages outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
-
-If you have set a valid value for `outputs_location` in the bootstrap and in the resman stage, simply link the relevant `*.auto.tfvars.json` files from this stage's folder in the path you specified.
-The `*` above is set to the name of the stage that produced it, except for `globals.auto.tfvars.json` which is also generated by the bootstrap stage, containing global values compiled manually for the bootstrap stage.
-For this stage, link the following files:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-```
-
-A second set of variables is specific to this stage, they are all optional so if you need to customize them, create an extra `terraform.tfvars` file.
-
-Please, refer to the [variables](#variables) table below for a map of the variable origins, and use the sections below to understand how to adapt this stage to your networking configuration.
+## Stage structure and files layout
### VPCs
@@ -286,46 +263,104 @@ Cloud DNS manages onprem forwarding, the main GCP zone (in this example `gcp.exa
The root DNS zone defined in the landing project acts as the source of truth for DNS within the Cloud environment. The resources defined in the spoke VPCs consume the landing DNS infrastructure through DNS peering (e.g. `prod-landing-root-dns-peering`).
The spokes can optionally define private zones (e.g. `prod-dns-private-zone`). Granting visibility both to the trusted and untrusted landing VPCs ensures that the whole cloud environment can query such zones.
-#### Cloud to on-premises
+#### Cloud to on-prem
Leveraging the forwarding zone defined in the landing project (e.g. `onprem-example-dns-forwarding` and `reverse-10-dns-forwarding`), the cloud environment can resolve `in-addr.arpa.` and `onprem.example.com.` using the on-premise DNS infrastructure. On-premise resolver IPs are set in the variable `dns.onprem`.
DNS queries sent to the on-premise infrastructure come from the `35.199.192.0/19` source range.
-#### On-premises to cloud
+#### On-prem to cloud
The [Inbound DNS Policy](https://cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-in) defined in the *trusted landing VPC module* ([`landing.tf`](./landing.tf)) automatically reserves the first available IP address on each subnet (typically the third one in a CIDR) to expose the Cloud DNS service, so that it can be consumed from outside of GCP.
-### Private Google Access
+## How to run this stage
-[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) is configured in this environment. It enables VMs and on-premise systems to consume Google APIs from within the Google network.
+This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-For PGA to work:
+It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-- Private Google Access should be enabled on the subnet. \
-Subnets created using the `net-vpc` module are PGA-enabled by default.
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-premises to the trusted landing VPC, and from there to the `default-internet-gateway`. \
-The `vpn_onprem_configs` variable contains the ranges advertised from GCP to on-premises. Furthermore, the trusted landing VPC (e.g. see `landing-trusted-vpc` in [`landing.tf`](./landing.tf)) has explicit routes to send traffic destined to restricted and private - googleapis.com to the Internet gateway (which works for Google APIs only, and not for the whole Internet, since Cloud NAT is not configured in the trusted landing VPC).
+### Provider and Terraform variables
-- On-premises, a private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain). Its configuration can be copied from the module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf)
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
-### Preliminar activities
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
-Before running `terraform apply`, make sure to adapt `variables.tf` to your needs, to update the variable values using a new `terraform.tfvars` file, and to update the references to the regions in the whole directory, in order to match your preferences (e.g. `europe-west1` or `ew1`).
+```bash
+../../stage-links.sh ~/fast-config
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+ln -s ~/fast-config/providers/2-networking-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json ./
+```
+
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+```
+
+### Impersonating the automation service account
+
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
+
+### Variable configuration
+
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
+
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` and `1-resman.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-If you're not using other FAST stages, you'll also need to create a `providers.tf` file to configure the GCS backend and the service account to use to run the deployment.
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
-You're now ready to run `terraform init` and `terraform apply`.
+### Running the stage
+
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
+
+```bash
+terraform init
+terraform apply
+```
### Post-deployment activities
-- On-premise routers should be configured to advertise all relevant CIDRs to the GCP environments. To avoid hitting GCP quotas, we recommend aggregating routes as much as possible
-- On-premise routers should accept BGP sessions from their cloud peers
-- On-premise DNS servers should have forward zones configured, in order to resolve GCP-managed domains
+- On-prem routers should be configured to advertise all relevant CIDRs to the GCP environments. To avoid hitting GCP quotas, we recomment aggregating routes as much as possible.
+- On-prem routers should accept BGP sessions from their cloud peers.
+- On-prem DNS servers should have forward zones for GCP-managed ones.
+
+#### Private Google Access
+
+[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+
+For PGA to work:
+
+- Private Google Access should be enabled on the subnet. \
+Subnets created by the `net-vpc` module are PGA-enabled by default.
+
+- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
+Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC (e.g. see `landing-vpc` in [`landing.tf`](./landing.tf)) has explicit routes set in case the `0.0.0.0/0` route is changed.
+
+- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf)
## Customizations
+### Changing default regions
+
+Regions are defined via the `regions` variable which sets up a mapping between the `regions.primary` and `regions.secondary` logical names and actual GCP region names. If you need to change regions from the defaults:
+
+- change the values of the mappings in the `regions` variable to the regions you are going to use
+- change the regions in the factory subnet files in the `data` folder
+
### Adding an environment
To create a new environment (e.g. `staging`), a few changes are required:
diff --git a/fast/stages/2-networking-d-separate-envs/README.md b/fast/stages/2-networking-d-separate-envs/README.md
index a461dc97bf..dfc199cd0f 100644
--- a/fast/stages/2-networking-d-separate-envs/README.md
+++ b/fast/stages/2-networking-d-separate-envs/README.md
@@ -1,4 +1,4 @@
-# Networking
+# Networking with separated single environment
This stage sets up the shared network infrastructure for the whole organization. It implements a single shared VPC per environment, where each environment is independently connected to the on-premise environment, to maintain a fully separated routing domain on GCP.
@@ -14,6 +14,31 @@ The following diagram illustrates the high-level design, and should be used as a
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [VPC design](#vpc-design)
+ - [External connectivity](#external-connectivity)
+ - [IP ranges, subnetting, routing](#ip-ranges-subnetting-routing)
+ - [Internet egress](#internet-egress)
+ - [VPC and Hierarchical Firewall](#vpc-and-hierarchical-firewall)
+ - [DNS](#dns)
+- [Stage structure and files layout](#stage-structure-and-files-layout)
+ - [VPCs](#vpcs)
+ - [VPNs](#vpns)
+ - [Routing and BGP](#routing-and-bgp)
+ - [Firewall](#firewall)
+ - [DNS architecture](#dns-architecture)
+ - [Private Google Access](#private-google-access)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+ - [Post-deployment activities](#post-deployment-activities)
+- [Customizations](#customizations)
+ - [Changing default regions](#changing-default-regions)
+
## Design overview and choices
### VPC design
@@ -87,57 +112,7 @@ From cloud, the `example.com` domain (used as a placeholder) is forwarded to on-
This configuration is battle-tested, and flexible enough to lend itself to simple modifications without subverting its design, for example by forwarding and peering root zones to bypass Cloud DNS external resolution.
-## How to run this stage
-
-This stage is meant to be executed after the [resman](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-
-It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-
-Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-
-### Providers configuration
-
-The default way of making sure you have the right permissions, is to use the identity of the service account pre-created for this stage during the [resource management](../1-resman) stage, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
-
-To simplify setup, the previous stage pre-configures a valid providers file in its output, and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
-
-If you have set a valid value for `outputs_location` in the bootstrap stage, simply link the relevant `providers.tf` file from this stage's folder in the path you specified:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/02-networking-providers.tf .
-```
-
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage's outputs:
-
-```bash
-cd ../1-resman
-terraform output -json providers | jq -r '.["02-networking"]' \
- > ../02-networking/providers.tf
-```
-
-### Variable configuration
-
-There are two broad sets of variables you will need to fill in:
-
-- variables shared by other stages (org id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
-
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
-
-If you have set a valid value for `outputs_location` in the bootstrap and in the resman stage, simply link the relevant `terraform-*.auto.tfvars.json` files from this stage's folder in the path you specified, where the `*` above is set to the name of the stage that produced it. For this stage, a single `.tfvars` file is available:
-
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ../../configs/example/02-networking/terraform-bootstrap.auto.tfvars.json
-ln -s ../../configs/example/02-networking/terraform-resman.auto.tfvars.json
-# also copy the tfvars file used for the bootstrap stage
-cp ../0-bootstrap/terraform.tfvars .
-```
-
-A second set of variables is specific to this stage, they are all optional so if you need to customize them, add them to the file copied from bootstrap.
-
-Please refer to the [Variables](#variables) table below for a map of the variable origins, and to the sections below on how to adapt this stage to your networking configuration.
+## Stage structure and files layout
### VPCs
@@ -187,27 +162,64 @@ When implementing this architecture, make sure you'll be able to route packets c
The [Inbound DNS Policy](https://cloud.google.com/dns/docs/server-policies-overview#dns-server-policy-in) defined on eachVPC automatically reserves the first available IP address on each created subnet (typically the third one in a CIDR) to expose the Cloud DNS service so that it can be consumed from outside of GCP.
-### Private Google Access
+## How to run this stage
-[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-For PGA to work:
+It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-- Private Google Access should be enabled on the subnet. \
-Subnets created by the `net-vpc` module are PGA-enabled by default.
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
-Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC has explicit routes set in case the `0.0.0.0/0` route is changed.
+### Provider and Terraform variables
+
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
+
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
+
+```bash
+../../stage-links.sh ~/fast-config
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+ln -s ~/fast-config/providers/2-networking-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json ./
+```
+
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '2-networking-a-peering'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/2-networking-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+```
+
+### Impersonating the automation service account
+
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
+
+### Variable configuration
+
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
-- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain), as implemented in module `googleapis-private-zone` in `dns-xxx.tf`
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` and `1-resman.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-### Preliminar activities
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
-Before running `terraform apply` on this stage, make sure to adapt all of `variables.tf` to your needs, to update all reference to regions (e.g. `europe-west1` or `ew1`) in the whole directory to match your preferences.
+### Running the stage
-If you're not using FAST, you'll also need to create a `providers.tf` file to configure the GCS backend and the service account to use to run the deployment.
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
-You're now ready to run `terraform init` and `apply`.
+```bash
+terraform init
+terraform apply
+```
### Post-deployment activities
@@ -215,6 +227,29 @@ You're now ready to run `terraform init` and `apply`.
- On-prem routers should accept BGP sessions from their cloud peers.
- On-prem DNS servers should have forward zones for GCP-managed ones.
+#### Private Google Access
+
+[Private Google Access](https://cloud.google.com/vpc/docs/private-google-access) (or PGA) enables VMs and on-prem systems to consume Google APIs from within the Google network, and is already fully configured on this environment.
+
+For PGA to work:
+
+- Private Google Access should be enabled on the subnet. \
+Subnets created by the `net-vpc` module are PGA-enabled by default.
+
+- 199.36.153.4/30 (`restricted.googleapis.com`) and 199.36.153.8/30 (`private.googleapis.com`) should be routed from on-prem to VPC, and from there to the `default-internet-gateway`. \
+Per variable `vpn_onprem_configs` such ranges are advertised to onprem - furthermore every VPC has explicit routes set in case the `0.0.0.0/0` route is changed.
+
+- A private DNS zone for `googleapis.com` should be created and configured per [this article](https://cloud.google.com/vpc/docs/configure-private-google-access-hybrid#config-domain)
+
+## Customizations
+
+### Changing default regions
+
+Regions are defined via the `regions` variable which sets up a mapping between the `regions.primary` and `regions.secondary` logical names and actual GCP region names. If you need to change regions from the defaults:
+
+- change the values of the mappings in the `regions` variable to the regions you are going to use
+- change the regions in the factory subnet files in the `data` folder
+
diff --git a/fast/stages/2-security/README.md b/fast/stages/2-security/README.md
index a609cd8144..6486cd7418 100644
--- a/fast/stages/2-security/README.md
+++ b/fast/stages/2-security/README.md
@@ -12,6 +12,24 @@ The following diagram illustrates the high-level design of created resources and
+## Table of contents
+
+- [Design overview and choices](#design-overview-and-choices)
+ - [Cloud KMS](#cloud-kms)
+ - [VPC Service Controls](#vpc-service-controls)
+- [How to run this stage](#how-to-run-this-stage)
+ - [Provider and Terraform variables](#provider-and-terraform-variables)
+ - [Impersonating the automation service account](#impersonating-the-automation-service-account)
+ - [Variable configuration](#variable-configuration)
+ - [Running the stage](#running-the-stage)
+- [Customizations](#customizations)
+ - [KMS keys](#kms-keys)
+ - [VPC Service Controls configuration](#vpc-service-controls-configuration)
+ - [Dry-run vs. enforced](#dry-run-vs-enforced)
+ - [Access levels](#access-levels)
+ - [Ingress and Egress policies](#ingress-and-egress-policies)
+ - [Perimeters](#perimeters)
+
## Design overview and choices
Project-level security resources are grouped into two separate projects, one per environment. This setup matches requirements we frequently observe in real life and provides enough separation without needlessly complicating operations.
@@ -42,57 +60,57 @@ Some care needs to be taken with project membership in perimeters, which can onl
## How to run this stage
-This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the folder and automation resources created there. The relevant user groups must also exist, but that's one of the requirements for the previous stages too, so if you ran those successfully, you're good to go.
-
-It's possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the bootstrap stage for the required roles.
+This stage is meant to be executed after the [resource management](../1-resman) stage has run, as it leverages the automation service account and bucket created there, and additional resources configured in the [bootstrap](../0-bootstrap) stage.
-Before running this stage, you need to ensure you have the correct credentials and permissions, and customize variables by assigning values that match your configuration.
+It's of course possible to run this stage in isolation, but that's outside the scope of this document, and you would need to refer to the code for the previous stages for the environmental requirements.
-### Providers configuration
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-The default way of making sure you have the correct permissions is to use the identity of the service account pre-created for this stage during bootstrap, and that you are a member of the group that can impersonate it via provider-level configuration (`gcp-devops` or `organization-admins`).
+### Provider and Terraform variables
-To simplify setup, the previous stage pre-configures a valid providers file in its output, and optionally writes it to a local file if the `outputs_location` variable is set to a valid path.
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
-If you have set a valid value for `outputs_location` in the resource management stage, simply link the relevant `providers.tf` file from this stage's folder in the path you specified:
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/providers/02-security-providers.tf .
-```
+../../stage-links.sh ~/fast-config
-If you have not configured `outputs_location` in resource management, you can derive the providers file from that stage's outputs:
+# copy and paste the following commands for '2-security'
-```bash
-cd ../1-resman
-terraform output -json providers | jq -r '.["02-security"]' \
- > ../02-security/providers.tf
+ln -s ~/fast-config/providers/2-security-providers.tf ./
+ln -s ~/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json ./
```
-### Variable configuration
+```bash
+../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
-There are two broad sets of variables you will need to fill in:
+# copy and paste the following commands for '2-security'
-- variables shared by other stages (organization id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/2-security-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+```
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
+### Impersonating the automation service account
-If you configured a valid path for `outputs_location` in the previous stages, simply link the relevant `terraform-*.auto.tfvars.json` files from this stage's output folder (under the path you specified), where the `*` above is set to the name of the stage that produced it. For this stage, two `.tfvars` files are available:
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
-```bash
-# `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-# also copy the tfvars file used for the bootstrap stage
-cp ../0-bootstrap/terraform.tfvars .
-```
+### Variable configuration
+
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
+
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `0-bootstrap.auto.tfvars.json` and `1-resman.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-A second set of optional variables is specific to this stage. If you need to customize them add them to the file copied from bootstrap.
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
-Refer to the [Variables](#variables) table at the bottom of this document, for a full list of variables, their origin (e.g., a stage or specific to this one), and descriptions explaining their meaning. The sections below also describe some of the possible customizations.
+### Running the stage
-Once done, you can run this stage:
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
```bash
terraform init
diff --git a/fast/stages/3-data-platform/dev/README.md b/fast/stages/3-data-platform/dev/README.md
index 615dbde8b0..48d09eafc0 100644
--- a/fast/stages/3-data-platform/dev/README.md
+++ b/fast/stages/3-data-platform/dev/README.md
@@ -78,74 +78,91 @@ In the case your Data Warehouse need to handle confidential data and you have th
## How to run this stage
-This stage can be run in isolation by prviding the necessary variables, but it's really meant to be used as part of the FAST flow after the "foundational stages" ([`00-bootstrap`](../../0-bootstrap), [`01-resman`](../../1-resman), [`02-networking`](../../2-networking-b-vpn) and [`02-security`](../../2-security)).
+This stage is meant to be executed after the FAST "foundational" stages: bootstrap, resource management, security and networking stages.
-When running in isolation, the following roles are needed on the principal used to apply Terraform:
+It's of course possible to run this stage in isolation, refer to the *[Running in isolation](#running-in-isolation)* section below for details.
-- on the organization or network folder level
- - `roles/xpnAdmin` or a custom role which includes the following permissions
- - `"compute.organizations.enableXpnResource"`,
- - `"compute.organizations.disableXpnResource"`,
- - `"compute.subnetworks.setIamPolicy"`,
-- on each folder where projects are created
- - `"roles/logging.admin"`
- - `"roles/owner"`
- - `"roles/resourcemanager.folderAdmin"`
- - `"roles/resourcemanager.projectCreator"`
-- on the host project for the Shared VPC
- - `"roles/browser"`
- - `"roles/compute.viewer"`
-- on the organization or billing account
- - `roles/billing.admin`
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
-The VPC host project, VPC and subnets should already exist.
+### Provider and Terraform variables
-### Providers configuration
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
-If you're running this on top of Fast, you should run the following commands to create the providers file, and populate the required variables from the previous stage.
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
```bash
-# Variable `outputs_location` is set to `~/fast-config` in stage 01-resman
-ln -s ~/fast-config/providers/03-data-platform-dev-providers.tf .
-```
+../../../stage-links.sh ~/fast-config
-If you have not configured `outputs_location` in bootstrap, you can derive the providers file from that stage's outputs:
+# copy and paste the following commands for '3-data-platform'
+
+ln -s /home/ludomagno/fast-config/providers/3-data-platform-providers.tf ./
+ln -s /home/ludomagno/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/1-resman.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/2-networking.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/2-security.auto.tfvars.json ./
+```
```bash
-cd ../../1-resman
-terraform output -json providers | jq -r '.["03-data-platform-dev"]' \
- > ../3-data-platform/dev/providers.tf
+../../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '3-data-platform'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/3-data-platform-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/2-networking.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/2-security.auto.tfvars.json ./
```
-### Variable configuration
+### Impersonating the automation service account
-There are two broad sets of variables that can be configured:
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
-- variables shared by other stages (organization id, billing account id, etc.) or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
+### Variable configuration
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
-If you configured a valid path for `outputs_location` in the bootstrap security and networking stages, simply link the relevant `terraform-*.auto.tfvars.json` files from this stage's outputs folder under the path you specified. This will also link the providers configuration file:
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `*.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
-```bash
-# Variable `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/02-networking.auto.tfvars.json .
-# also copy the tfvars file used for the bootstrap stage
-cp ../../0-bootstrap/terraform.tfvars .
-```
+The full list can be found in the [Variables](#variables) table at the bottom of this document.
-If you're not using FAST or its output files, refer to the [Variables](#variables) table at the bottom of this document for a full list of variables, their origin (e.g., a stage or specific to this one), and descriptions explaining their meaning.
+### Running the stage
-Once the configuration is complete you can apply this stage:
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
```bash
terraform init
terraform apply
```
+### Running in isolation
+
+This stage can be run in isolation by providing the necessary variables, but it's really meant to be used as part of the FAST flow after the "foundational stages" ([`0-bootstrap`](../../0-bootstrap), [`1-resman`](../../1-resman), [`2-networking`](../../2-networking-b-vpn) and [`2-security`](../../2-security)).
+
+When running in isolation, the following roles are needed on the principal used to apply Terraform:
+
+- on the organization or network folder level
+ - `roles/xpnAdmin` or a custom role which includes the following permissions
+ - `"compute.organizations.enableXpnResource"`,
+ - `"compute.organizations.disableXpnResource"`,
+ - `"compute.subnetworks.setIamPolicy"`,
+- on each folder where projects are created
+ - `"roles/logging.admin"`
+ - `"roles/owner"`
+ - `"roles/resourcemanager.folderAdmin"`
+ - `"roles/resourcemanager.projectCreator"`
+- on the host project for the Shared VPC
+ - `"roles/browser"`
+ - `"roles/compute.viewer"`
+- on the organization or billing account
+ - `roles/billing.admin`
+
+The VPC host project, VPC and subnets should already exist.
+
## Demo pipeline
The application layer is out of scope of this script. As a demo purpuse only, several Cloud Composer DAGs are provided. Demos will import data from the `landing` area to the `DataWarehouse Confidential` dataset suing different features.
diff --git a/fast/stages/3-gke-multitenant/dev/README.md b/fast/stages/3-gke-multitenant/dev/README.md
index 4accf8e1aa..f0460c06c5 100644
--- a/fast/stages/3-gke-multitenant/dev/README.md
+++ b/fast/stages/3-gke-multitenant/dev/README.md
@@ -39,7 +39,68 @@ This stage creates a project containing and as many clusters and node pools as r
## How to run this stage
-This stage is meant to be executed after "foundational stages" (i.e., stages [`00-bootstrap`](../../0-bootstrap), [`01-resman`](../../1-resman), 02-networking (either [VPN](../../2-networking-b-vpn) or [NVA](../../2-networking-c-nva)) and [`02-security`](../../2-security)) have been run.
+This stage is meant to be executed after the FAST "foundational" stages: bootstrap, resource management, security and networking stages.
+
+It's of course possible to run this stage in isolation, refer to the *[Running in isolation](#running-in-isolation)* section below for details.
+
+Before running this stage, you need to make sure you have the correct credentials and permissions, and localize variables by assigning values that match your configuration.
+
+### Provider and Terraform variables
+
+As all other FAST stages, the [mechanism used to pass variable values and pre-built provider files from one stage to the next](../../0-bootstrap/README.md#output-files-and-cross-stage-variables) is also leveraged here.
+
+The commands to link or copy the provider and terraform variable files can be easily derived from the `stage-links.sh` script in the FAST root folder, passing it a single argument with the local output files folder (if configured) or the GCS output bucket in the automation project (derived from stage 0 outputs). The following examples demonstrate both cases, and the resulting commands that then need to be copy/pasted and run.
+
+```bash
+../../../stage-links.sh ~/fast-config
+
+# copy and paste the following commands for '3-gke-multitenant'
+
+ln -s /home/ludomagno/fast-config/providers/3-gke-multitenant-providers.tf ./
+ln -s /home/ludomagno/fast-config/tfvars/globals.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/0-bootstrap.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/1-resman.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/2-networking.auto.tfvars.json ./
+ln -s /home/ludomagno/fast-config/tfvars/2-security.auto.tfvars.json ./
+```
+
+```bash
+../../../stage-links.sh gs://xxx-prod-iac-core-outputs-0
+
+# copy and paste the following commands for '3-gke-multitenant'
+
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/providers/3-gke-multitenant-providers.tf ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/globals.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/0-bootstrap.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/1-resman.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/2-networking.auto.tfvars.json ./
+gcloud alpha storage cp gs://xxx-prod-iac-core-outputs-0/tfvars/2-security.auto.tfvars.json ./
+```
+
+### Impersonating the automation service account
+
+The preconfigured provider file uses impersonation to run with this stage's automation service account's credentials. The `gcp-devops` and `organization-admins` groups have the necessary IAM bindings in place to do that, so make sure the current user is a member of one of those groups.
+
+### Variable configuration
+
+Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets:
+
+- variables which refer to global values for the whole organization (org id, billing account id, prefix, etc.), which are pre-populated via the `globals.auto.tfvars.json` file linked or copied above
+- variables which refer to resources managed by previous stage, which are prepopulated here via the `*.auto.tfvars.json` files linked or copied above
+- and finally variables that optionally control this stage's behaviour and customizations, and can to be set in a custom `terraform.tfvars` file
+
+The latter set is explained in the [Customization](#customizations) sections below, and the full list can be found in the [Variables](#variables) table at the bottom of this document.
+
+### Running the stage
+
+Once provider and variable values are in place and the correct user is configured, the stage can be run:
+
+```bash
+terraform init
+terraform apply
+```
+
+### Running in isolation
It's of course possible to run this stage in isolation, by making sure the architectural prerequisites are satisfied (e.g., networking), and that the Service Account running the stage is granted the roles/permissions below:
@@ -62,39 +123,9 @@ It's of course possible to run this stage in isolation, by making sure the archi
The VPC host project, VPC and subnets should already exist.
-### Providers configuration
-
-If you're running this on top of FAST, you should run the following commands to create the providers file, and populate the required variables from the previous stage.
-
-```bash
-# Variable `outputs_location` is set to `~/fast-config` in stage 01-resman
-$ cd fabric-fast/stages/03-gke-multitenant/dev
-ln -s ~/fast-config/providers/03-gke-dev-providers.tf .
-```
-
-### Variable configuration
-
-There are two broad sets of variables you will need to fill in:
-
-- variables shared by other stages (organization id, billing account id, etc.), or derived from a resource managed by a different stage (folder id, automation project id, etc.)
-- variables specific to resources managed by this stage
-
-#### Variables passed in from other stages
+## Customizations
-To avoid the tedious job of filling in the first group of variables with values derived from other stages' outputs, the same mechanism used above for the provider configuration can be used to leverage pre-configured `.tfvars` files.
-
-If you configured a valid path for `outputs_location` in the bootstrap and networking stage, simply link the relevant `terraform-*.auto.tfvars.json` files from this stage's outputs folder (under the path you specified), where the `*` above is set to the name of the stage that produced it. For this stage, a single `.tfvars` file is available:
-
-```bash
-# Variable `outputs_location` is set to `~/fast-config`
-ln -s ~/fast-config/tfvars/00-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/01-resman.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/02-networking.auto.tfvars.json .
-```
-
-If you're not using FAST, refer to the [Variables](#variables) table at the bottom of this document for a full list of variables, their origin (e.g., a stage or specific to this one), and descriptions explaining their meaning.
-
-#### Cluster and node pools
+### Cluster and node pools
This stage is designed with multi-tenancy in mind, and the expectation is that GKE clusters will mostly share a common set of defaults. Variables are designed to support this approach for both clusters and node pools:
@@ -105,7 +136,7 @@ This stage is designed with multi-tenancy in mind, and the expectation is that
There are two additional variables that influence cluster configuration: `authenticator_security_group` to configure [Google Groups for RBAC](https://cloud.google.com/kubernetes-engine/docs/how-to/google-groups-rbac), `dns_domain` to configure [Cloud DNS for GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/cloud-dns).
-#### Fleet management
+### Fleet management
Fleet management is entirely optional, and uses three separate variables:
@@ -116,15 +147,6 @@ Fleet management is entirely optional, and uses three separate variables:
Leave all these variables unset (or set to `null`) to disable fleet management.
-## Running Terraform
-
-Once the [provider](#providers-configuration) and [variable](#variable-configuration) configuration is complete, you can apply this stage:
-
-```bash
-terraform init
-terraform apply
-```
-
diff --git a/fast/stages/CLEANUP.md b/fast/stages/CLEANUP.md
index 3bc581f92a..4b2667c838 100644
--- a/fast/stages/CLEANUP.md
+++ b/fast/stages/CLEANUP.md
@@ -7,7 +7,7 @@ Destruction must be done in reverse order, from stage 3 to stage 0
## Stage 3 (Project Factory)
```bash
-cd $FAST_PWD/03-project-factory/prod/
+cd $FAST_PWD/3-project-factory/dev/
terraform destroy
```
@@ -16,7 +16,7 @@ terraform destroy
Terraform refuses to delete non-empty GCS buckets and BigQuery datasets, so they need to be removed manually from the state.
```bash
-cd $FAST_PWD/03-project-factory/prod/
+cd $FAST_PWD/3-gke-multitenant/dev/
# remove BQ dataset manually
for x in $(terraform state list | grep google_bigquery_dataset); do
@@ -29,14 +29,14 @@ terraform destroy
## Stage 2 (Security)
```bash
-cd $FAST_PWD/02-security/
+cd $FAST_PWD/2-security/
terraform destroy
```
## Stage 2 (Networking)
```bash
-cd $FAST_PWD/02-networking-XXX/
+cd $FAST_PWD/2-networking-XXX/
terraform destroy
```
@@ -47,7 +47,7 @@ A minor glitch can surface running `terraform destroy`, where the service projec
Stage 1 is a little more complicated because of the GCS buckets containing your terraform statefiles. By default, Terraform refuses to delete non-empty buckets, which is good to protect your terraform state, but it makes destruction a bit harder. Use the commands below to remove the GCS buckets from the state and then execute `terraform destroy`
```bash
-cd $FAST_PWD/01-resman/
+cd $FAST_PWD/1-resman/
# remove buckets from state since terraform refuses to delete them
for x in $(terraform state list | grep google_storage_bucket.bucket); do
@@ -64,10 +64,10 @@ terraform destroy
Just like before, we manually remove several resources (GCS buckets and BQ datasets). Note that `terrafom destroy` will fail. This is expected; just continue with the rest of the steps.
```bash
-cd $FAST_PWD/00-bootstrap/
+cd $FAST_PWD/0-bootstrap/
# remove provider config to execute without SA impersonation
-rm 00-bootstrap-providers.tf
+rm 0-bootstrap-providers.tf
# migrate to local state
terraform init -migrate-state
diff --git a/fast/stages/COMPANION.md b/fast/stages/COMPANION.md
index d5d7752f2e..96506d0083 100644
--- a/fast/stages/COMPANION.md
+++ b/fast/stages/COMPANION.md
@@ -8,7 +8,7 @@ The detailed explanation of each stage, their configuration, possible modificati
## Prerequisites
-1. FAST uses the recommended groups from the [GCP Enterprise Setup checklist](). Go to [Workspace / Cloud Identity](https://admin.google.com) and ensure all the following groups exist:
+1. FAST uses the recommended groups from the [GCP Enterprise Setup checklist](https://cloud.google.com/docs/enterprise/setup-checklist). Go to [Workspace / Cloud Identity](https://admin.google.com) and ensure all the following groups exist:
- `gcp-billing-admins@`
- `gcp-devops@`
@@ -80,8 +80,8 @@ If you are using a billing account in a different organization, please follow [t
This initial stage will create common projects for IaC, Logging & Billing, and bootstrap IAM policies.
```bash
-# move to the 00-bootstrap directory
-cd $FAST_PWD/00-bootstrap
+# move to the 0-bootstrap directory
+cd $FAST_PWD/0-bootstrap
# copy the template terraform tfvars file and save as `terraform.tfvars`
# then edit to match your environment!
@@ -114,11 +114,12 @@ outputs_location = "~/fast-config"
terraform init
terraform apply -var bootstrap_user=$FAST_BU
-# link the generated provider file
-ln -s ~/fast-config/providers/0-0-bootstrap* .
+# link providers file
+ln -s ~/fast-config/providers/0-bootstrap-providers.tf ./
# re-run init and apply to remove user-level IAM
terraform init -migrate-state
+
# answer 'yes' to terraform's question
terraform apply
```
@@ -132,14 +133,14 @@ This stage performs two important tasks:
```bash
# move to the 01-resman directory
-cd $FAST_PWD/01-resman
+cd $FAST_PWD/1-resman
-# Link providers and variables from previous stages
-ln -s ~/fast-config/providers/1-0-resman-providers.tf .
-ln -s ~/fast-config/tfvars/0-0-bootstrap.auto.tfvars.json .
+# link providers and variables from previous stages
+ln -s ~/fast-config/providers/1-resman-providers.tf .
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json .
ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-# Edit your terraform.tfvars to append Teams configuration (optional)
+# edit your terraform.tfvars to append Teams configuration (optional)
edit terraform.tfvars
```
@@ -178,15 +179,15 @@ In this stage, we will deploy one of the 3 available Hub&Spoke networking topolo
```bash
# move to the 02-networking-XXX directory (where XXX should be one of vpn|peering|nva)
-cd $FAST_PWD/02-networking-XXX
+cd $FAST_PWD/2-networking-XXX
# setup providers and variables from previous stages
-ln -s ~/fast-config/providers/2-0-networking-providers.tf .
-ln -s ~/fast-config/tfvars/0-0-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/1-0-resman.auto.tfvars.json .
+ln -s ~/fast-config/providers/2-networking-providers.tf .
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json .
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json .
ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-# Create terraform.tfvars. output_location variable is required to generate networking stage output file
+# create terraform.tfvars. output_location variable is required to generate networking stage output file
edit terraform.tfvars
```
@@ -212,12 +213,12 @@ This stage sets up security resources (KMS and VPC-SC) and configurations which
cd $FAST_PWD/02-security
# link providers and variables from previous stages
-ln -s ~/fast-config/providers/2-0-security-providers.tf .
-ln -s ~/fast-config/tfvars/0-0-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/1-0-resman.auto.tfvars.json .
+ln -s ~/fast-config/providers/2-security-providers.tf .
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json .
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json .
ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-# Edit terraform.tfvars to include KMS and/or VPC-SC configuration
+# edit terraform.tfvars to include KMS and/or VPC-SC configuration
edit terraform.tfvars
```
@@ -234,19 +235,20 @@ terraform apply
The Project Factory stage builds on top of your foundations to create and set up projects (and related resources) to be used for your workloads. It is organized in folders representing environments (e.g. "dev", "prod"), each implemented by a stand-alone terraform resource factory.
```bash
-# Variable `outputs_location` is set to `~/fast-config`
-cd $FAST_PWD/3-0-project-factory/ENVIRONMENT
-ln -s ~/fast-config/providers/3-0-project-factory-ENVIRONMENT-providers.tf .
+# variable `outputs_location` is set to `~/fast-config`
+cd $FAST_PWD/3-project-factory/ENVIRONMENT
+ln -s ~/fast-config/providers/3-project-factory-ENVIRONMENT-providers.tf .
-ln -s ~/fast-config/tfvars/0-0-bootstrap.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/1-0-resman.auto.tfvars.json .
-ln -s ~/fast-config/tfvars/2-0-networking.auto.tfvars.json .
+ln -s ~/fast-config/tfvars/0-bootstrap.auto.tfvars.json .
+ln -s ~/fast-config/tfvars/1-resman.auto.tfvars.json .
+ln -s ~/fast-config/tfvars/2-networking.auto.tfvars.json .
ln -s ~/fast-config/tfvars/globals.auto.tfvars.json .
-# Define your environment default values (eg for billing alerts and labels)
+# define your environment default values (eg for billing alerts and labels)
edit data/defaults.yaml
-# Create one yaml file per project to be created. Yaml file will include project configuration. Projects will be named after the filename
+# create one YAML file per project to be created with project configuration
+# filenames will be used for project ids
cp data/projects/project.yaml.sample data/projects/YOUR_PROJECT_NAME.yaml
edit data/projects/YOUR_PROJECT_NAME.yaml
diff --git a/fast/stages/FAQ.md b/fast/stages/FAQ.md
index bd9559d481..5245c8a965 100644
--- a/fast/stages/FAQ.md
+++ b/fast/stages/FAQ.md
@@ -1,29 +1,13 @@
-
-## 00-bootstrap
-
-1. How to handle requests where automation, logging and/or billing export projects are not under organization but in different folders.
- - Run bootstrap stage and let automation, logging and/or billing projects be created under organization.
- - Run resource manager stage or any other custom stage which creates the folders where these projects will reside.
- - Once folders are created add folder ids to varibale "project_parent_ids" in bootstrap stage and run bootstrap stage.
- - This step will move the projects from organization to the parent folders specificed.
-
-## cicd
-
-1. Why do we need two seperate ServiceAccounts when configuring cicd pipelines (cicd SA and IaC SA)
- - Having seperate service accounts helps shutdown the pipeline incase of any issues and still keep IaC SA and ability to run terraform plan/apply manually.
- - A pipeline can only generate a token that can get access to an SA. It cannot directly call a provider file to impersonate IaC SA.
- - Having providers file that allows impersonation to IaC SA allows flexibility to run terraform manually or from CICD Pipelines.
- ![CICD SA and IaC SA](IaC_SA.png)
-
-## Authenciation
-
-1. If you are seeing "Permission Issues" when doing terraform apply and the identity with which you are running terraform has correct permissions;
- run below command so that correct auth credentials are picked by ADC when terraform commands are executed
-
- ````bash
- gcloud auth application-default login
- ````
-
-
- Refer to [GCP Authentication](https://cloud.google.com/docs/authentication
- ) and [Terraform Provider](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) for more information
+# FAST Mini FAQ
+
+- **How can the automation, logging and/or billing export projects be placed under specific folders instead of the org?**
+ - Run the bootstrap stage and let automation, logging and/or billing projects be created under the organization.
+ - Add the needed folders to the resource manager stage, or create them outside the stage in the console/gcloud or from a custom Terraform setup.
+ - Once folders have been created go back to the bootstrap stage, and edit your tfvars file by adding their ids to the `project_parent_ids` variable.
+ - Run the bootstrap stage again, the projects will be moved under the desired folders.
+- **Why do we need two separate service accounts when configuring CI/CD pipelines (CI/CD SA and IaC SA)?**
+ - To have the pipeline workflow follow the same impersonation flow ([CI/CD SA impersonates IaC SA](IaC_SA.png)) used when applying Terraform manually (user impersonates IaC SA), which allows the pipeline to consume the same auto-generated provider files.
+ - To allow disabling pipeline credentials in case of issues with a single operation, by removing the ability of the CI/CD SA to impersonate the IaC SA.
+- **How can I fix permission issues when running Terraform apply?**
+ - Make sure your account is part of the organization admin group defined in variables.
+ - Make sure you have configured [application default credentials](https://cloud.google.com/docs/authentication/application-default-credentials), rerun `gcloud auth login --update-adc` to fix them.
From e64e8db20dd041d229983d50ae93f32343c86452 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Wiktor=20Niesiob=C4=99dzki?=
Date: Sat, 11 Feb 2023 12:53:28 +0000
Subject: [PATCH 07/44] Allow additive IAM grants by robots name
Regreatablly member name will be known after apply, hence changes in the
tests
---
modules/project/README.md | 23 +++++++++++++++++++
modules/project/iam.tf | 13 ++++++++++-
.../examples/iam-additive-members.yaml | 3 ---
.../project/examples/iam-additive.yaml | 4 ----
4 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/modules/project/README.md b/modules/project/README.md
index fbc4ab294d..e7a645fe54 100644
--- a/modules/project/README.md
+++ b/modules/project/README.md
@@ -138,6 +138,29 @@ module "project" {
# tftest modules=1 resources=2
```
+### Using shortcodes for Service Identities in additive IAM
+Most Service Identities contains project number in their e-mail address and this prevents additive IAM to work, as these values are not known at moment of execution of `terraform plan` (its not an issue for authoritative IAM). To refer current project Service Identities you may use shortcodes for Service Identities similarly as for `service_identity_iam` when configuring Shared VPC.
+
+```hcl
+module "project" {
+ source = "./fabric/modules/project"
+ name = "project-example"
+
+ services = [
+ "run.googleapis.com",
+ "container.googleapis.com",
+ ]
+
+ iam_additive = {
+ "roles/editor" = ["cloudservices"]
+ "roles/vpcaccess.user" = ["cloudrun"]
+ "roles/container.hostServiceAgentUser" = ["container-engine"]
+ }
+}
+# tftest modules=1 resources=6
+```
+
+
### Service identities requiring manual IAM grants
The module will create service identities at project creation instead of creating of them at the time of first use. This allows granting these service identities roles in other projects, something which is usually necessary in a Shared VPC context.
diff --git a/modules/project/iam.tf b/modules/project/iam.tf
index 69925cc767..3ed2d2a6fd 100644
--- a/modules/project/iam.tf
+++ b/modules/project/iam.tf
@@ -47,7 +47,18 @@ locals {
}
iam_additive = {
for pair in concat(local._iam_additive_pairs, local._iam_additive_member_pairs) :
- "${pair.role}-${pair.member}" => pair
+ "${pair.role}-${pair.member}" => {
+ role = pair.role
+ member = (
+ pair.member == "cloudservices"
+ ? "serviceAccount:${local.service_account_cloud_services}"
+ : pair.member == "default-compute"
+ ? "serviceAccount:${local.service_accounts_default.compute}"
+ : pair.member == "default-gae"
+ ? "serviceAccount:${local.service_accounts_default.gae}"
+ : try("serviceAccount:${local.service_accounts_robots[pair.member]}", pair.member)
+ )
+ }
}
}
diff --git a/tests/modules/project/examples/iam-additive-members.yaml b/tests/modules/project/examples/iam-additive-members.yaml
index 5832e4dcaa..6a517a4a1d 100644
--- a/tests/modules/project/examples/iam-additive-members.yaml
+++ b/tests/modules/project/examples/iam-additive-members.yaml
@@ -17,17 +17,14 @@ values:
project_id: project-example
module.project.google_project_iam_member.additive["roles/editor-user:two@example.org"]:
condition: []
- member: user:two@example.org
project: project-example
role: roles/editor
module.project.google_project_iam_member.additive["roles/owner-user:one@example.org"]:
condition: []
- member: user:one@example.org
project: project-example
role: roles/owner
module.project.google_project_iam_member.additive["roles/owner-user:two@example.org"]:
condition: []
- member: user:two@example.org
project: project-example
role: roles/owner
diff --git a/tests/modules/project/examples/iam-additive.yaml b/tests/modules/project/examples/iam-additive.yaml
index f07b0df66e..5bab822321 100644
--- a/tests/modules/project/examples/iam-additive.yaml
+++ b/tests/modules/project/examples/iam-additive.yaml
@@ -16,22 +16,18 @@ values:
module.project.google_project.project[0]: {}
module.project.google_project_iam_member.additive["roles/owner-group:three@example.org"]:
condition: []
- member: group:three@example.org
project: project-example
role: roles/owner
module.project.google_project_iam_member.additive["roles/storage.objectAdmin-group:two@example.org"]:
condition: []
- member: group:two@example.org
project: project-example
role: roles/storage.objectAdmin
module.project.google_project_iam_member.additive["roles/viewer-group:one@example.org"]:
condition: []
- member: group:one@example.org
project: project-example
role: roles/viewer
module.project.google_project_iam_member.additive["roles/viewer-group:two@xample.org"]:
condition: []
- member: group:two@xample.org
project: project-example
role: roles/viewer
From a853dc4fe207db2d26f57a37570c0ec01df7d8f2 Mon Sep 17 00:00:00 2001
From: Ayman Farhat
Date: Thu, 16 Feb 2023 15:45:20 +0100
Subject: [PATCH 08/44] update Data Platform blueprint README with more example
Dataflow commands
---
.../demo/dataflow-csv2bq/README.md | 65 ++++++++++++++++++-
1 file changed, 62 insertions(+), 3 deletions(-)
diff --git a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
index 44f178fa26..14b342134d 100644
--- a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
+++ b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
@@ -3,7 +3,66 @@ This demo serves as a simple example of building and launching a Flex Template D
![Dataflow pipeline overview](../../images/df_demo_pipeline.png "Dataflow pipeline overview")
-## Example build run
+
+## Local development run
+
+For local development, the pipeline can be launched from the local machine for testing purposes using different runners depending on the scope of the test.
+
+### Using the Beam DirectRunner
+The below example uses the Beam DirectRunner. The use case for this runner is mainly for quick local run tests on low volume of data.
+
+```
+CSV_FILE=gs://[TEST-BUCKET]/customers.csv
+JSON_SCHEMA=gs://[TEST-BUCKET]/customers_schema.json
+OUTPUT_TABLE=[TEST-PROJ].[TEST-DATASET].customers
+PIPELINE_STAGIN_PATH="gs://[TEST-STAGING-BUCKET]"
+
+python src/csv2bq.py \
+--runner="DirectRunner" \
+--csv_file=$CSV_FILE \
+--json_schema=$JSON_SCHEMA \
+--output_table=$OUTPUT_TABLE \
+--temp_location=$PIPELINE_STAGIN_PATH/tmp
+```
+
+*Note:* All paths mentioned can be local paths or on GCS. For cloud resources referenced (GCS and BigQuery), make sure that the user launching the command is authenticated to GCP via `gcloud auth application-default login` and has the required access privileges to those resources.
+
+### Using the DataflowRunner with a local CLI launch
+
+The below example uses the DataflowRunner locally. The use case for this is for running local tests on larger volumes of test data and verifying that the pipeline runs well on Dataflow, before compiling it into a template.
+
+```
+PROJECT_ID=[TEST-PROJECT]
+REGION=[REGION]
+SUBNET=[SUBNET-NAME]
+DEV_SERVICE_ACCOUNT=[DEV-SA]
+
+PIPELINE_STAGIN_PATH="gs://[TEST-STAGING-BUCKET]"
+CSV_FILE=gs://[TEST-BUCKET]/customers.csv
+JSON_SCHEMA=gs://[TEST-BUCKET]/customers_schema.json
+OUTPUT_TABLE=[TEST-PROJ].[TEST-DATASET].customers
+
+python src/csv2bq.py \
+--runner="Dataflow" \
+--project=$PROJECT_ID \
+--region=$REGION \
+--csv_file=$CSV_FILE \
+--json_schema=$JSON_SCHEMA \
+--output_table=$OUTPUT_TABLE \
+--temp_location=$PIPELINE_STAGIN_PATH/tmp
+--staging_location=$PIPELINE_STAGIN_PATH/stage \
+--subnetwork="regions/$REGION/subnetworks/$SUBNET" \
+--impersonate_service_account=$DEV_SERVICE_ACCOUNT \
+--no_use_public_ips
+```
+
+In terms of resource access priveleges, you can choose to impersonate another service account, which could be defined for development resource access. The authenticated user launching this pipeline will need to have the role `roles/iam.serviceAccountTokenCreator`. If you choose to launch the pipeline without service account impersonation, it will use the default compute service account assigned of the target project.
+
+## Dataflow Flex Template run
+
+For production, and as outline in the Data Platform demo, we build and launch the pipeline as a Flex Template, making it available for other cloud services(such as Apache Airflow) and users to trigger launch instances of it on demand.
+
+### Build launch
Below is an example for triggering the Dataflow flex template build pipeline defined in `cloudbuild.yaml`. The Terraform output provides an example as well filled with the parameters values based on the generated resources in the data platform.
@@ -28,9 +87,9 @@ gcloud builds submit \
**Note:** For the scope of the demo, the launch of this build is manual, but in production, this build would be launched via a configured cloud build trigger when new changes are merged into the code branch of the Dataflow template.
-## Example Dataflow pipeline launch in bash (from flex template)
+### Dataflow Flex Template run
-Below is an example of launching a dataflow pipeline manually, based on the built template. When launched manually, the Dataflow pipeline would be launched via the orchestration service account, which is what the Airflow DAG is also using in the scope of this demo.
+After the build step succeeds. You can launch dataflow pipeline from CLI (outline in this example) or the API via Airflow's operator. For the use case of the data platform, the Dataflow pipeline would be launched via the orchestration service account, which is what the Airflow DAG is also using in the scope of this demo.
**Note:** In the data platform demo, the launch of this Dataflow pipeline is handled by the airflow operator (DataflowStartFlexTemplateOperator).
From fcdadf521d54e201c26f829b2376cffaa5c8584d Mon Sep 17 00:00:00 2001
From: Ayman Farhat
Date: Thu, 16 Feb 2023 15:48:12 +0100
Subject: [PATCH 09/44] Fix spelling mistake
---
.../data-platform-foundations/demo/dataflow-csv2bq/README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
index 14b342134d..ece7efbb29 100644
--- a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
+++ b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
@@ -56,7 +56,7 @@ python src/csv2bq.py \
--no_use_public_ips
```
-In terms of resource access priveleges, you can choose to impersonate another service account, which could be defined for development resource access. The authenticated user launching this pipeline will need to have the role `roles/iam.serviceAccountTokenCreator`. If you choose to launch the pipeline without service account impersonation, it will use the default compute service account assigned of the target project.
+In terms of resource access privilege, you can choose to impersonate another service account, which could be defined for development resource access. The authenticated user launching this pipeline will need to have the role `roles/iam.serviceAccountTokenCreator`. If you choose to launch the pipeline without service account impersonation, it will use the default compute service account assigned of the target project.
## Dataflow Flex Template run
From eac2065ae2a06838aac02b0ce89661ce78dcd472 Mon Sep 17 00:00:00 2001
From: Ayman Farhat
Date: Thu, 16 Feb 2023 17:04:05 +0100
Subject: [PATCH 10/44] Update on docs wording
---
.../data-platform-foundations/demo/dataflow-csv2bq/README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
index ece7efbb29..b052fab058 100644
--- a/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
+++ b/blueprints/data-solutions/data-platform-foundations/demo/dataflow-csv2bq/README.md
@@ -9,7 +9,7 @@ This demo serves as a simple example of building and launching a Flex Template D
For local development, the pipeline can be launched from the local machine for testing purposes using different runners depending on the scope of the test.
### Using the Beam DirectRunner
-The below example uses the Beam DirectRunner. The use case for this runner is mainly for quick local run tests on low volume of data.
+The below example uses the Beam DirectRunner. The use case for this runner is mainly for quick local tests on the development environment with low volume of data.
```
CSV_FILE=gs://[TEST-BUCKET]/customers.csv
@@ -29,7 +29,7 @@ python src/csv2bq.py \
### Using the DataflowRunner with a local CLI launch
-The below example uses the DataflowRunner locally. The use case for this is for running local tests on larger volumes of test data and verifying that the pipeline runs well on Dataflow, before compiling it into a template.
+The below example triggers the pipeline on Dataflow from your local development environment. The use case for this is for running local tests on larger volumes of test data and verifying that the pipeline runs well on Dataflow, before compiling it into a template.
```
PROJECT_ID=[TEST-PROJECT]
From a497aef707ee6d044f1aebca1af65728c9de141b Mon Sep 17 00:00:00 2001
From: Aleksandr Averbukh
Date: Sat, 18 Feb 2023 21:36:51 +0100
Subject: [PATCH 11/44] feat: new version of projects-data-source based on
AssetInventory ds
---
modules/projects-data-source/README.md | 60 ++++++---
modules/projects-data-source/main.tf | 146 ++++------------------
modules/projects-data-source/outputs.tf | 13 +-
modules/projects-data-source/variables.tf | 52 ++++++--
modules/projects-data-source/versions.tf | 2 +-
5 files changed, 118 insertions(+), 155 deletions(-)
diff --git a/modules/projects-data-source/README.md b/modules/projects-data-source/README.md
index 6fd7dd8abf..d447692315 100644
--- a/modules/projects-data-source/README.md
+++ b/modules/projects-data-source/README.md
@@ -1,9 +1,14 @@
# Projects Data Source Module
-This module extends functionality of [google_projects](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/projects) data source by retrieving all the projects and folders under a specific `parent` recursively.
+This module extends functionality of [google_projects](https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/projects) data source by retrieving all the projects under a specific `parent` recursively with only one API call against [Cloud Asset Inventory](https://cloud.google.com/asset-inventory) service.
A good usage pattern would be when we want all the projects under a specific folder (including nested subfolders) to be included into [VPC Service Controls](../vpc-sc/). Instead of manually maintaining the list of project numbers as an input to the `vpc-sc` module we can use that module to retrieve all the project numbers dynamically.
+### IAM Permissions required
+
+- `roles/cloudasset.viewer` on the `parent` level or above
+
+
## Examples
### All projects in my org
@@ -15,11 +20,7 @@ module "my-org" {
}
output "projects" {
- value = module.my-org.projects
-}
-
-output "folders" {
- value = module.my-org.folders
+ value = module.my-org.projects_numbers
}
# tftest skip (uses data sources)
@@ -31,34 +32,65 @@ output "folders" {
module "my-dev" {
source = "./fabric/modules/projects-data-source"
parent = "folders/123456789"
- filter = "labels.env:DEV lifecycleState:ACTIVE"
+ query = "labels.env:DEV state:ACTIVE"
}
output "dev-projects" {
value = module.my-dev.projects
}
-output "dev-folders" {
- value = module.my-dev.folders
+# tftest skip (uses data sources)
+```
+
+### Projects under org with folder/project exclusions
+```hcl
+module "my-filtered" {
+ source = "./fabric/modules/projects-data-source"
+ parent = "organizations/123456789"
+ ignore_projects = [
+ "sandbox-*", # wildcard ignore
+ "project-full-id", # specific project id
+ "0123456789" # specific project number
+ ]
+
+ include_projects = [
+ "sandbox-114", # include specific project which was excluded by wildcard
+ "415216609246" # include specific project which was excluded by wildcard (by project number)
+ ]
+
+ ignore_folders = [ # subfolders are ingoner as well
+ "343991594985",
+ "437102807785",
+ "345245235245"
+ ]
+ query = "state:ACTIVE"
+}
+
+output "filtered-projects" {
+ value = module.my-filtered.projects
}
# tftest skip (uses data sources)
+
```
+
## Variables
| name | description | type | required | default |
|---|---|:---:|:---:|:---:|
-| [parent](variables.tf#L23) | Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format. | string
| ✓ | |
-| [filter](variables.tf#L17) | A string filter as defined in the [REST API](https://cloud.google.com/resource-manager/reference/rest/v1/projects/list#query-parameters). | string
| | "lifecycleState:ACTIVE"
|
+| [parent](variables.tf#L17) | Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format. | string
| ✓ | |
+| [ignore_folders](variables.tf#L58) | A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable. | list(string)
| | []
|
+| [ignore_projects](variables.tf#L32) | A list of project IDs, numbers or prefixes to exclude matching projects from the module output. | list(string)
| | []
|
+| [include_projects](variables.tf#L44) | A list of project IDs/numbers to include to the output if some of them are excluded by `ignore_projects` wilcard entries. | list(string)
| | []
|
+| [query](variables.tf#L26) | A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax). | string
| | "state:ACTIVE"
|
## Outputs
| name | description | sensitive |
|---|---|:---:|
-| [folders](outputs.tf#L17) | Map of folders attributes keyed by folder id. | |
-| [project_numbers](outputs.tf#L22) | List of project numbers. | |
-| [projects](outputs.tf#L27) | Map of projects attributes keyed by projects id. | |
+| [project_numbers](outputs.tf#L17) | List of project numbers. | |
+| [projects](outputs.tf#L22) | List of projects in [StandardResourceMetadata](https://cloud.google.com/asset-inventory/docs/reference/rest/v1p1beta1/resources/searchAll#StandardResourceMetadata) format. | |
diff --git a/modules/projects-data-source/main.tf b/modules/projects-data-source/main.tf
index 76df425e5c..5bb16b9dd0 100644
--- a/modules/projects-data-source/main.tf
+++ b/modules/projects-data-source/main.tf
@@ -1,5 +1,5 @@
/**
- * Copyright 2022 Google LLC
+ * Copyright 2023 Google LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -15,129 +15,27 @@
*/
locals {
- folders_l1_map = { for item in data.google_folders.folders_l1.folders : item.name => item }
-
- folders_l2_map = merge([
- for _, v in data.google_folders.folders_l2 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l3_map = merge([
- for _, v in data.google_folders.folders_l3 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l4_map = merge([
- for _, v in data.google_folders.folders_l4 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l5_map = merge([
- for _, v in data.google_folders.folders_l5 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l6_map = merge([
- for _, v in data.google_folders.folders_l6 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l7_map = merge([
- for _, v in data.google_folders.folders_l7 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l8_map = merge([
- for _, v in data.google_folders.folders_l8 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l9_map = merge([
- for _, v in data.google_folders.folders_l9 :
- { for item in v.folders : item.name => item }
- ]...)
-
- folders_l10_map = merge([
- for _, v in data.google_folders.folders_l10 :
- { for item in v.folders : item.name => item }
- ]...)
-
- all_folders = merge(
- local.folders_l1_map,
- local.folders_l2_map,
- local.folders_l3_map,
- local.folders_l4_map,
- local.folders_l5_map,
- local.folders_l6_map,
- local.folders_l7_map,
- local.folders_l8_map,
- local.folders_l9_map,
- local.folders_l10_map
+ _ignore_folder_numbers = [for folder_id in var.ignore_folders: trimprefix(folder_id, "folders/")]
+ _ignore_folders_query = join(" AND NOT folders:", concat([""], local._ignore_folder_numbers))
+ query = var.query != "" ? (
+ format("%s%s", var.query, local._ignore_folders_query)
+ ) : (
+ format("%s%s", var.query, trimprefix(local._ignore_folders_query, " AND "))
)
- parent_ids = toset(concat(
- [split("/", var.parent)[1]],
- [for k, _ in local.all_folders : split("/", k)[1]]
- ))
-
- projects = merge([
- for _, v in data.google_projects.projects :
- { for item in v.projects : item.project_id => item }
- ]...)
-}
-
-# 10 datasources are used to cover 10 possible nested layers in GCP organization hirerarcy.
-data "google_folders" "folders_l1" {
- parent_id = var.parent
-}
-
-data "google_folders" "folders_l2" {
- for_each = local.folders_l1_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l3" {
- for_each = local.folders_l2_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l4" {
- for_each = local.folders_l3_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l5" {
- for_each = local.folders_l4_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l6" {
- for_each = local.folders_l5_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l7" {
- for_each = local.folders_l6_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l8" {
- for_each = local.folders_l7_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l9" {
- for_each = local.folders_l8_map
- parent_id = each.value.name
-}
-
-data "google_folders" "folders_l10" {
- for_each = local.folders_l9_map
- parent_id = each.value.name
-}
-
-# Getting all projects parented by any of the folders in the tree including root prg/folder provided by `parent` variable.
-data "google_projects" "projects" {
- for_each = local.parent_ids
- filter = "parent.id:${each.value} ${var.filter}"
+ ignore_patterns = [for item in var.ignore_projects: "^${replace(item, "*", ".*")}$"]
+ ignore_regexp = length(local.ignore_patterns) > 0 ? join("|", local.ignore_patterns) : "^NO_PROJECTS_TO_IGNORE$"
+ projects_after_ignore = [ for item in data.google_cloud_asset_resources_search_all.projects.results : item if (
+ length(concat(try(regexall(local.ignore_regexp, trimprefix(item.project, "projects/")), []), try(regexall(local.ignore_regexp, trimprefix(item.name, "//cloudresourcemanager.googleapis.com/projects/")), []))) == 0
+ ) || contains(var.include_projects, trimprefix(item.name, "//cloudresourcemanager.googleapis.com/projects/")) || contains(var.include_projects, trimprefix(item.project, "projects/"))
+ ]
+}
+
+data google_cloud_asset_resources_search_all projects {
+ provider = google-beta
+ scope = var.parent
+ asset_types = [
+ "cloudresourcemanager.googleapis.com/Project"
+ ]
+ query = local.query
}
diff --git a/modules/projects-data-source/outputs.tf b/modules/projects-data-source/outputs.tf
index b7e38ae2cf..b1710fa20b 100644
--- a/modules/projects-data-source/outputs.tf
+++ b/modules/projects-data-source/outputs.tf
@@ -1,5 +1,5 @@
/**
- * Copyright 2022 Google LLC
+ * Copyright 2023 Google LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -14,17 +14,12 @@
* limitations under the License.
*/
-output "folders" {
- description = "Map of folders attributes keyed by folder id."
- value = local.all_folders
-}
-
output "project_numbers" {
description = "List of project numbers."
- value = [for _, v in local.projects : v.number]
+ value = [for item in local.projects_after_ignore : trimprefix(item.project, "projects/")]
}
output "projects" {
- description = "Map of projects attributes keyed by projects id."
- value = local.projects
+ description = "List of projects in [StandardResourceMetadata](https://cloud.google.com/asset-inventory/docs/reference/rest/v1p1beta1/resources/searchAll#StandardResourceMetadata) format."
+ value = local.projects_after_ignore
}
diff --git a/modules/projects-data-source/variables.tf b/modules/projects-data-source/variables.tf
index a7f393d335..3273959ad8 100644
--- a/modules/projects-data-source/variables.tf
+++ b/modules/projects-data-source/variables.tf
@@ -1,5 +1,5 @@
/**
- * Copyright 2022 Google LLC
+ * Copyright 2023 Google LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -14,12 +14,6 @@
* limitations under the License.
*/
-variable "filter" {
- description = "A string filter as defined in the [REST API](https://cloud.google.com/resource-manager/reference/rest/v1/projects/list#query-parameters)."
- type = string
- default = "lifecycleState:ACTIVE"
-}
-
variable "parent" {
description = "Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format."
type = string
@@ -28,3 +22,47 @@ variable "parent" {
error_message = "Parent must be of the form folders/folder_id or organizations/organization_id."
}
}
+
+variable "query" {
+ description = "A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax)."
+ type = string
+ default = "state:ACTIVE"
+}
+
+variable "ignore_projects" {
+ description = "A list of project IDs, numbers or prefixes to exclude matching projects from the module output."
+ type = list(string)
+ default = []
+ # example
+ #ignore_projects = [
+ # "dev-proj-1",
+ # "uat-proj-2",
+ # "0123456789",
+ # "prd-proj-*"
+ #]
+}
+variable "include_projects" {
+ description = "A list of project IDs/numbers to include to the output if some of them are excluded by `ignore_projects` wilcard entries."
+ type = list(string)
+ default = []
+ # example excluding all the projects starting with "prf-" except "prd-123457"
+ #ignore_projects = [
+ # "prd-*"
+ #]
+ #include_projects = [
+ # "prd-123457",
+ # "0123456789"
+ #]
+}
+
+variable "ignore_folders" {
+ description = "A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable."
+ type = list(string)
+ default = []
+ # example exlusing a folder
+ # ignore_folders = [
+ # "folders/0123456789",
+ # "2345678901"
+ # ]
+}
+
diff --git a/modules/projects-data-source/versions.tf b/modules/projects-data-source/versions.tf
index 286536a65e..23f38edbce 100644
--- a/modules/projects-data-source/versions.tf
+++ b/modules/projects-data-source/versions.tf
@@ -1,4 +1,4 @@
-# Copyright 2022 Google LLC
+# Copyright 2023 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
From 1c302c7ab331afbe32b78655aea4a1b02d6e4efb Mon Sep 17 00:00:00 2001
From: Aleksandr Averbukh
Date: Sat, 18 Feb 2023 21:48:05 +0100
Subject: [PATCH 12/44] TF formatting
---
modules/projects-data-source/main.tf | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/modules/projects-data-source/main.tf b/modules/projects-data-source/main.tf
index 5bb16b9dd0..6bd5631ccf 100644
--- a/modules/projects-data-source/main.tf
+++ b/modules/projects-data-source/main.tf
@@ -15,25 +15,25 @@
*/
locals {
- _ignore_folder_numbers = [for folder_id in var.ignore_folders: trimprefix(folder_id, "folders/")]
- _ignore_folders_query = join(" AND NOT folders:", concat([""], local._ignore_folder_numbers))
+ _ignore_folder_numbers = [for folder_id in var.ignore_folders : trimprefix(folder_id, "folders/")]
+ _ignore_folders_query = join(" AND NOT folders:", concat([""], local._ignore_folder_numbers))
query = var.query != "" ? (
format("%s%s", var.query, local._ignore_folders_query)
- ) : (
+ ) : (
format("%s%s", var.query, trimprefix(local._ignore_folders_query, " AND "))
)
- ignore_patterns = [for item in var.ignore_projects: "^${replace(item, "*", ".*")}$"]
+ ignore_patterns = [for item in var.ignore_projects : "^${replace(item, "*", ".*")}$"]
ignore_regexp = length(local.ignore_patterns) > 0 ? join("|", local.ignore_patterns) : "^NO_PROJECTS_TO_IGNORE$"
- projects_after_ignore = [ for item in data.google_cloud_asset_resources_search_all.projects.results : item if (
- length(concat(try(regexall(local.ignore_regexp, trimprefix(item.project, "projects/")), []), try(regexall(local.ignore_regexp, trimprefix(item.name, "//cloudresourcemanager.googleapis.com/projects/")), []))) == 0
+ projects_after_ignore = [for item in data.google_cloud_asset_resources_search_all.projects.results : item if(
+ length(concat(try(regexall(local.ignore_regexp, trimprefix(item.project, "projects/")), []), try(regexall(local.ignore_regexp, trimprefix(item.name, "//cloudresourcemanager.googleapis.com/projects/")), []))) == 0
) || contains(var.include_projects, trimprefix(item.name, "//cloudresourcemanager.googleapis.com/projects/")) || contains(var.include_projects, trimprefix(item.project, "projects/"))
]
}
-data google_cloud_asset_resources_search_all projects {
+data "google_cloud_asset_resources_search_all" "projects" {
provider = google-beta
- scope = var.parent
+ scope = var.parent
asset_types = [
"cloudresourcemanager.googleapis.com/Project"
]
From 8174890331d3204adc770d0cbdf001aad59ba354 Mon Sep 17 00:00:00 2001
From: Aleksandr Averbukh
Date: Sat, 18 Feb 2023 22:04:40 +0100
Subject: [PATCH 13/44] Sort variables
---
modules/projects-data-source/variables.tf | 44 +++++++++++------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/modules/projects-data-source/variables.tf b/modules/projects-data-source/variables.tf
index 3273959ad8..9fef35ab6c 100644
--- a/modules/projects-data-source/variables.tf
+++ b/modules/projects-data-source/variables.tf
@@ -14,19 +14,15 @@
* limitations under the License.
*/
-variable "parent" {
- description = "Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format."
- type = string
- validation {
- condition = can(regex("(organizations|folders)/[0-9]+", var.parent))
- error_message = "Parent must be of the form folders/folder_id or organizations/organization_id."
- }
-}
-
-variable "query" {
- description = "A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax)."
- type = string
- default = "state:ACTIVE"
+variable "ignore_folders" {
+ description = "A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable."
+ type = list(string)
+ default = []
+ # example exlusing a folder
+ # ignore_folders = [
+ # "folders/0123456789",
+ # "2345678901"
+ # ]
}
variable "ignore_projects" {
@@ -41,6 +37,7 @@ variable "ignore_projects" {
# "prd-proj-*"
#]
}
+
variable "include_projects" {
description = "A list of project IDs/numbers to include to the output if some of them are excluded by `ignore_projects` wilcard entries."
type = list(string)
@@ -55,14 +52,17 @@ variable "include_projects" {
#]
}
-variable "ignore_folders" {
- description = "A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable."
- type = list(string)
- default = []
- # example exlusing a folder
- # ignore_folders = [
- # "folders/0123456789",
- # "2345678901"
- # ]
+variable "parent" {
+ description = "Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format."
+ type = string
+ validation {
+ condition = can(regex("(organizations|folders)/[0-9]+", var.parent))
+ error_message = "Parent must be of the form folders/folder_id or organizations/organization_id."
+ }
}
+variable "query" {
+ description = "A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax)."
+ type = string
+ default = "state:ACTIVE"
+}
From ff4b2fffe274d7b58dbc2f75477a03ccbc5b3198 Mon Sep 17 00:00:00 2001
From: Aleksandr Averbukh
Date: Sat, 18 Feb 2023 22:11:44 +0100
Subject: [PATCH 14/44] Regenerate docs
---
modules/projects-data-source/README.md | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/modules/projects-data-source/README.md b/modules/projects-data-source/README.md
index d447692315..8fcfad968f 100644
--- a/modules/projects-data-source/README.md
+++ b/modules/projects-data-source/README.md
@@ -73,18 +73,17 @@ output "filtered-projects" {
# tftest skip (uses data sources)
```
-
## Variables
| name | description | type | required | default |
|---|---|:---:|:---:|:---:|
-| [parent](variables.tf#L17) | Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format. | string
| ✓ | |
-| [ignore_folders](variables.tf#L58) | A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable. | list(string)
| | []
|
-| [ignore_projects](variables.tf#L32) | A list of project IDs, numbers or prefixes to exclude matching projects from the module output. | list(string)
| | []
|
-| [include_projects](variables.tf#L44) | A list of project IDs/numbers to include to the output if some of them are excluded by `ignore_projects` wilcard entries. | list(string)
| | []
|
-| [query](variables.tf#L26) | A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax). | string
| | "state:ACTIVE"
|
+| [parent](variables.tf#L55) | Parent folder or organization in 'folders/folder_id' or 'organizations/org_id' format. | string
| ✓ | |
+| [ignore_folders](variables.tf#L17) | A list of folder IDs or numbers to be excluded from the output, all the subfolders and projects are exluded from the output regardless of the include_projects variable. | list(string)
| | []
|
+| [ignore_projects](variables.tf#L28) | A list of project IDs, numbers or prefixes to exclude matching projects from the module output. | list(string)
| | []
|
+| [include_projects](variables.tf#L41) | A list of project IDs/numbers to include to the output if some of them are excluded by `ignore_projects` wilcard entries. | list(string)
| | []
|
+| [query](variables.tf#L64) | A string query as defined in the [Query Syntax](https://cloud.google.com/asset-inventory/docs/query-syntax). | string
| | "state:ACTIVE"
|
## Outputs
From befc73ec126f46c0544a4491fa6a14b4d2aa3d99 Mon Sep 17 00:00:00 2001
From: Aleksandr Averbukh
Date: Sun, 19 Feb 2023 00:51:49 +0100
Subject: [PATCH 15/44] feat: Update TFC+WIF blueprint with TFC Dynamic
Credentials feature.
---
blueprints/README.md | 2 +-
blueprints/cloud-operations/README.md | 4 +-
.../README.md | 57 ++++++++++--------
.../diagram.png | Bin 0 -> 75704 bytes
.../gcp-workload-identity-provider/README.md | 26 ++++----
.../gcp-workload-identity-provider/main.tf | 32 +++++-----
.../gcp-workload-identity-provider/outputs.tf | 25 +++-----
.../variables.tf | 16 ++---
.../tfc-workflow-using-wif/README.md | 16 +++++
.../backend.tf.template | 6 +-
.../tfc-workflow-using-wif/main.tf | 4 +-
.../tfc-workflow-using-wif/provider.tf} | 12 +---
.../terraform.auto.tfvars.template | 5 +-
.../tfc-workflow-using-wif/variables.tf} | 11 +---
.../terraform-enterprise-wif/diagram.png | Bin 29084 -> 0 bytes
.../terraform.auto.tfvars.template | 20 ------
.../tfc-workflow-using-wif/README.md | 17 ------
.../tfc-workflow-using-wif/provider.tf | 24 --------
.../tfc-workflow-using-wif/tfc-oidc/README.md | 38 ------------
.../tfc-workflow-using-wif/tfc-oidc/main.tf | 23 -------
.../tfc-oidc/outputs.tf | 27 ---------
.../tfc-oidc/variables.tf | 26 --------
.../tfc-oidc/versions.tf | 29 ---------
.../tfc-workflow-using-wif/variables.tf | 24 --------
.../__init__.py | 0
.../__init__.py | 0
.../fixture/main.tf | 8 +--
.../fixture/variables.tf | 16 ++---
.../test_plan.py | 0
29 files changed, 124 insertions(+), 344 deletions(-)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/README.md (50%)
create mode 100644 blueprints/cloud-operations/terraform-cloud-dynamic-credentials/diagram.png
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/gcp-workload-identity-provider/README.md (54%)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/gcp-workload-identity-provider/main.tf (77%)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/gcp-workload-identity-provider/outputs.tf (53%)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/gcp-workload-identity-provider/variables.tf (83%)
create mode 100644 blueprints/cloud-operations/terraform-cloud-dynamic-credentials/tfc-workflow-using-wif/README.md
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/tfc-workflow-using-wif/backend.tf.template (89%)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/tfc-workflow-using-wif/main.tf (91%)
rename blueprints/cloud-operations/{terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/write_token.sh => terraform-cloud-dynamic-credentials/tfc-workflow-using-wif/provider.tf} (74%)
rename blueprints/cloud-operations/{terraform-enterprise-wif => terraform-cloud-dynamic-credentials}/tfc-workflow-using-wif/terraform.auto.tfvars.template (75%)
rename blueprints/cloud-operations/{terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/get_audience.sh => terraform-cloud-dynamic-credentials/tfc-workflow-using-wif/variables.tf} (81%)
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/diagram.png
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/gcp-workload-identity-provider/terraform.auto.tfvars.template
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/README.md
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/provider.tf
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/README.md
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/main.tf
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/outputs.tf
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/variables.tf
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/tfc-oidc/versions.tf
delete mode 100644 blueprints/cloud-operations/terraform-enterprise-wif/tfc-workflow-using-wif/variables.tf
rename tests/blueprints/cloud_operations/{terraform_enterprise_wif => terraform-cloud-dynamic-credentials}/__init__.py (100%)
rename tests/blueprints/cloud_operations/{terraform_enterprise_wif => terraform-cloud-dynamic-credentials}/gcp_workload_identity_provider/__init__.py (100%)
rename tests/blueprints/cloud_operations/{terraform_enterprise_wif => terraform-cloud-dynamic-credentials}/gcp_workload_identity_provider/fixture/main.tf (81%)
rename tests/blueprints/cloud_operations/{terraform_enterprise_wif => terraform-cloud-dynamic-credentials}/gcp_workload_identity_provider/fixture/variables.tf (83%)
rename tests/blueprints/cloud_operations/{terraform_enterprise_wif => terraform-cloud-dynamic-credentials}/gcp_workload_identity_provider/test_plan.py (100%)
diff --git a/blueprints/README.md b/blueprints/README.md
index 60a84912dc..b19b02d30e 100644
--- a/blueprints/README.md
+++ b/blueprints/README.md
@@ -5,7 +5,7 @@ This section provides **[networking blueprints](./networking/)** that implement
Currently available blueprints:
- **apigee** - [Apigee Hybrid on GKE](./apigee/hybrid-gke/), [Apigee X analytics in BigQuery](./apigee/bigquery-analytics), [Apigee network patterns](./apigee/network-patterns/)
-- **cloud operations** - [Active Directory Federation Services](./cloud-operations/adfs), [Cloud Asset Inventory feeds for resource change tracking and remediation](./cloud-operations/asset-inventory-feed-remediation), [Fine-grained Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Cloud DNS & Shared VPC design](./cloud-operations/dns-shared-vpc), [Delegated Role Grants](./cloud-operations/iam-delegated-role-grants), [Networking Dashboard](./cloud-operations/network-dashboard), [Managing on-prem service account keys by uploading public keys](./cloud-operations/onprem-sa-key-management), [Compute Image builder with Hashicorp Packer](./cloud-operations/packer-image-builder), [Packer example](./cloud-operations/packer-image-builder/packer), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Configuring workload identity federation for Terraform Cloud/Enterprise workflow](./cloud-operations/terraform-enterprise-wif), [TCP healthcheck and restart for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck), [Migrate for Compute Engine (v5) blueprints](./cloud-operations/vm-migration), [Configuring workload identity federation to access Google Cloud resources from apps running on Azure](./cloud-operations/workload-identity-federation)
+- **cloud operations** - [Active Directory Federation Services](./cloud-operations/adfs), [Cloud Asset Inventory feeds for resource change tracking and remediation](./cloud-operations/asset-inventory-feed-remediation), [Fine-grained Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Cloud DNS & Shared VPC design](./cloud-operations/dns-shared-vpc), [Delegated Role Grants](./cloud-operations/iam-delegated-role-grants), [Networking Dashboard](./cloud-operations/network-dashboard), [Managing on-prem service account keys by uploading public keys](./cloud-operations/onprem-sa-key-management), [Compute Image builder with Hashicorp Packer](./cloud-operations/packer-image-builder), [Packer example](./cloud-operations/packer-image-builder/packer), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Configuring workload identity federation with Terraform Cloud/Enterprise workflows](./cloud-operations/terraform-cloud-dynamic-credentials), [TCP healthcheck and restart for unmanaged GCE instances](./cloud-operations/unmanaged-instances-healthcheck), [Migrate for Compute Engine (v5) blueprints](./cloud-operations/vm-migration), [Configuring workload identity federation to access Google Cloud resources from apps running on Azure](./cloud-operations/workload-identity-federation)
- **data solutions** - [GCE and GCS CMEK via centralized Cloud KMS](./data-solutions/cmek-via-centralized-kms), [Cloud Composer version 2 private instance, supporting Shared VPC and external CMEK key](./data-solutions/composer-2), [Cloud SQL instance with multi-region read replicas](./data-solutions/cloudsql-multiregion), [Data Platform](./data-solutions/data-platform-foundations), [Spinning up a foundation data pipeline on Google Cloud using Cloud Storage, Dataflow and BigQuery](./data-solutions/gcs-to-bq-with-least-privileges), [#SQL Server Always On Groups blueprint](./data-solutions/sqlserver-alwayson), [Data Playground](./data-solutions/data-playground), [MLOps with Vertex AI](./data-solutions/vertex-mlops), [Shielded Folder](./data-solutions/shielded-folder)
- **factories** - [The why and the how of Resource Factories](./factories), [Google Cloud Identity Group Factory](./factories/cloud-identity-group-factory), [Google Cloud BQ Factory](./factories/bigquery-factory), [Google Cloud VPC Firewall Factory](./factories/net-vpc-firewall-yaml), [Minimal Project Factory](./factories/project-factory)
- **GKE** - [Binary Authorization Pipeline Blueprint](./gke/binauthz), [Storage API](./gke/binauthz/image), [Multi-cluster mesh on GKE (fleet API)](./gke/multi-cluster-mesh-gke-fleet-api), [GKE Multitenant Blueprint](./gke/multitenant-fleet), [Shared VPC with GKE support](./networking/shared-vpc-gke/)
diff --git a/blueprints/cloud-operations/README.md b/blueprints/cloud-operations/README.md
index 863aee5812..99013624e5 100644
--- a/blueprints/cloud-operations/README.md
+++ b/blueprints/cloud-operations/README.md
@@ -64,9 +64,9 @@ This [blueprint](./onprem-sa-key-management) shows how to manage IAM Service Acc
-## Workload identity federation for Terraform Enterprise workflow
+## Workload identity federation with Terraform Cloud workflows
- This [blueprint](./terraform-enterprise-wif) shows how to configure [Wokload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) between [Terraform Cloud/Enterprise](https://developer.hashicorp.com/terraform/enterprise) instance and Google Cloud.
+ This [blueprint](./terraform-cloud-dynamic-credentials) shows how to configure [Wokload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) between [Terraform Cloud/Enterprise](https://developer.hashicorp.com/terraform/enterprise) instance and Google Cloud.
diff --git a/blueprints/cloud-operations/terraform-enterprise-wif/README.md b/blueprints/cloud-operations/terraform-cloud-dynamic-credentials/README.md
similarity index 50%
rename from blueprints/cloud-operations/terraform-enterprise-wif/README.md
rename to blueprints/cloud-operations/terraform-cloud-dynamic-credentials/README.md
index 4bb282c560..3cec722e0f 100644
--- a/blueprints/cloud-operations/terraform-enterprise-wif/README.md
+++ b/blueprints/cloud-operations/terraform-cloud-dynamic-credentials/README.md
@@ -1,10 +1,10 @@
-# Configuring workload identity federation for Terraform Cloud/Enterprise workflow
+# Configuration of workload identity federation for Terraform Cloud/Enterprise workflows
-The most common way to use Terraform Cloud for GCP deployments is to store a GCP Service Account Key as a part of TFE Workflow configuration, as we all know there are security risks due to the fact that keys are long term credentials that could be compromised.
+The most common way to use Terraform Cloud for GCP deployments is to store a GCP Service Account Key as a part of TFC Workflow configuration, as we all know there are security risks due to the fact that keys are long term credentials that could be compromised.
Workload identity federation enables applications running outside of Google Cloud to replace long-lived service account keys with short-lived access tokens. This is achieved by configuring Google Cloud to trust an external identity provider, so applications can use the credentials issued by the external identity provider to impersonate a service account.
-This blueprint shows how to set up [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) between [Terraform Cloud/Enterprise](https://developer.hashicorp.com/terraform/enterprise) instance and Google Cloud. This will be possible by configuring workload identity federation to trust oidc tokens generated for a specific workflow in a Terraform Enterprise organization.
+This blueprint shows how to set up [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation) between [Terraform Cloud/Enterprise](https://developer.hashicorp.com/terraform/enterprise) instance and Google Cloud. This will be possible by configuring workload identity federation and [Terraform Cloud Dynamic Provider Credentials](https://www.hashicorp.com/blog/terraform-cloud-adds-dynamic-provider-credentials-vault-official-cloud-providers).
The following diagram illustrates how the VM will get a short-lived access token and use it to access a resource:
@@ -12,8 +12,8 @@ The following diagram illustrates how the VM will get a short-lived access token
## Running the blueprint
-### Create Terraform Enterprise Workflow
-If you don't have an existing Terraform Enterprise organization you can sign up for a [free trial](https://app.terraform.io/public/signup/account) account.
+### Create Terraform Cloud Workflow
+If you don't have an existing Terraform Cloud organization you can sign up for a [free trial](https://app.terraform.io/public/signup/account) account.
Create a new Workspace for a `CLI-driven workflow` (Identity Federation will work for any workflow type, but for simplicity of the blueprint we use CLI driven workflow).
@@ -21,7 +21,7 @@ Note workspace name and id (id starts with `ws-`), we will use them on a later s
Go to the organization settings and note the org name and id (id starts with `org-`).
-### Deploy GCP Workload Identity Pool Provider for Terraform Enterprise
+### Deploy GCP Workload Identity Pool Provider for Terraform Cloud integration
> **_NOTE:_** This is a preparation part and should be executed on behalf of a user with enough permissions.
@@ -32,7 +32,7 @@ Required permissions when new project is created:
- Workload Identity Admin on the project level
- Project IAM Admin on the project level
-Fill out required variables, use TFE Org and Workspace IDs from the previous steps (IDs are not the names).
+Fill out required variables, use TFC Org and Workspace IDs from the previous steps (IDs are not the names).
```bash
cd gcp-workload-identity-provider
@@ -50,34 +50,41 @@ terraform init
terraform apply
```
-As a result a set of outputs will be provided (your values will be different), note the output since we will use it on the next steps.
+You will receive a set of outputs (your values may be different), note them because we will need them in the next steps.
```
-impersonate_service_account_email = "sa-tfe@fe-test-oidc.iam.gserviceaccount.com"
-project_id = "tfe-test-oidc"
-workload_identity_audience = "//iam.googleapis.com/projects/476538149566/locations/global/workloadIdentityPools/tfe-pool/providers/tfe-provider"
-workload_identity_pool_provider_id = "projects/476538149566/locations/global/workloadIdentityPools/tfe-pool/providers/tfe-provider"
+project_id = "tfc-dynamic-creds-gcp"
+tfc_workspace_wariables = {
+ "TFC_GCP_PROJECT_NUMBER" = "200635100209"
+ "TFC_GCP_PROVIDER_AUTH" = "true"
+ "TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL" = "sa-tfc@tfc-dynamic-creds-gcp.iam.gserviceaccount.com"
+ "TFC_GCP_WORKLOAD_POOL_ID" = "tfc-pool"
+ "TFC_GCP_WORKLOAD_PROVIDER_ID" = "tfc-provider"
+}
```
-### Configure OIDC provider for your TFE Workflow
+### Configure Dynamic Provider Credentials for your TFC Workflow
-To enable OIDC for a TFE workflow it's enough to setup an environment variable `TFC_WORKLOAD_IDENTITY_AUDIENCE`.
+To configure [GCP Dynamic Provider Credentials](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/gcp-configuration) for a TFC workflow, you need to set a set of environment variables:
+- `TFC_GCP_PROVIDER_AUTH`
+- `TFC_GCP_PROJECT_NUMBER`
+- `TFC_GCP_RUN_SERVICE_ACCOUNT_EMAIL`
+- `TFC_GCP_WORKLOAD_POOL_ID`
+- `TFC_GCP_WORKLOAD_PROVIDER_ID`
-Go the the Workflow -> Variables and add a new variable `TFC_WORKLOAD_IDENTITY_AUDIENCE` equal to the value of `workload_identity_audience` output, in our example it's:
+Go to the Workflow -> Variables page and click the + Add variable button. For variable type select ` Environment variable`. The variable names listed above are the names of the variables that you need to set. The values provided in the terraform output in the previous step are the values that you need to provide for each variable.
-```
-TFC_WORKLOAD_IDENTITY_AUDIENCE = "//iam.googleapis.com/projects/476538149566/locations/global/workloadIdentityPools/tfe-pool/providers/tfe-provider"
-```
-
-At that point we setup GCP Identity Federation to trust TFE generated OIDC tokens, so the TFE workflow can use the token to impersonate a GCP Service Account.
+At that point we set up GCP Identity Federation to trust TFC generated OIDC tokens, workflow should be able to use Dynamic Provider Credentials to impersonate a GCP Service Account.
## Testing the blueprint
-In order to test the setup we will deploy a GCS bucket from TFE Workflow using OIDC token for Service Account Impersonation.
+To test the setup, we will deploy a GCS bucket from the TFC Workflow created in the previous step.
+
+This will allow us to verify that the workflow can successfully interact with GCP services using the TFC Dynamic Provider Credentials.
### Configure backend and variables
-First, we need to configure TFE Remote backend for our testing terraform code, use TFE Organization name and workspace name (names are not the same as ids)
+First, we need to configure the TFC Remote backend for our testing Terraform code. Use the TFC Organization name and workspace name (names are not the same as ids).
```
cd ../tfc-workflow-using-wif
@@ -89,7 +96,7 @@ vi backend.tf
```
-Fill out variables based on the output from the preparation steps:
+Fill out `project_id` variable based on the output from the preparation steps:
```
mv terraform.auto.tfvars.template terraform.auto.tfvars
@@ -100,7 +107,7 @@ vi terraform.auto.tfvars
### Authenticate terraform for triggering CLI-driven workflow
-Follow this [documentation](https://learn.hashicorp.com/tutorials/terraform/cloud-login) to login ti terraform cloud from the CLI.
+Follow this [documentation](https://learn.hashicorp.com/tutorials/terraform/cloud-login) to login to terraform cloud from the CLI.
### Trigger the workflow
@@ -110,6 +117,6 @@ terraform init
terraform apply
```
-As a result we have a successfully deployed GCS bucket from Terraform Enterprise workflow using Workload Identity Federation.
+As a result we have a successfully deployed GCS bucket from Terraform Cloud workflow using Workload Identity Federation.
Once done testing, you can clean up resources by running `terraform destroy` first in the `tfc-workflow-using-wif` and then `gcp-workload-identity-provider` folders.
diff --git a/blueprints/cloud-operations/terraform-cloud-dynamic-credentials/diagram.png b/blueprints/cloud-operations/terraform-cloud-dynamic-credentials/diagram.png
new file mode 100644
index 0000000000000000000000000000000000000000..9216226ad1323e94178e51f56d083ffa47e50fa1
GIT binary patch
literal 75704
zcmY&Y|=
z@Ae2PK-^FC9`}FWXi+O3snGtbwOI(P_;uGQ`SlZ+U?Xx8%@;i}&y-{s+W!h96#lP(
z`vg2h90JCn
zN@)atB!{u(gF2nb5TC#-z6y_WOoJ8RavBUi{i^PlI&`io*{q5safkI^
zHFu#4GO0&RSW0j2h42uwr)ZbVasVEd_sV#|<-Lf25Y!I78_t3dO!}!0@r&KX$K3-{
z93OLsn)Hy4redNlcZ)sa8|o6(c~iz3Os{%W&UY+=B#R|d&4F2$5bvqUo1qSq^OR_7*z
zo;q&o%E`nvf)Yafhe%6A`pojr*!DBSUa1kvxE5vVxYB#mZ0g<+o;HgNwzfyt(PJ1+sgbr0Onj)Avg)cL|)xE|1K$RF2FG&q0!m3Qhutu
zYC9{RNqzWgUidQIr>o^G-;9-YYqI)m+M{57NcWg8rU}*@el?u_C0&c@N`Jh>Fean
z5|T3aJM8f>V1hHUvP|~qc2tH)!6V@t;?SQ+tT^cR-BA!xOwQX(KIso^+1UuVR@DkPM8w$W=sxYm+AS`XiYNVyjsqW3d179q@yBVFWmqi`hwu7hZy%~H>1byOb
zeZx9KXe8KQ-}v%oAzmOk2vCS>H<}r7{nf&7sh%6xUUq*ZGTcRpm0@ks-#v17r%suA
z==E5T+Id30us*MUh(c=hm$DwrIhP-os@QHTqMKteu?0u>X6145cXjPjh&G@kTkVy|
z&m;vxA|ljiv9huPc)SNz;+Sv65h5D>1EaoO4Muz?4W$qFi(XiUEkHgBrLW^{-ku6!
zA^5NNhwF^$&Zb(%1?B;Hyhqi&-+TD9vYaXD@Aa0otv4W0%W
zeNG}j?+re`_q4s;jE7bk!}|W#GheF1JLk!vFr=>{C8){zK5i(o;T~Hx9V3PlA68&n
z!+-$a4xn|GSsb8ux$Jr*;PHN%$rrs!u=BmmgoDUvu$ZTKQx_E#l~RX9#9OX+qV%&}
z?R@V2cz>$fHa<7HO`&H(8S=ObLk`t!Fx->q9#6aM+>4>DZ9grk^**q%^TIXu`nb)V
zULJ^~WWoBmf3A9ruqA?rG8EFDI9U{wUhmTkfgL~~oG@U)HQaKaW@B;G#xUBlY5)g!
zEf-mMb**NKc3Qq+gAQCx^+7>HH2AR=_rP@oiw^FENPK)UnksW}>G%2Cvhh&;dF%Hv
z&DirSU+X?d%VD<}r8j(K$NTAB^;#G!05h1rH-JoswA;w#i!nUso}~dH5d>c_-tF`H
zK)?lcveMypsgiS(w9(;a;4p|D6_kx~*y*<=@HAZWdeL!yGk&@C=WK4Af!Ft3lXz>q
z6!G6?v;kZV;8l*pYs=@cPmfD;$MtdD=aF~wI%eAE!YPg;{5*t7SU0X?o7p-SOz`vV
z*6?S)-4z5$6g0XH>kQ!PDFr;|c1$Bro=V6GK~g&8za7wta4>U`CucPlKPoyl1Rho1
zh}5P(Df+hq<_S(@`yJ)5g7MPu@G#K86-M>CRQpg#*m&o$neatPsoi(Qc7CsGN-Sh=
z*bgc#4AlxNLi)_l<`JQNN@U!!`uPGBd0Y{fZAUqb-aD{%OlklWSoTj#Z?H#W3U{qT4_7SvoO8G1-m{J`M~vKR+H>pAx>W
zBWMG7tV6r@zV9vXa3bLk5KAGBOD~|)Y)@qeGVXm64zf}P$a2JeB(7W{@O1!VT3diIxi1KyneE3ddgMQfh)(46jrF8
zg>#w?$K2-JSDC*L*}V-7Vj4s}E8fx8!au95i8!Q@LNmdDwB9nI)_9Z5{i=-vmL^E_dG
zvC?>i==+&{>9zGbvj4KW)ctVC+4GD&?LH(aaDxmr$U!kGragYqo{r+J0$$^60@$@t-IHf<6{!{xZ
zbE)&Cl-}`8Z|-}Grn>{%Wsfe;0k6X!)d_IlzfsCLsG2h3AWDh`iutwXk2zh0pRbA^{fu2F
zBiFM;iS%k#np+?2qP{#T<(w7KX2-2>q{e$LY&$qiGtKB}lNnt7;M$Tvvx3jUn&PP+(t^2ke|C*=$K5h~D
zu0TYPEA@Qt7q0RvYg*|NZyHaw2?g#SKerfr4$e5Y*w~goyB|NEH@15AQ2kz&C@u9p
zo{R0=->o2DJZ;PAj
zczE6;hg5PdC{oi&w5!drS4J@S$4s}n?V!S-qO>yF+LX`Do=z=2%&C}4!^P3GM{7(j
z$?@PM%Zp?$`rx#9eOc~e*5UC7ImrjVMsx-|r>k`MxGA)Br7}sL;TXPysn3!uB(+%s
z<{-CVvaD%?J_za_p|HUl>#UU-!cAk}hO`M*yp8QmJYAGrQ0C<`^%Cr|G8Xq+VsN>0
zibe`2pjFuvfv0mPLaL3L*c+vNDt7|gV|oFt5Ak_Eq{S=pg)&Q7w@DgLr=NwKx}mW<
zcoQ2Phz;*Jr|$G#%UrS~NJQg3M3k0JE?k&93)L>Y8!Lqx%+
zZN|5L#ynOZ;F{P&w+Iy?mqG^!jbrnBCROK?<)g<#PeZIA6h-74!8+vj)sS_E8gpNE
z-Y(YYjrXyLD8TA-?}pYTg(4Dm?-A?0lv1(BLyv`5*?skmTs{JK$$M@3}4-O%O|LaJYs42LUT=XrUgBpthV2=-jR%SYeZHFvUU*?{2S_mSMA
z%jIvgeFY<;+$DGMk_3j0V&te>fs3G!B)O5_u5uV{R~p2}Xi*EnNQKi3FI#(;(Z*Nk
zlmx6LjS}-&mIXn}u=%Vl0A^rWMsL!m7`(yl4$cV^gI*XY!(ik__y}2oE2OnqW#5(W
zQn4?YpWSkbdE?0i5kB!agYQsqVgK<`rxdIPDa^aA_csx?b|D0l#fwM`XB`SKZcW_5
z_u5L3n{1t?ZFjmmBYiDB>?E_m5txF8TJF>PV>Lhg}-CI8=Ldv#7
ziHJkHNeTWXBjTJu~5FqC&U4h$k
z!eKWkPRpvUZp;Lmbo}L>9PpcelZ+)86i7ePn+Jn!(IsLJJ!6kT6;EV-X3r@owgbxo
zyN#{ydA%Tfy9yNydgpsxnGSh>JC5d5kXJDBVxoydtb*bQVQ+gywR)@le5oBE1s?JI
z%b*2;b!x{X_c9)v*L9>GLW((;pamz$wG_%%EXuQ~AO?8xuq2%8@FEqm)39}VX^o0$&_4wpuIxljDU$+fZ}m3w
zc8NB<&vdp#jQl6x-nTyaYq{#Kg8N*M>LsRhAmRI?2kW3kDUQ>C?n3BJpV^3tXsIFe
zVMM84h~yQL@Ys^Rm(8g^qNI!eniyzOfQ}fp6sl#&Ev%p>67Ht-K!lUCfyYuI;-=5%-+F*QFLsg4
zLY=xb-@4c3-PJ>Q_L6>Pn{(sRJm%jrqZOejYyu{QUS(s7>`5}8NitB1lN+;jX~TK0
zOp4*glXbk!#;d1b5otU%6dq%fBHbYl?)*$0wUo>-k}XWkB9mKauap`m5%r)cneeOT
zUrk)u5}*&kB7dytvg^qtzd)7G)t1E>#+1Z(fVy~D3+Jz4fzlxnk}2@IEzPt1`1p`n
zk5jM53(5h=@zin5po3+s$zS6sleIqotm;iZf!M|D>@|E<7~NPzC+2*sCzg-80=9vg
zEsgMP8**RyebC@-&|Khl1(kBBE~vR3Q6M!PH=_5x4
z{rkVA0_fv38+~F~QfN@-T8s2mkS<2SHZ~I@zT4V2|3v*8#2$!1*q;H?UXyh^?5rMa
zUh~6`|JvWTMcvfR5c0R(pYwK)DE9i^S=%Hj-T-QhddK)!r;lE&HCti$s1)l}OQbq~
z66X7Gr|)lqLB~rYSyl71@;JUZ!^9Y!>SM?WHIR#Df6#G*-KzhFTg&!L3``KDq>vL$
z79pO72nuEbOs2znbA!#j1&xnMrPXv&FDr%TP{J!)<4+wHOxXzJqE<@c@5+c%uxf*szAbPJn!v2#a*!|<%-Y`>RM
zzn2!qk5DT-ufNVxG)J}1-^sRsK&Vqjc0n~hB#
z=L@}AJhDD`xGRBUsn`8*qk&fhkail?=?V+@J$$YvkD?uJ@V+nj;GIkB&J}h{Sh^ZA
zh%q67g_H6N6TzV+jrT-<_8Ou&`K*S6F%e6$mAja+F}>tyjJG3`P*$;UK1>2O+&&pj
zLB$?KNWbfO+^a1a_`Tb2;gpizaC#(i@$>SIX3nq0WJ=!=Kf{a>vVvbLLP7Q;_T$B@
zhhIB9kPoI8&2U^|I*#6rU|dfY5_-}kCRm5FPO>F_iQG<XJ$F|BH2w6w$Df-oT2&^7fE
zoyoy>k8)IT#08eh5dlDyhkt+dBdC5T8ZxJujpAinJg#JeO~3hjHyeF{;KY7%jf0aQ
zj0cbTzFio)%|A&+c6=HT$q<0L)o~^eu*+S^f70nBgC}R6qmHkCnFju7HG9+t&$(_t>9S-DBJk9QxalyAKO7T%Q*L6*
zJH)P@0IADNMs}RGN_P+8=4c(o*03Ejts!T1E5XGyWB#g>9+F2&3K)*fWkT$mee>v7
zE{nUC0_6)dwBjP2YwP^$kaD3dX$^tB2x~QV%YPnvz-MUetBGCGzj~~htu$mEcWq3n
zh!+_B9ZO2!KnG6kl&XPL3T{OJ1%btu8bRl{p!;Ms60aRNN^s#-)hQq#JfB-NaK
z)wktweao?LQB?q|j@y3NR*bBNUh&saR5gI~#n~Bg#^#hnK#Xw>@_dNaF!*l?C;eCg
z{+RKq($IY;$Z0xMA!j;h^LHKsMYf4rxhasa``
z<1<9Rn7d_DL?g)o<70{6LztO`uha!^u^j)b?HWhwrKPooNkbFi#EAi0ac&A<0Nj7)
z!f$_sSu0xSGp+pmC~Z+=Fx}%ZawSgE#NvtkQj3e3AD}Om84qPu70LETDx#k}c#lbH
zBSv-r_gbI4LAYO)=XL~Kd6jDxS6x2xJ};fbcPwe=T5bn)xLw=FDbHo8s6r##eXbne
zu_D&}`a|TfuF)m(a>v94rx-Q53z2(||9bmpBU7homqB==+or6LqFsGX+u28fpS+@h
znU8?tK|jR-jFUpGi7fK>X*$pQN&}yFm!-yz`cY_x-4yvuFHcWg!$8mwE(!6qj+2s1
zL-YYXW+xz145@>Uk6-wd7>7%iet#xu8Dg`99MS5{WZlLP7)YTXT0SypY9Pnaw)@1{
zV!fI6%P}e6^Jyn^HtTpYfQo8%xbsMb3XLozU*GHBJpf>}eazJ#L_ga}o($u9xfwh5
zs}i@UoO&=efQu=OKLS}!JE33f)v!_SgRIFz!MFR1@VeB}-`3KP;{OXN8_1q8P!3Qz5qMJ8+$<=LhF*b)FnSm_
zf2n5Hzd2jDklFJAP<9_h*Lc)TWB!omwqVbs5tlRu@OdcwH*x|JVbbTxNx{79@zvX8AlD`Y6~dwLIZW>MZQJ$G
zQKD$Kkb@vIABW+XJNAIpQ2+8Rc}$uTGY7{wYIBl=oYC)~$EFVOi5}P$DBL7>o4=$x
z{L*+sS!ST69I6KV(`OV}D{%ylZE}H-%4__T2QM*rMC9KihfB;5yrxX-{8%^dbeHJa
zE%(y3TT9GKTP{Q>H;$4b0(~j4Wc2(Fn%^ns5D95wrsViL&CS-Paw@DU(2*8JgE%T;
zui-dOg9-{`>_O8B9=BQ|aaLk4*2d9;V&LErSed&&-!JDe{#D!g&|*H~ZaqP0?{#e6
z$0+*VBo5&8eB9TD%87<|1FxBQUD3EbKvF#+&5Y
zeM=DK#aMxCEP`QYf_q~A)~2#FlDELi)jEUueAL-cDWY{F!5dORkw&PSF7Z-}#fsYt
z4QI@2A#$;S2f{FNa7oP=Z~<9=J?ZE8J3K={*dM4`TBoNnt(B@s7tTLjWCThr`6>aw
zuH+Q|052*^sC($sm{g8Y69V~a87bmP89T*w-XvOhy?6wgmBS>J{G=TU%C41i
z^Rq!qR?GuW6;3`U*#}?q2ASgVx2Nm$^l*4XLX99#sKYxMbUTK2Rj>BDIawv2FjBJw
zIQSZWDxykz;%zovBln@zKccROs?zkpu)(E@9W(@B!rv10@8B4?q`_@dDKoCaAWTbM
z**9AX_i!deXUt82c9?ERcOB?BF&m2xS*5Ha7_nv*HMeb)N@pb%XJBASI>Q2;q0~s?
zNN&(`CWs9$ed1r|auG3MaP`D?XgnN4(I|T9k=#@s+AnjDd8J_1K`w(_92Rujiw>*)
z1Ua@uxFU<7U41e5FDbezg4
zL*lF?^=A#hNIi8a`6YM8`!1?rm^QCE{xUgQZ#;;~8vrZ!LIBsaX?^$bSRC+oXfm_x
zTHadT&yJAJWU_a=nO-NqUJ?O+cPmo=h2<%Nt0(MmXKc*ckob~VdNEs@tN}7x0>%bV
z3?+&|14n42U++T&YoP@tJA-yD-F2!~yJ~&PnjYt^vs&7_=@8c!y1grxnMF;MWZvKC
zvzRIaj>2ZPw#&mc612qxA-&qLH6|5ri?IvZ@$q8C*nUhx?Lj0-j3*m`?3~gt^Yj(u
z(v0bZ1S9gPAeWSOG`!;dLHM1t&zMd1a0u7V`>|t7eigGHk=?5f0}CC@Vf5gJAfYbQCBq$D
zV3
zE@f-nGl>*Q%KUaU<5?Ip;q#^$>Vu26RA{pt#Zvsy}>
zYcH4U-{I}t!GsH&8eYR^$bIMNskB+pNb
z`|=d1XgmZpUQ~~Gw(jSeuR6^N(bx6I<~rp%92tdB3^{
z{b6)v&<`iWDn2EcFmW{$tvmA-6u!;<@jr409kCW0G9B}O1^?`N
z-d&4ix)C-ERjvKwOb)B%P>7r%uc)n~fCQMF)Ux122tKh6ipgd}c6beOs}6Lf3O|*7e^d;OCf3v?HVFzYB!-;wsWqxJhjOQktm*W;SW4W$?zG(2ZS0$oA8|n;LukoMm^NNuhu$<9oei*
zz*Jdy;w;yEH>#gXN!C8~oUG^k-s7;_8?NGv#9Z6&W+m>r8<(rb!@}+K%X+sr9}qhe
zzHi0kAbJ^-Re0{j1j{>~e9k>cqtmg|aWieAOza#=
zgOSv59HnF^Wl0MuYXAb9MyGcig5N0a&5}%C9|%mR@aY~sCpU
zkP!kR%J2=y6;lo+KjVEz`OGaYh%WQh_Cji=_FrFIY61Gh85LB
zfK1Ps&~RLffcJR!vS{Pkk6~`%8W)!$m?+Vq;0#dEEpD_sSmL4H3<)`g1Xu*1Ebep|
zhyKvCMFMI3-4>cH<%3^@ye2p)@W3ATm*hG~CV}jCUJS9;OoI
z&A>pVPz6SV&fgV#8$mZUJZ6cYPH`%KOMndHRj^|IfsG>FdLQGn6{kEdM
zlzHTQx}u1xd=EF86vk17)L^l?o8?JT_Kw~uX@87-_FV@o{f-A8zvt9AVl23txZKya
zTv2$Eu>JQ-Kfwh9rU-X7V08O&=8k|7V(Z=S^YT-P5@LMdrAT^jyG&y&oLp9{oGL>7
zUlag9{(MR~m@|{%P3nn!6d2i{Ygxq7hQG$R)!=c&;m72-T2IY2*iXQC>IP8N0?XdELGu6na$9DJPB%R)VrRsU0qyMDJlTBfHIMMLC*U*CWfKCDI379&~
z`hOgKzU8uU5<#St;m@5z8<5XQos(B0Uqn0v&fWSWdjGc9=ueOWO&Bm!sjk_$6iFg5
z)T`va4B5_^A|lqQTG1UaLr*5lJ=w|N%s^i)dzSJ&$&ufb0%tCWY1Eoz{Yxp+=Wdyk
z_^15hm#`9`oRcCzbyRVI-yG1{k^IZq5RL_vYXOSSG2NuX-qeHf-!hqi1ZcFWZC%L^
zj83IiE@aT>2W`#f(b9@2hfKJsplQ2nC>JEEa%mA<(u0>kP%z#b6ffHb
z?yx{Eh(VNOHDw(5<((@GHk|3KlzW81Bl&%^maqn+R%vZFG2L8Sof@JhT39RcQ!lln
zWrl#2oFMbzA5~1AH7JoTE;tTz;=yJ9cIh){P_!(zElXX>lU8E4lK7<|)#VbZt
z*(3vGf>n0E7rN}h>i43IwFrf9k?3r#;BB-OJr@0|O7x4r)@VN@6vNQ(v#44Uot^~O
zSHwHS`6E}8LI0P9|K3_L@Z1%XnG92%)sQd24T431*xpll>Sw<6XGCA;R_YDL_PjEc
zvJ_&JiVRtuE>yIx?GEQn{J;T-2Pvj3sFi(CJ+c&HJ3eM=bZ??byNrv>isNpJ%&&-J
zPH9M#S-UiaW=L6;W=1?cZ1&iK~bAtxzg
zJvgt4WCG<3q%c$mxfiAg7-T`rI;qzKlOvwa2$(he8I+gt!FX*eXj>TiqTRB+rNEM<
z9mV!!j!S)Au4kd8?9$!i{XL{_GcZRdIW31I=>ZGA1$NjmTBSA!%q9ozuHCMOM@`
zP=xr(;@9bw!O;Ef#siHwsJ|3NxU7=%fS6}|!n!hv)?4Wnw1qfHyoq&0r^DQM+g+Xh
zF|0;hUhV+ypk*fq-2mgz!-{nQJ@jmRz&153c5=`wR4KBSRKdm|JS8BdyE#ECWr8#P
zvjLMf&BFdG2i7@QapYe)c%CWEd9_v%)bI_+ty#D{i{WrT2nz1+zTWmYc2N@a=Ppeu
zEU=t!Lo7@)p|GG8_LJ<2`R6d)>T{QkIy9G{{)i|uH1{a}?s!m^-3N?`WI~o9c8Vx;re#
z7hVuXW}%XOWUwwFT}Z1XPt+glo=OHKSCp}zK>k5ps>ftMRUWrNZd%Oqo;h{y+vH>>
zQu^6)D}+){bDeG(E&@yu46rYe+sx{?j@aSffI*Rk7ZM4PrVa(MS+4W7v`j#dUEjYJ
z`~ej@VpJXyB`KW+wQ=srnLV1m!6+gpYw!t@>^1UJa>?H-z7vd=gb5oul&04Nn3E~q
z%m26@IB}cO(m4qJXuS@V@Bfkq*$eo|7bZH_o*-la^O=WHhesXe$a3#WHI&6rRGISF
z)bDA8TY=Z&9=lRy(%fMqJd*139Ds=(Z6*3no_sH7X;$*@!=g4PL_9krCb
zloP*Y*w4+A*xB^?wE@;LIA%2P@qrXK@
zLmKpYN>oy!2^k^S^^)t#{kI04lx$c1(RO!jK?Y*kZ}{KG}2Rt>T`CYvW2+%=pgh&inzG_Ea2
zEs=;UW(P<1%=YjycbbtctUICy`lLrClL&50R%$G%YGLJ+MuQM-LNtFRZlqtIkiY9q
zRu0ksaFl+I1Fmg4S~}jYQrrZ-TQSTNG^qp}`tU*;-8{~gUAj~L$o+4ICgeh>9ipcx
zlq>fXRi(zPQv5ZyTrMnvwhRe>Jb0wPbQp31@GX0CJT{@%l~~wYd}lepD!
z`Qll2#sGVkwesqH9tJRV_5P>)k3sX~$Vy>zF>4ui(DGR=E|&n?6@VK~+MKiG_j`4t{{ERSF=p{sJq^Vy|6K8p0$S;Aq}v#t$998CdK
zP503Ml3fnk-SnN)u_E`GBmEe@6d{Ay=6p4KQ*HAMN~*$jJX1?;Nszt_{ScYM&A$}I
zb|{u(k6^5JK8IMXjpHX?-Q%YrFG%k5HII`2>ojjC->xgpT``=l*7Y@iX%3DlUnQK<
zI`v`O)OkquP1sEL{zn06?ZzMkgoSS7*9f5B$FF&=!#ryxvY
zY;XQjkLfG{kkWZ8{dyT+6rdMxLgHDaGWJ8iMcmEm4@76_j}fG6YfJM&uwZ0#UW;ur
zS;cgjgh`6zKl0D{*VpNNefn?3NyuYI)MYj_ze|;U|7fSiG_wrLIVA}6DElinQUv#B
z4osEKAMO-t+q{$u)rJAzosZjfOX`iHhP=7>faJUvwN|T;(_zq&lAnWn!@XXvO=Rzi
zg?Ta>BH39tExMRpfz+{a1x}86~nFz
zMFj;>%Q){jZ0)co=kN93g&OCU#k4E>Y@TEqSGEcFLk@lvYDX)Asgk@V|5l(>Un-wd
z9T2d@x(S3Mt3U)V&p-H2k_D6yU7L_J$4}gQvgUHq{|s!JH{MQ;uvlxDl>JUnHTcLs
zKeZUmYSE)_XX1#RRM6`-UtX2Z`b*j&34xCX(4Y=b1O(x*cbb(u&wwonON&_El*e6Y
z*N+AXLDs+sd~F^fmnYX%6YJ`~6+6WoCNq*MH9zRgH)mY-UWz}fY~Za@dR32+BL$;$
zT{D`Bc0`+N5NlVG0;$BBrv5(dPwbmm8+&VBETn#LMXW$)DHr>{Ojj)1bvSBd{JKb~E?uBC>l^Ytfioch$+#&^2HRq|<12j%c0G&7?}o(z7Oz>=~;Mw$9<6V&pFEfq-t9H
z##88zg^IO}#~<(q&U@V>7ChTF2Nseqak*G{T<;e&5}RBe`5!M<+_ty-0(Dw!ea8MQ
ziMj;3+38p@j|DakW
zx+z&<8|*l{FYDmIE(xIg@z!w>IqxbpaFvKJ(>Idl-e2i2z-?RG=ZM?5Qr5s-*JX
z;>>NO$Suy?l9lKsJ9{~yO)%hmEa|8o^iO0|Gg(R!!}<$oXq63
z##-^)K0cg0LnIW?Wk?NH@ZZ_lG^!61OB#h+QNN<791jucPz_j2tOf3MKqW&2CHmhz
zV&ZYOLaE|yDr1Pk{d&9ArtoF_JAxDG@vgpZ0hP))xf+SW
zW?z${Qc9ijyM9Lq2o|(MZlL-m-o_pM2-6c0p(;P0Aiyh6;Mx0QJD-%FKb@9gLn7*S
zLBqgzyEp!JdP@lWRvc3g+=j*D{2xaPQn@9&^23*o^?!fWY?ESq5=OlUS1r7%CCDPw
zLoZ+?Ty6py2MPJ=pahSII8$&pGE2RW_rd3j2dN&SNr>ZGZP3%LY%zBd(0Zslq}Aa{
zZxBRWuX`NRbdhixjDk``X#jkcB%o+kktWVYrWk^*NY~bOt$ET_eRxMLcH?(!N$EH+
zVeu&Ku;|3O{@1!170(QgYS!i^C=UWTT;$-~jJ=^_!#BbJh-mr0|IB2$`nQ!!`a1j>
zxph0OT>OEt1Ym@RAb58a94<&||Buxx?!wh>B;%B6*u8XgVsOq>HSP(03dyfHcn}yb
zuiFJnXk>13KS|_p3VWA`i4-cEM4n1
zI+1b7)d^Nx{{;ulwOjsGJ!JnQt2->yMN2Tl_5q9`)JaVb(wm88B`n
z1qvRvO+w68v{v{jlM1do+~mpRoBgo9?cNxi(<{-QrM>Od{cPN_H)TV$)by;;;Cqwd
z-L>Wcura-)xDYF#x^}4oETkhhK*hp>*D@&Z@*5q^`TV2|Lk8=qDlc{
z!6wwsoit19d25FHEM1c+oK-DXuFoR&2Oo{*WJa>!gyVB+DdiF@8I2Zsk@LEc1|aJs
zlGVna9VnOdTDNpON;lS+dm9S9+Na`idt=Q7?twK@LJMEzt9f*acv^!dQZ~-Gd**c-
z9#1SW73*}$VufVm1x$)yA9RwdsNWRrPusFCIGKv9@r>q}zbK{kt5ZI=`^?igp}P?(
zww$34+O}-%RP6tWSb(=xdeFdw6`nRzdCT3(p3(^x@t8gdh=CLf%2SI&kw@n%khn@l
z5+6?xUl~sp?S#K%PFk@Vyv=yL_oT=~@8|*P(fW<(fsw_wJl&Zg!--GsEFvI6%>q8i
zQ7alIaw)x-TlgrHgyEtGoNVgYt-`?=BXi}dgsACJ;u-g+=}N#!n1vA*bbt_$%-?E9
z`28o8TX7XExnUVgZGQekBf)fMG1<5&|_bE79gK@$!*i?xXsgZ&tyLc?C9|-d1oguDAaCi8h+76|tVbA#YRb7VIBR5fbD52-^Hc^Kn
z=k0bGJf|aiVj`SSz`8c`3t7K%a>s&d7qTtco5G`44aD<*Y&xyRp}5XXB!oaX^Yw!7
zooY9lO;+&f@9;>Zh3h!?iE*{uwkSqhU6eeMebjOXfua1NvPCA(h_@ML5T2}Q{6(qC
znLVUeBvAUnIOsTZ>>f?+`IjR1a4yNro_dO#-)2nZWb}Vy`s+1l$mx8UdDH1KZ;+E8
zY3^?;uWu)=qW0|YS#!CfwTgO7PHC9I=!@{mCxs_IUim7LF^b8$m?y8W=baqt+OQbzxMuTj}8x5vhF|en(YE%S*m*MN~
zi}Q|r<0dr%Cameec%zBqQpLjV1e_jIDFtQti*O5)Xilp|0^F4;`^TWR#gauMQcd-r
z>$!sU_^_<`?vaE%2Di1Tr<}o?{t-mE?FO-bKU({|v*j8S&D-#4&{huW{~t%^7#&I1
zMd3IT+nlIl+sPYDl8H01ZQHhO+qNdQZQFLfp0EGc>Z(<%?m2g#y`S4M!jHP$g}2B!cl;N0>L@
zRne4khDgL<@E?B|CcOYlL+JC$%-n%E#gL9Byf)xbjSUdWYgM;8m&|Wa+z#f^Af&$WCMM*c+(QUWG|Zd
zNv^rHZyzl+RmKKivhiFg3f4aSYJ0T?<4M{YRzlJ4|K4$Lna1_s?%RrLVnqQB(nq`8
z=_%E6v;@}@Z>r)}5u^yDm#8h5bU!bQjJ^>y+M~I&r`bhfQJL8twrvRn?4X*?a2Pl`
zI&u}}PczUisc#bQMjY@$`L6&nb~b$7FQ#EB^(vrIvxsw<9vrI*9f6MT$oNUc=*RS}
z0(laOwh_UMiCeh^h)Evllay^4O+Kma<-n?sDeba`8xu>o{$FpZXTd{g2-mG=m1P(P
z9!)W8p=`+~0NS-)yH<5$V1vG)-z)N6L;UuqnMAw#d8*T;M>##nzrJ&;p%!fK7rrcQ
zJ+vnDHj*~585}tP=flZA?x5Qo@M9+G7eu--D
zWUiV0<&z*x*6^uz{d)+AkmgzXZ$L-S>5q)#qLVU*(lpSzDK+R3&ssf#^0(KbttHfv
zNvd-x{;B*HcG*K0Jnn=qmT&crENodW8cNi_~(E?VOozDFYqtqYH6(L3tj
zJ$0J=RPEo^=ar#ZTV{dUM!$gxy!`=++BK}R3+kv0d22atgYV{tQ2ltckarsTXqT+v
zJKa~Z{dS$nem<)zJ{bO)RsIhYk{tSsjioGZ8*@S=7rlVl<*CMYuo@d9Pfv(E%#t20Sf)*L^w^=Us*X)uU)4JN
zKV)nLxv~Y8pltVp#PTLTKd|xh$JRf~Ls_B>`Q+Au+mpbV63YnkdG=`GOM|inW2+{8
zsS-_bK`K#dt|gu&q>#~yeCT#`1qP(d!LT&I`mGp!KRo8jFFNCb+k-fp%Gz|?N<8jb
zq)9!hJwXULFbbFGmI5|IsEsI^Fy8ruTY4MjQ|w@oqzAR_PY36n@OBIs!u-WfQZc!{Y3f41db&y6lYX%Oo!i?S*N$=99Pg>_cceuZnmxU*#*3*D^6N;GPqe
z|FsV|3+GPZrib>cp8Qg;mF`u3W+R98gZiT_H~xvCh#Qsh9!qyZ1t=1`{D^^e_Oy%U
zsqk}F{cdxaB3jPO{MtC!CwX3H6Oj@lXP1-ALt$b1-La?={Yr_=UzL>nSQW{mM*in=
z6Lg4?q6Z3n9vg|Lt^Qnr&%KJm3`Vea9s~A82-kjaP}xL9AB>kn-B|w-Av8o;ji@X<
z`H59?x|BKiHegxfx?#(qU0xsfYnqrW4byIwehv~6!4GG71xs^GIj=4lh7HwHp@)+n
z^Qq!u|5vc9Z>-Bzy!i*h#&)@qiuhyUT)sftAdi(7y0U2_J6Gg!7cm_%QEcf9B
zUG$QSI1E`;2qU+CApl7_SKmV4KS@j*N?NH+Tah61PDm%t>j9O^zY2qw8!XmeCcQqN(7Zje>RUZxc#ET2Y~UIu(#%D-
zwa*=wktrZfM)DrJ$=s%$$nO+SJK)h6bg+NWB!gN@AxoZpsjE;kI9lZLZ)*__@O!o$
z_Pgyxt<=_ELDJo=D==v7LiTp|VE*+rIg@&3+;GZzJ|6M-;yr(&WUX2;@%uL-A|fj_
zc>xY9?yV;ue)3!Qnlu6pdOZuvA!RVmAPD)@m00OBxptmT;GusTG^7xGQDoeKFlu3XqjMPZVtyuYrM$
zIq3TIcQdKM@LWi{w2qa8-du@VI~;b)Ipr+s6VYfo;Ny^wyOjOoaX}4Sl#{We%$;m&
zIg((Fjnn0FdPTt7P6W<_L(-)U!owHM=ab(pPWk@cF?Y?GCGs3c-%l5~B-ymrh!uw=
z{SlLSbjYe&H@7QJoj%MpEf|iuKkn@Xk<=*C97B=A;E9T*7O|sAm(2E%#W6+=?^Z`q
zYpgEgL;ApQlg4A&Yx4KBbPc3|Ra>B-ZI%t&XO~S^nJO}*ABuZ04U=OM{kq*y9_D`a
zYofCT{Kt;+YxB(XobS}`TS@k(pfykTO<|7IKi*BJNtuf;t3pN4VSQNG=olU=3ZuFmT`D|EP+Wv6Ne+0E-
z79q><4_X`R5xBtpykNjcE6&Lz1IJwdWxU_#KunLNsi}04!Xe*=|FTRMz%5+!Yn6wWzx~+n-0_EdrCgprf5n-novdf>v6`ADXbC@%C07ww4UJk<
zJ66j{S`S}MD{Aj$&iJ@5q_INgp6uL*V~e{x2o{!{#}r@;ZZ4ozkYcpAdP||Z;2LLl
z;dzXs=7;+x?zirlPdHwp_|snHsZg`&yu64T4Aj?0cle^*NfQv?-k0o;R~t;Gub{m{
znYQW-hKr>$GD{^EL>siN7JgSdQ5>4gLvonYSD+0f=wlBnqM;pUxo86ob3;&4;}C`3
z9O`lL)fuX_fS=WE8tIoWVf&0D54r;I^)-MVyU!otxCMO9FSgq|JGjf!&o9_!33H;M
z^ufH28x9wLQ!4sB&ku@*kQ5xUWF$$nX_tTK$o=NGygB1S04zExcs3n1h88T?-Br~Z
z*thnvXVpi`yBP!oP9)wO+3B`vU9@Z^Vt#>62w03Jn~Kv9vv*S8Qn=G~R{)g%>A;=P
z97}6W;Dh>?TOL>0si`Y%4##d996lVUP+_I=PkNX<-9i0_#lo3D=XLjZO?&uE;nvsJs6Jm3
z1^FaJL0US?<${ieXs?q>XGRdR_3}_GIfN1f*R7PgjY^0#1jeukAJNp)`6qOWlrhYjQikIUZ8X~
zvH_<6(|JwHh5sIJ@DiK2M6uCyJ~s%#nO7i&*-o4w%(#AycItTQEm>_l!)Cms!KGz?
zn*Q7cPgW&+neB!rJLP9Pd+e}TiFFq32u=&xx@q%T$v=ID7Nd4JNx|xx)Ps@h7lj6g
z&A>h*7n8L@0F{G27*%>50&^XbMPU<1@*>QcvQD)IzU+#oIz~|jUg0_?5OP7^a}mEU
z9t~fk#lg+Z&d8}$xunIlN+5CGd|}v{9>2oV#Bm;ap|Ab%kB)Ri$Cc}XTf3Dqd#!lm>*tMH3RgJiO%^Ty(Zt>Zr
zPNDS}<+!jMb>)b6`O)kaH*ZcKX1Bh6(Pw)a+n8?wmo0rCz8Lvw5i=;rZ78(C)LJxNNP24EjP20IgT%+o))}zDm
zIEUrz{%2n1+mkxt`Ia(d%WC!ybJ8b8>*V~vIz=1Y$?1q#Kl8NToA+beTTUyZ#?azW
zV(yv7n$lbeTnXQQ!U}`|d8ac!_Y%x}6%I1mY_cKO&K-??vShX=UD@4EB_G-W@l7rZ
zOuElZsb?Qzxv!c#wed&&ta(0Aq`C7L3cDIb0M2F>HR5EcJU3?V#(0{JPm9S)|-Y!$O?m+
zYnSTF&AJ(PnYtDJya*a8(u$8)t~C}nG!SZ$fJjHp&97T`^aoGCUYLM=RSWAb;jBM-
zc9$A2#qECUf_zs~)5f;0p1DJE*ITOOy+9rurcja6l2m9fRX
zq$P=yrHz8TLE2;4$&kVCu))ItkM{KMQnk$LET65V5JK-j)e6mP!7hdIM?>ZFK`lQeorUbSmX3?y9>v_kgG3>*r
zv82*uc@`<@9VKVe>yt1o4>68PjgGn=U6Q=4z07uytOrq7!HuD^z+N*fIag0I*Quc_
z=S)R~zcz?O@#F-LpZLeDdk?Z&dVbrYefKhacyRb5mBncP<_jNgNL-5r1qJKPR(SX)
zfN|U|K+gEggXFK64OS~rpR;l?>rVZ#hn%X8+Lm8DE4iR%`0=CNKyaEkk(cB6(|rs9
zk<@YEvxvioaRqS*H`VA0b4B$%_UU+K(%7y!Nq5_>A;l>7hK85z^zWjr^O6&nV4bDY
z@%=s$uNr)I$!rbtKx;edQq};m%v*)7G<e{zbH{UZ@Pc`82K78nzmB
zQEa-HTT2CjJw~+|a7+EOT
zto-Lz0{7|6S}WkYcb#)Zvg0){Fj&@fKp^;4Hq(E(g?UHSa`%V!G^~ioJ_Noy@*!Sy
z=$Y2(lh7q@A3n0{#-eGgxhkW_XPVE@UQs-EmF?vXzY&dVVW@mkJp|=K;NZgD_Tk0!
z0=i$1lt6qYtDQ)8xarizo~zJvCMwa&;^Czu*B5%tRzHic>H-w
zfGZPk#3pY_mi=&sriyAv750Q2lZ)M(@-!JU$8n~$VJ)SdfO9fzO~Q+tN++Insjcu{
z+K^Mh(Y|B`x1$j6TH*|85?1N#>pe?_TYYC3>@fZQzXbB~w|`&zlm`$n6LEmXj)#Vp
z5Xg#zh`4u2(hA6c-EejfCg;mWcn<3`ZOh7kz1~-P2vWX(q-
z<*U*n)?DUf!c?_3sAt4xA0U+233nMEET9ZB2S4NUDRa5%wyT%S?62*?H#euj^a<1B
zYwv4$-o9dKaW?8zDVC?BKX(mh@B$?D+j>z`@z%`+%!t-Jvgk&tpZV!X@e$?i5Bkg=^z*)mlJ`3Imx3u%1)4
z2HY!8fn8G>D0KERrS(+9u$!?10Dw6B-#xO!u&dTk?=+&Hq}KL!iZx?ks+QGmJ177`
z`N}rUYGW2R^S8utifrmZNJjMl=>i8!vI;w@)Xl+9z&mbIZ`G2iH~;dGBnVKHlQh>8b;K8L*`f6@@d>y5TLP1uSe1s@$*
zx8ls(tZdD6kCs*L_zdB`x1M&G?(v+N>
z_NTEbykPdK)5(Nger1=XlB{ud&d0B?J-ORBzdep?Y@fn*=i)}=$g1L&3G{xO>l*8J
z;taf8uAxT7>E>x)n^EzO42=a~nA^M8V`>hVw^7Q2%xp}=Tc&jt_AQJ@=pCyM)Io?6
zS2f)`z(wc|eUAst
zX*gwsyJ3U;C1`IxGJ3q>q*f43G9Oo^jEYkc6g1hq8yr0gP>UZh*bl`r5Z0v`bSFpC
z(!>ef0=qPw7XNszm8Tel{G>C*)*j=i!H4WHnA9J|Un6kYusbbEu}7ypo_WDM&*8Mw
z?+->ejhvR54GtSH&M49^tEq{Z9n$`9>QBkdJPy}Faby*jF)Iman4;?Tpv
z{lM6@9tu;~MGreeR24&`Xt$R`f7YWfdX25MX=a5!PobdEyX^^imb8an0ZtHt_d_wi
zN>?ma!S_RuAAK76#p1sMOMa7@k2FKS7Kkc7`@f$Ik
zSPtY!S9e3I9r`Hye8YAPwd{&Whe86)TXI+(((Nwj9RzU_^6w@3&3`P|>!R`4A8fWd
z?cCcX6k#rCFtHlEbhir>6VNm`tjJn)oQJ9y|D#aR_0~aSnfgRZe!j}U$Hg6j##qAT
z;+TR;tIBAx+-}Zeu&O-%>YCSioAP9*hTvO#|J9@Ei3DDX`%B@^u6!%gKkHxm&)IP
zkzFi0CN<9Biz`I+tv>{*A0|+_Uha&EkjEMRtXKZKU*Mx3c!_#z#Kn)J0h;yW4oj2o
zuTRU@e_*WXkBRA8QsJvo8c;Z<*{e2uypN4z{%0V^EIp}=3U*Kr{vuuWCw*t!m%C;J
z5CPGbxdI06n?7TE1n{{7{GA{oJqHEDgh6+KW193?dD+zGv8z8SH(v*_|^YDMl{Wbv;3IW
zz=Ti)dNW|Ic}DRf@q>}^!mM}>qZ{P1oioS=<2f%WCWSU$9|B&NuwOlp_G5oG%wq3Ta{=9}9fDr7k%w
zYYj*1GFHN$=JmsuIKDq!%8_*6r2%irZQ6sd6QS?nUx?y!2*?|(Pw9gHdAz>;#jZXz
zpY!GDJm7bO0fm%?CVKY1{rv^x8vcIXfMe*4C9rek*mOh_Ifi6#1*O?=nC62MK3YXIb{ENmb<~78ZM;bB^)*#zwv#XeXN|LYq-JA!FM>I
z0cvB$V`veZt1r>(z$J+^q=4$oI5B#!jNT+{dfb_Vm30B|OKjm9_2urJF6$uzWJd&j
z0f`u&K|oHVA2i`eaTbv66U#)5P%rcYnzx@dLb!5{A_&Uw`I&H}Lq-_K;
zQ9X~JyPvzRy`MW~aJ#*qf#8W&FH~^yU
zd1(F{&}JR>YH4U0a8UP~ztDName9(#9zD+Ud)aK;dDQ9EJVhsG}Ud_HTwA!m0fSN_36(T7ImZP$FB
zU3^jsWu~}n2)$qQj)wlt5oLZXMEwQQpSu3R-VikOEs0)7#8tm~zMsF1SCGpDUK0fL
zf&_q|08F+Mj2hRVuX^+n6BiR4-L{0(cd?ZjACp_6JTPngyJ;3C?D#Q0B0hC}<9wif
z#*9LFCSASH1DR3PU&p}Ea3E`w*J3xMsuU9MW<7k@)`Ui+;Y0J$ot2xr$?IIV({3M#
zvz*jq_Zlop@je&mc@19fLF_6ii3LoJx@t2wQn74Oq2(^#W595g=oZh>b4SwycKUiR@a<3v1vUYv^CJ9fVtwnWxy$3(
zJ|Fw_Un0Jee-9y>iW47haB&coL^m3r%m3?kyys(_HpH-(th)0~vJfQ@2N6xIPvu`e
zmLvpOen;>EMHIRXQhA^RpObqsLg!=e-xnPjq7?ysX+ZRj9SG$X93+PfHA?>96cDk{
z?H~UT%+a|E@ZJL=jF8#rDeI8~^p@e182F#trbTC8fqy481U{_aW6QIlE%4qTF#g9_
zyq5k20YAD%Fy