From 1f3b5c5f3a42c65b53cf5ed40e4f682e5bda83cb Mon Sep 17 00:00:00 2001 From: Ludo Date: Thu, 9 Feb 2023 23:56:01 +0100 Subject: [PATCH 1/8] top-level and stage 0 --- fast/stages/0-bootstrap/README.md | 111 +++++++++++++++++------------- fast/stages/CLEANUP.md | 14 ++-- fast/stages/COMPANION.md | 56 +++++++-------- fast/stages/FAQ.md | 42 ++++------- 4 files changed, 111 insertions(+), 112 deletions(-) diff --git a/fast/stages/0-bootstrap/README.md b/fast/stages/0-bootstrap/README.md index 2cab11510d..a4b4f7caee 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 Organization-level diagram

+## 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 /home/ludomagno/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/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 c2c0d3c42dd8fd6845c4928719ef8f61e1b9d11a Mon Sep 17 00:00:00 2001 From: Ludo Date: Fri, 10 Feb 2023 00:24:50 +0100 Subject: [PATCH 2/8] stage 1 --- fast/stages/0-bootstrap/README.md | 2 +- fast/stages/1-resman/README.md | 74 ++++++++++++++++++------------- 2 files changed, 45 insertions(+), 31 deletions(-) diff --git a/fast/stages/0-bootstrap/README.md b/fast/stages/0-bootstrap/README.md index a4b4f7caee..e1bb2948a4 100644 --- a/fast/stages/0-bootstrap/README.md +++ b/fast/stages/0-bootstrap/README.md @@ -282,7 +282,7 @@ The following two snippets show how to leverage the `stage-links.sh` script in t # copy and paste the following commands for '0-bootstrap' -ln -s /home/ludomagno/fast-config/providers/0-bootstrap-providers.tf ./ +ln -s ~/fast-config/providers/0-bootstrap-providers.tf ./ ``` ```bash 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 Resource-management diagram

+## 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 From 5973b5ac4b8e77e4b0fc2f9155d717cbf9bb4d3d Mon Sep 17 00:00:00 2001 From: Ludo Date: Fri, 10 Feb 2023 08:22:00 +0100 Subject: [PATCH 3/8] net peering --- fast/stages/2-networking-a-peering/README.md | 166 +++++++++++-------- 1 file changed, 100 insertions(+), 66 deletions(-) diff --git a/fast/stages/2-networking-a-peering/README.md b/fast/stages/2-networking-a-peering/README.md index 7966ce80bb..efbfb29c91 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 Networking diagram

+## 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 @@ -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. From 359fac58f06fc7c4cd62836e6eae288938187743 Mon Sep 17 00:00:00 2001 From: Ludo Date: Tue, 14 Feb 2023 19:21:52 +0200 Subject: [PATCH 4/8] networking --- fast/stages/2-networking-a-peering/README.md | 4 +- 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 | 164 ++++++++++------- 4 files changed, 306 insertions(+), 201 deletions(-) diff --git a/fast/stages/2-networking-a-peering/README.md b/fast/stages/2-networking-a-peering/README.md index efbfb29c91..c066423cdd 100644 --- a/fast/stages/2-networking-a-peering/README.md +++ b/fast/stages/2-networking-a-peering/README.md @@ -71,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 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 Networking diagram

+## 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 Networking diagram

+## 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..599218b51c 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,32 @@ The following diagram illustrates the high-level design, and should be used as a Networking diagram

+## 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) + ## Design overview and choices ### VPC design @@ -87,57 +113,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 +163,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' -- 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` +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 ./ +``` -### Preliminar activities +### Impersonating the automation service account -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. +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 -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. +Variables in this stage -- like most other FAST stages -- are broadly divided into three separate sets: -You're now ready to run `terraform init` and `apply`. +- 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 @@ -215,6 +228,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 + From d1f10553e9dc0487de7313ec3a0be15edd79be82 Mon Sep 17 00:00:00 2001 From: Ludo Date: Tue, 14 Feb 2023 19:22:25 +0200 Subject: [PATCH 5/8] networking --- fast/stages/2-networking-d-separate-envs/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/fast/stages/2-networking-d-separate-envs/README.md b/fast/stages/2-networking-d-separate-envs/README.md index 599218b51c..19f162f827 100644 --- a/fast/stages/2-networking-d-separate-envs/README.md +++ b/fast/stages/2-networking-d-separate-envs/README.md @@ -19,7 +19,6 @@ The following diagram illustrates the high-level design, and should be used as a - [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) From b0d34b4ab32853eef6d289e0dc33cdac48796e55 Mon Sep 17 00:00:00 2001 From: Ludo Date: Tue, 14 Feb 2023 19:33:12 +0200 Subject: [PATCH 6/8] security --- fast/stage-links.sh | 5 ++ fast/stages/2-security/README.md | 82 +++++++++++++++++++------------- 2 files changed, 55 insertions(+), 32 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/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 Security diagram

+## 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 From 886445902d0685772e03726fffe7686e37f2a9fa Mon Sep 17 00:00:00 2001 From: Ludo Date: Tue, 14 Feb 2023 19:47:38 +0200 Subject: [PATCH 7/8] gke, dp --- fast/stages/3-data-platform/dev/README.md | 103 +++++++++++-------- fast/stages/3-gke-multitenant/dev/README.md | 108 ++++++++++++-------- 2 files changed, 125 insertions(+), 86 deletions(-) diff --git a/fast/stages/3-data-platform/dev/README.md b/fast/stages/3-data-platform/dev/README.md index 615dbde8b0..37c4dc6609 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..32043fb8fe 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 -``` - From 841133b8b0eabf7323cc935de5ae76f19047b15a Mon Sep 17 00:00:00 2001 From: Ludo Date: Tue, 14 Feb 2023 19:51:59 +0200 Subject: [PATCH 8/8] checks --- fast/stages/2-networking-d-separate-envs/README.md | 4 ++-- fast/stages/3-data-platform/dev/README.md | 2 +- fast/stages/3-gke-multitenant/dev/README.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/fast/stages/2-networking-d-separate-envs/README.md b/fast/stages/2-networking-d-separate-envs/README.md index 19f162f827..dfc199cd0f 100644 --- a/fast/stages/2-networking-d-separate-envs/README.md +++ b/fast/stages/2-networking-d-separate-envs/README.md @@ -237,9 +237,9 @@ For PGA to work: 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. +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), as implemented in module `googleapis-private-zone` in [`dns-landing.tf`](./dns-landing.tf) +- 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 diff --git a/fast/stages/3-data-platform/dev/README.md b/fast/stages/3-data-platform/dev/README.md index 37c4dc6609..48d09eafc0 100644 --- a/fast/stages/3-data-platform/dev/README.md +++ b/fast/stages/3-data-platform/dev/README.md @@ -86,7 +86,7 @@ Before running this stage, you need to make sure you have the correct credential ### 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. +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. diff --git a/fast/stages/3-gke-multitenant/dev/README.md b/fast/stages/3-gke-multitenant/dev/README.md index 32043fb8fe..f0460c06c5 100644 --- a/fast/stages/3-gke-multitenant/dev/README.md +++ b/fast/stages/3-gke-multitenant/dev/README.md @@ -47,7 +47,7 @@ Before running this stage, you need to make sure you have the correct credential ### 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. +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.