cloud-foundation-fabric/fast/stages
Ludovico Magnocavallo 82fcd5a7d3
rename FAST globals output file (#1695)
2023-09-20 10:36:06 +02:00
..
0-bootstrap rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
1-resman rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-networking-a-peering rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-networking-b-vpn rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-networking-c-nva rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-networking-d-separate-envs rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-networking-e-nva-bgp rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
2-security rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
3-data-platform rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
3-gke-multitenant rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
3-project-factory rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
CLEANUP.md FAST stage docs cleanup (#1145) 2023-02-15 05:42:14 +00:00
COMPANION.md rename FAST globals output file (#1695) 2023-09-20 10:36:06 +02:00
IaC_SA.png Adding new file FAQ and an image 2022-12-19 16:07:41 -06:00
README.md Fixed type in readme for FAST stages 2023-04-08 19:35:21 +01:00

README.md

FAST stages

Each of the folders contained here is a separate "stage", or Terraform root module.

Each stage can be run in isolation (for example to only bring up a hub and spoke VPC in an existing environment), but when combined together they form a modular setup that allows top-down configuration of a whole GCP organization.

When combined together, each stage is designed to leverage the previous stage's resources and to provide outputs to the following stages via predefined contracts, that regulate what is exchanged.

This has two important consequences

  • any stage can be swapped out and replaced by different code as long as it respects the contract by providing a predefined set of outputs and optionally accepting a predefined set of variables
  • data flow between stages can be partially automated (see stage 00 documentation on output files), reducing the effort and pain required to compile variables by hand

One important assumption is that the flow of data is always forward looking, so no stage needs to depend on outputs generated further down the chain. This greatly simplifies both the logic and the implementation, and allows stages to be effectively independent.

To achieve this, we rely on specific GCP functionality like delegated role grants that allow controlled delegation of responsibilities, for example to allow managing IAM bindings at the organization level in different stages only for specific roles.

Refer to each stage's documentation for a detailed description of its purpose, the architectural choices made in its design, and how it can be configured and wired together to terraform a whole GCP organization. The following is a brief overview of each stage.

To destroy a previous FAST deployment follow the instructions detailed in cleanup.

Organization (0 and 1)

  • Bootstrap
    Enables critical organization-level functionality that depends on broad permissions. It has two primary purposes. The first is to bootstrap the resources needed for automation of this and the following stages (service accounts, GCS buckets). And secondly, it applies the minimum amount of configuration needed at the organization level, to avoid the need of broad permissions later on, and to implement a minimum of security features like sinks and exports from the start.
    Exports: automation variables, organization-level custom roles
  • Resource Management
    Creates the base resource hierarchy (folders) and the automation resources required later to delegate deployment of each part of the hierarchy to separate stages. This stage also configures organization-level policies and any exceptions needed by different branches of the resource hierarchy.
    Exports: folder ids, automation service account emails

Multitenancy

Implemented via separate stages that configure separate FAST-enabled hierarchies for each tenant, check the multitenant stages folder.

Shared resources (2)

Environment-level resources (3)

  • Project Factory
    YAML-based factory to create and configure application or team-level projects. Configuration includes VPC-level settings for Shared VPC, service-level configuration for CMEK encryption via centralized keys, and service account creation for workloads and applications. This stage is meant to be used once per environment.
  • Data Platform
  • GKE Multitenant
  • GCE Migration (in development)