diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 2f6e06ece..9549d6bf3 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -19,6 +19,7 @@ Please provide details about your deployment to help us reproduce the issue. * [ ] US Region Restricted (e.g., Access Policy constraint) * [ ] FedRAMP Medium * [ ] FedRAMP High + * [ ] FedRAMP Moderate * [ ] DoD IL4 * [ ] DoD IL5 * [ ] Stand-alone / Custom diff --git a/.github/ISSUE_TEMPLATE/documentation-suggestion.md b/.github/ISSUE_TEMPLATE/documentation-suggestion.md index c79de6cc4..c98236f7e 100644 --- a/.github/ISSUE_TEMPLATE/documentation-suggestion.md +++ b/.github/ISSUE_TEMPLATE/documentation-suggestion.md @@ -20,4 +20,4 @@ Where should this documentation live? e.g., existing file in `docs/`, a new file Please provide a draft or outline of the content you would like to add. ## Compliance Context (if applicable) -Does this documentation relate to a specific compliance regime (FedRAMP High, IL5) or NIST control? +Does this documentation relate to a specific compliance regime (FedRAMP Moderate, FedRAMP High, IL5) or NIST control? diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 8e269024e..26b1e1d59 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -22,6 +22,7 @@ A clear and concise description of what you want to happen. * [ ] US Region Restricted (e.g., Access Policy constraint) * [ ] FedRAMP Medium * [ ] FedRAMP High + * [ ] FedRAMP Moderate * [ ] DoD IL4 * [ ] DoD IL5 * [ ] All / General diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 0b4060e89..24ba9e2c4 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -14,6 +14,7 @@ Fixes # (GitHub issue id) * [ ] US Region Restricted (e.g., Access Policy constraint) * [ ] FedRAMP Moderate * [ ] FedRAMP High + * [ ] FedRAMP Moderate * [ ] DoD IL4 * [ ] DoD IL5 * [ ] General / All @@ -32,7 +33,7 @@ Fixes # (GitHub issue id) ### Security - [ ] My change adheres to GCP security best practices and the principle of least privilege. -- [ ] I have ensured compliance with the targeted regime (FedRAMP High, IL5, etc.). +- [ ] I have ensured compliance with the targeted regime (FedRAMP Moderate, FedRAMP High, IL5, etc.). ### Testing - [ ] I have tested my changes locally. diff --git a/GEMINI.md b/GEMINI.md index 27fc8be96..9717dcf3f 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -4,7 +4,7 @@ Stellar Engine is a fork of the Google Cloud Foundation Fabric (CFF), providing Infrastructure as Code (IaC) to help Google Cloud Platform (GCP) customers create secure and compliant landing zones. It has a strong focus on environments requiring Assured Workload overlays, such -as FedRAMP High, IL4, and IL5, and includes documentation mapping NIST 800-53r5 controls to accelerate Authorization to Operate (ATO) +as FedRAMP Moderate, FedRAMP High, IL4, and IL5, and includes documentation mapping NIST 800-53r5 controls to accelerate Authorization to Operate (ATO) processes. **Key Technologies:** Terraform, Google Cloud Platform (GCP) @@ -35,7 +35,7 @@ outputs, and any dependencies. Consistency in naming variables, resources, modules, and files is crucial. 5. **Security:** Adhere to GCP security best practices and the principle of least privilege in all configurations. Ensure compliance with -the targeted regime (FedRAMP High, IL5, etc.). +the targeted regime (FedRAMP Moderate, FedRAMP High, IL5, etc.). ## Key Codebase Resources diff --git a/README.md b/README.md index 93f8963ef..726180c46 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ ## Introduction -Stellar Engine is a fork of the Google Cloud Foundation Fabric (CFF) repository, aimed at providing Infrastructure as Code (IaC) for Google Cloud Platform (GCP) customers who need to create a landing zone environment with the Assured Workload overlays. In addition to the IaC, there is [documentation available](./docs/path-to-authorization.md) for both FedRAMP High (FRH), Department of Defense (DoD) Impact Level 4 (IL4) and DoD Impact Level (IL5) compliance regimes that provide a mapping of National Institute of Standards and Technology (NIST) 800-53r5 controls to enable projects that leverage the Stellar Engine codebase to accelerate the speed at which an Authorization to Operate (ATO) can be attained. +Stellar Engine is a fork of the Google Cloud Foundation Fabric (CFF) repository, aimed at providing Infrastructure as Code (IaC) for Google Cloud Platform (GCP) customers who need to create a landing zone environment with the Assured Workload overlays. In addition to the IaC, there is [documentation available](/docs/path-to-authorization.md) for FedRAMP High (FRH), FedRAMP Moderate (FRM), Department of Defense (DoD) Impact Level 4 (IL4) and DoD Impact Level (IL5) compliance regimes that provide a mapping of National Institute of Standards and Technology (NIST) 800-53r5 controls to enable projects that leverage the Stellar Engine codebase to accelerate the speed at which an Authorization to Operate (ATO) can be attained. ## Getting Started @@ -14,7 +14,7 @@ This repository provides **end-to-end blueprints** and a **suite of Terraform mo The target audience for Stellar Engine is organizations and teams that operate in regulated industries or require robust compliance and security frameworks. Below are a few examples of these such users: -- **Government Agencies:** Agencies and contractors, such as those that work with FRH, IL4, and IL5 environments.
+- **Government Agencies:** Agencies and contractors, such as those that work with FRM, FRH, IL4, and IL5 environments.
- **Regulated Industries:** Regulated industries often face overlapping compliance and security requirements; Stellar Engine can simplify that.
- **Educational and Research Institutions:** Universities and research organizations working on government-funded projects that require secure and compliant cloud environments.
@@ -45,7 +45,7 @@ The suite of modules in this repository is designed for rapid composition and re All modules share a similar interface where each module tries to stay close to the underlying provider resources, support IAM together with resource creation and modification, offer the option of creating multiple resources where it makes sense (e.g. not for projects), and be completely free of side-effects (e.g. no external commands). -A well-defined naming standard is used across Stellar Engine to ensure adherence to Google Cloud's best practices, naming requirements, and naming collision avoidance for global resources. The Google Cloud naming standard documentation is [here](./documentation/naming-convention.md) and will be used before the Stellar Engine deployment begins by choosing a naming standard that will flow through the Google Cloud infrastructure state. +A well-defined naming standard is used across Stellar Engine to ensure adherence to Google Cloud's best practices, naming requirements, and naming collision avoidance for global resources. The Google Cloud naming standard documentation is [here](/docs/naming-convention.md) and will be used before the Stellar Engine deployment begins by choosing a naming standard that will flow through the Google Cloud infrastructure state. The current modules support most of the core foundational and networking components used to design end-to-end infrastructure, with more modules in active development for specialized compute, security, and data scenarios. @@ -53,18 +53,18 @@ For more information and usage examples see each module's README file, as well a ## End-to-End Blueprints -Stellar Engine currently offers blueprints that are compliant with [FRH](https://github.com/google/stellar-engine/tree/main/blueprints/fedramp-high) and [IL5](https://github.com/google/stellar-engine/tree/main/blueprints/il5) baselines.
+Stellar Engine currently offers blueprints that are compliant with [FRM](https://github.com/google/stellar-engine/tree/main/blueprints/fedramp-moderate), [FRH](https://github.com/google/stellar-engine/tree/main/blueprints/fedramp-high), and [IL5](https://github.com/google/stellar-engine/tree/main/blueprints/il5) baselines.
These blueprints range from full end-to-end services like a Cloud Native Access Point (CNAP), to ad-hoc services that are designed to be molded to users' individual use cases. For more information, please look at each blueprint's README file. ## Cybersecurity Documentation -In addition to the IaC, Stellar Engine provides supporting documentation that maps NIST 800-53r5 controls for users leveraging the IaC. This documentation is designed to streamline achieving ATO by providing generalized templates. All documentation can be requested [here](https://forms.gle/zdv7Gip4opmdhBqk7). For how to utilize these documents, please see the following [Path to Authorization](./docs/path-to-authorization.md) guide. +In addition to the IaC, Stellar Engine provides supporting documentation that maps NIST 800-53r5 controls for users leveraging the IaC. This documentation is designed to streamline achieving ATO by providing generalized templates. All documentation can be requested [here](https://forms.gle/zdv7Gip4opmdhBqk7). For how to utilize these documents, please see the following [Path to Authorization](/docs/path-to-authorization.md) guide. ## Detailed Deployment Guide -The Stellar Engine Cloud Foundation Fabric Detailed Deployment Guide (DDG) outlines a structured process for deploying a secure, compliant infrastructure on GCP using IaC. Designed to support compliance with standards such as FRH, IL4, and IL5, the guide enables organizations to create a foundational "landing zone" with Assured Workload overlays. It includes mappings of NIST 800-53r5 controls to streamline achieving ATO. The deployment process is divided into stages, each focusing on specific components like resource management, networking, and security configuration. +The Stellar Engine Cloud Foundation Fabric Detailed Deployment Guide (DDG) outlines a structured process for deploying a secure, compliant infrastructure on GCP using IaC. Designed to support compliance with standards such as FRM, FRH, IL4, and IL5, the guide enables organizations to create a foundational "landing zone" with Assured Workload overlays. It includes mappings of NIST 800-53r5 controls to streamline achieving ATO. The deployment process is divided into stages, each focusing on specific components like resource management, networking, and security configuration. Key stages include Stage 0 (Bootstrap), which initializes the infrastructure, creates core Google Cloud Projects, and sets up service accounts; Stage 1 (Resource Management), which organizes Google Cloud Folders and Google Cloud Projects for tenants; and Stage 2 (Network Creation), which configures networking, including advanced setups like Palo Alto NGFWs for IL5 environments. The final stage, Stage 3 (Security and Audit Account Configuration), establishes security protocols, including Customer Managed Encryption Keys (CMEK) requirements and logging for audit purposes. Each stage requires detailed configuration of Terraform variables and adherence to prerequisites like IAM roles, service account setups, and enabling Google Cloud services. @@ -82,7 +82,7 @@ For more information, please look at the [TDD](./docs/tdd.md). ## Security Best Practices Guide -The Stellar Engine Security Best Practices Guide (SBPG) outlines a robust framework for deploying secure and compliant GCP infrastructure. Designed for organizations requiring adherence to FRH and IL5 standards, it employs IaC principles via Terraform. The Stellar Engine facilitates the automated creation of a baseline GCP environment, supporting modular deployment of both Google and approved third-party services. Its hierarchical architecture ensures effective organization, leveraging role-based access control (RBAC), strict IAM policies, and a hub-and-spoke VPC networking design for isolation and scalability. +The Stellar Engine Security Best Practices Guide (SBPG) outlines a robust framework for deploying secure and compliant GCP infrastructure. Designed for organizations requiring adherence to FRM, FRH, and IL5 standards, it employs IaC principles via Terraform. The Stellar Engine facilitates the automated creation of a baseline GCP environment, supporting modular deployment of both Google and approved third-party services. Its hierarchical architecture ensures effective organization, leveraging role-based access control (RBAC), strict IAM policies, and a hub-and-spoke VPC networking design for isolation and scalability. The document emphasizes best practices in identity and access management, security monitoring, and compliance. IAM configurations focus on the principle of least privilege, with automation enabling minimal human interaction during setup. Security features include encryption-at-rest, TLS enforcement, and centralized logging and monitoring through audit logs, VPC flow logs, and other diagnostics. The system supports Assured Workloads, providing region-specific data residency and compliance settings to meet regulatory requirements. diff --git a/blueprints/README.md b/blueprints/README.md index 80b61b0ac..57aec8a46 100644 --- a/blueprints/README.md +++ b/blueprints/README.md @@ -45,7 +45,7 @@ For more information, please see the individual README files in each blueprint's | [Secret Manager](./fedramp-high/secret-manager/) |     ✅     |     ❌     | | [Shielded VM Project](./il5/shielded-vm-project/) |     🔗     |     ✅     | | [Vertex MLOps](./fedramp-high/vertex-mlops/) |     ✅     |     ❌     | -| [VPC Peering Project](./il5/vpc-peering-project/) |     🔗     |     ✅     | +| [VPC Peering Project](./stand-alone/vpc-peering-project/) |     🔗     |     ✅     | | [Workflows](./fedramp-high/workflows/) |     ✅     |     ❌     |
diff --git a/blueprints/il5/compute-engine/README.md b/blueprints/il5/compute-engine/README.md index bd093e938..1dc3d0adf 100644 --- a/blueprints/il5/compute-engine/README.md +++ b/blueprints/il5/compute-engine/README.md @@ -119,4 +119,3 @@ keyrings-keys = { ## Verification of a successful deployment? - Go to the Compute Engine in the GCP Console. Select the VM. Check the Presistent Disk Encryption -![GCP Compute Engine Instance Presistent Disk Encryption](./images/vm-disk-1.png?raw=true "GCP Compute Engine Instance Presistent Disk Encryption") diff --git a/blueprints/third-party-solutions/gitlab/README.md b/blueprints/third-party-solutions/gitlab/README.md index f0bebdfb8..734821af0 100644 --- a/blueprints/third-party-solutions/gitlab/README.md +++ b/blueprints/third-party-solutions/gitlab/README.md @@ -242,7 +242,7 @@ following [link](https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-m If you want to deploy from your Cloud Shell, click on the image below, sign in if required and when the prompt appears, click on “confirm”. -[![Open Cloudshell](../../../assets/images/cloud-shell-button.png)](https://shell.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2FGoogleCloudPlatform%2Fcloud-foundation-fabric&cloudshell_workspace=blueprints%2Fthird-party-solutions%2Fwordpress%2Fcloudrun) +![Open Cloudshell](https://shell.cloud.google.com/cloudshell/editor?cloudshell_git_repo=https%3A%2F%2Fgithub.com%2FGoogleCloudPlatform%2Fcloud-foundation-fabric&cloudshell_workspace=blueprints%2Fthird-party-solutions%2Fwordpress%2Fcloudrun) Otherwise, in your console of choice: diff --git a/docs/ddg.md b/docs/ddg.md index 540c0a018..e940bb65e 100644 --- a/docs/ddg.md +++ b/docs/ddg.md @@ -20,7 +20,7 @@ environment with the Assured Workload overlays. The project has been confirmed to work with (DISA) Impact Level 5 (IL5), Impact Level 4 (IL4), and FedRAMP High, but will function as a starting point for any other Assured Workloads overlay. In addition to the IaC, there is documentation available for both the -IL5 and FedRAMP High compliance regimes that provide a mapping of National +IL5, FedRAMP High, and FedRAMP Moderate compliance regimes that provide a mapping of National Institute of Standards and Technology (NIST) 800-53r5 controls to enable projects that leverage the Stellar Engine codebase to accelerate the speed at which an Authorization to Operate (ATO) can be attained. These responses are @@ -67,7 +67,7 @@ To make using this deployment guide easier, the variables described below need t | :------------------------------------ | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Billing Account | `billing_account.id` | The billing account to use for the deployment of the environments. Console Link | | Bootstrap Project ID | `bootstrap_project` | The bootstrap project id (created below) | -| Compliance Regime | `assured_workloads.regime` | The compliance regime for this environment, (confirmed working in IL4, IL5, FEDRAMP_HIGH, and COMPLIANCE_REGIME_UNSPECIFIED) | +| Compliance Regime | `assured_workloads.regime` | The compliance regime for this environment, (confirmed working in IL4, IL5, FEDRAMP_MODERATE, FEDRAMP_HIGH, and COMPLIANCE_REGIME_UNSPECIFIED) | | Customer ID | `organization.customer_id` | The Google Workspace Directory Customer ID.
Run gcloud organizations list to view. | | Domain Name | `organization.domain` | The primary Fully Qualified Domain Name (FQDN). Run gcloud organizations list to view (make sure you have authorized as per prerequisites below) | | Alert Email | `alert_email` | The email address used for logging alerts notifications. | @@ -207,7 +207,7 @@ billing_account = { id = "``" # taken from Google Cloud Console Billing Accounts -> Manage Billing Account } # region configuration - this will automatically populate locations for GCS, BigQuery, KMS, and logging buckets -# Default to us-east4 for IL5/FedRAMP compliance - adjust as needed +# Default to us-east4 for IL5/FedRAMP High/Moderate compliance - adjust as needed regions = { primary = "``" } @@ -391,7 +391,7 @@ gcloud storage cp gs://${FAST_PREFIX}-prod-iac-core-outputs-0/tfvars/0-bootstrap ## Stage 2 - Network Creation -## FedRAMP High - Stage 2.1 Networking +## FedRAMP High / Moderate - Stage 2.1 Networking ### Steps diff --git a/docs/path-to-authorization.md b/docs/path-to-authorization.md index 7d4e39853..d8f0149f0 100644 --- a/docs/path-to-authorization.md +++ b/docs/path-to-authorization.md @@ -1,6 +1,6 @@ # Path to Authorization -_Impact Level 5 (H-H-X) & FedRAMP High_ +_Impact Level 5 (H-H-X), FedRAMP High & FedRAMP Moderate_ **Created Date:** @@ -67,7 +67,7 @@ privacy risks managed, and authorized for operation or use. - [Impact Level 5 Authorization Boundary](https://forms.gle/zdv7Gip4opmdhBqk7) - - [FedRAMP High Authorization + - [FedRAMP High & Moderate Authorization Boundary](https://forms.gle/zdv7Gip4opmdhBqk7) - Regularly assess the security and privacy risks at the organization level and system level. Update risk assessment results on an on-going basis. @@ -111,10 +111,10 @@ risk assessment(s) frequency in which the controls are monitored? - [Security Control Traceability Matrix (SCTM) Templates](https://forms.gle/zdv7Gip4opmdhBqk7) - (IL5 H-H-X and FedRAMP High Baselines) + (IL5 H-H-X, FedRAMP High, and FedRAMP Moderate Baselines) - [Policies and Procedures Templates](https://forms.gle/zdv7Gip4opmdhBqk7) - (IL5 HHX and FedRAMP High Baselines) + (IL5 HHX, FedRAMP High, and FedRAMP Moderate Baselines) [**Step 3; Implement**](https://csrc.nist.gov/Projects/risk-management/about-rmf/implement-step): diff --git a/docs/runbooks/compute-resource-compromise.md b/docs/runbooks/compute-resource-compromise.md index c1122624e..aa6c4b820 100644 --- a/docs/runbooks/compute-resource-compromise.md +++ b/docs/runbooks/compute-resource-compromise.md @@ -24,7 +24,7 @@ This runbook provides a structured, actionable process for Security Operators an * `roles/compute.storageAdmin` to snapshot disks for forensics. ## 3. Scope -This runbook applies to all environments deployed using the Stellar framework, including FedRAMP High and IL5 landing zones. It assumes the use of modern GCP compute paradigms, including Shielded VMs, OS Login, Workload Identity, and immutable infrastructure. +This runbook applies to all environments deployed using the Stellar framework, including FedRAMP High, FedRAMP Moderate, and IL5 landing zones. It assumes the use of modern GCP compute paradigms, including Shielded VMs, OS Login, Workload Identity, and immutable infrastructure. --- diff --git a/docs/runbooks/customer-managed-encryption-keys-compromise.md b/docs/runbooks/customer-managed-encryption-keys-compromise.md index 07fbb47a2..dd5412047 100644 --- a/docs/runbooks/customer-managed-encryption-keys-compromise.md +++ b/docs/runbooks/customer-managed-encryption-keys-compromise.md @@ -24,7 +24,7 @@ This runbook provides a structured, actionable process for Security Operators an * Familiarity with the Stellar framework's GitOps repository to revert unauthorized Infrastructure as Code (IaC) changes. ## 3. Scope -This runbook applies to all environments deployed using Stellar, including FedRAMP High and IL5 landing zones, where CMEK is mandated for data at rest. It covers: +This runbook applies to all environments deployed using Stellar, including FedRAMP High, FedRAMP Moderate, and IL5 landing zones, where CMEK is mandated for data at rest. It covers: * Compromise of Cloud KMS symmetric or asymmetric keys. * Malicious or accidental scheduling of key destruction. * Loss of access due to improper IAM bindings on keys or key rings. @@ -39,7 +39,7 @@ Monitor for the following indicators of compromise or loss: * **Cloud Logging:** Administrative actions on `cloudkms.googleapis.com`. * **Security Command Center (SCC):** Alerts for anomalous KMS activity, excessive administrative actions, or policy violations. * **Service Disruption (Availability Impact):** Automated alerts for widespread HTTP 500s, applications failing to start, or Cloud Storage/BigQuery returning `Permission Denied` or `FAILED_PRECONDITION` (Key Disabled) errors. -* **Key Access Justifications (KAJ):** For IL5/FedRAMP environments, unusual justification codes logged during key access. +* **Key Access Justifications (KAJ):** For IL5/FedRAMP High/Moderate environments, unusual justification codes logged during key access. ### 4.2 Initial Assessment & Log Extraction 1. **Locate the Log Entry:** Find the specific KMS log entry causing the alert. diff --git a/docs/runbooks/vpc-service-controls-violation.md b/docs/runbooks/vpc-service-controls-violation.md index 6134b3d1c..9033dc2cd 100644 --- a/docs/runbooks/vpc-service-controls-violation.md +++ b/docs/runbooks/vpc-service-controls-violation.md @@ -23,7 +23,7 @@ This runbook provides a structured process for Security Operators and Incident R * `roles/accesscontextmanager.policyAdmin` (via Break-Glass/Emergency Access) to modify perimeters if immediate containment is required. ## 3. Scope -This runbook applies to all environments deployed using the Stellar framework (including FedRAMP High and IL5 landing zones) where VPC-SC is used to protect sensitive data and mitigate data exfiltration risks. +This runbook applies to all environments deployed using the Stellar framework (including FedRAMP High, FedRAMP Moderate, and IL5 landing zones) where VPC-SC is used to protect sensitive data and mitigate data exfiltration risks. --- diff --git a/docs/tdd.md b/docs/tdd.md index 4014e2b4e..8582ce0b1 100644 --- a/docs/tdd.md +++ b/docs/tdd.md @@ -58,8 +58,7 @@ regulations. A root folder is created at the top of the organization to hold all projects and resources. From the root folder, tenants can be created in either an Assured -Workloads folder with configurable compliance regime, such as FedRAMP High or -IL5, based on the needs of the user. Each deployment initially creates a +Workloads folder with configurable compliance regime, such as FedRAMP High, FedRAMP Moderate, or IL5, based on the needs of the user. Each deployment initially creates a development environment with the intention of users migrating to a production environment after the development environment has been fully built and tested. @@ -924,8 +923,7 @@ and workloads. They are isolated from each other and communicate with each other through the hub VPCHub and Spoke Architecture with Compliance Overlays Stellar Engine implements a robust Hub and Spoke network architecture, -specifically tailored to meet rigorous compliance requirements (FedRAMP High and -IL5). In this model, centralized Hub VPCs host shared networking resources, +specifically tailored to meet rigorous compliance requirements (FedRAMP High, FedRAMP Moderate, and IL5). In this model, centralized Hub VPCs host shared networking resources, connectivity gateways (Cloud VPN, Interconnect), and security appliances, while Spoke VPCs host isolated workload environments (e.g., Development, Production). @@ -945,7 +943,7 @@ topology with distinct security appliance strategies: Supported Implementations: -#### FedRAMP High Pattern (2-networking-a-fedramp-high): +#### FedRAMP High / Moderate Pattern (2-networking-a-fedramp): - Topology: VDSS (Landing + DMZ). - Perimeter Security: Uses Network Virtual Appliances (NVAs). diff --git a/fast/README.md b/fast/README.md index dbf98affe..bde55acdb 100644 --- a/fast/README.md +++ b/fast/README.md @@ -44,11 +44,10 @@ FAST also aims to minimize the number of permissions granted to principals accor A resource factory consumes a simple representation of a resource (e.g., in YAML) and deploys it (e.g., using Terraform). Used correctly, factories can help decrease the management overhead of large-scale infrastructure deployments. See "[Resource Factories: A descriptive approach to Terraform](https://medium.com/google-cloud/resource-factories-a-descriptive-approach-to-terraform-581b3ebb59c)" for more details and the rationale behind factories. -FAST uses YAML-based factories to deploy subnets and firewall rules and, as its name suggests, in the [project factory](./stages/3-project-factory/) stage. ### CI/CD -One of our objectives with FAST is to provide a lightweight reference design for the IaC repositories, and a built-in implementation for running our code in automated pipelines. Our CI/CD approach leverages [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation), and provides sample workflow configurations for several major providers. Refer to the [CI/CD section in the bootstrap stage](./stages/0-bootstrap/README.md#cicd) for more details. We also provide separate [optional small stages](./extras/) to help you configure your CI/CD provider. +One of our objectives with FAST is to provide a lightweight reference design for the IaC repositories, and a built-in implementation for running our code in automated pipelines. Our CI/CD approach leverages [Workload Identity Federation](https://cloud.google.com/iam/docs/workload-identity-federation), and provides sample workflow configurations for several major providers. Refer to the CI/CD section in the bootstrap stage for more details. We also provide separate optional small stages to help you configure your CI/CD provider. ## Implementation diff --git a/fast/stages-aw/0-bootstrap/README.md b/fast/stages-aw/0-bootstrap/README.md index 998d4e545..3615e4a65 100644 --- a/fast/stages-aw/0-bootstrap/README.md +++ b/fast/stages-aw/0-bootstrap/README.md @@ -171,7 +171,7 @@ This stage also implements initial support for two interrelated features Workload Identity Federation support allows configuring external providers independently from CI/CD, and offers predefined attributes for a few well known ones (more can be easily added by editing the `identity-providers.tf` file). Once providers have been configured their names are passed to the following stages via interface outputs, and can be leveraged to set up access or impersonation in IAM bindings. -CI/CD support is fully implemented for GitHub, Gitlab, and Cloud Source Repositories / Cloud Build. For GitHub, we also offer a [separate supporting setup](../../extras/0-cicd-github/) to quickly create/configure repositories. +CI/CD support is fully implemented for GitHub, Gitlab, and Cloud Source Repositories / Cloud Build. For details on how to configure both features, refer to the Customizations sections below on [Workload Identity Federation](#workload-identity-federation) and [CI/CD repositories](#cicd-repositories). @@ -329,7 +329,6 @@ The `type` attribute can be set to one of the supported repository types: `githu Once the stage is applied the generated output files will contain pre-configured workflow files for each repository, that will use Workload Identity Federation via a dedicated service account for each repository to impersonate the automation service account for the stage. -You can use Terraform to automate creation of the repositories using the extra stage defined in [fast/extras/0-cicd-github](../../extras/0-cicd-github/) (only for Github for now). The remaining configuration is manual, as it regards the repositories themselves diff --git a/fast/stages-aw/1-resman/README.md b/fast/stages-aw/1-resman/README.md index 0004ce023..94c77c71f 100644 --- a/fast/stages-aw/1-resman/README.md +++ b/fast/stages-aw/1-resman/README.md @@ -31,7 +31,7 @@ The preconfigured provider file uses impersonation to run with this stage's auto ### Lightweight multitenancy -If the organization needs to support tenants without the full complexity and separation offered by our [full multitenant support](../../stages-multitenant/), this stage offers a simplified setup which is suitable for cases where tenants have less autonomy, and don't need to implement FAST stages inside their reserved partition. +If the organization needs to support tenants without the full complexity and separation offered by our full multitenant support, this stage offers a simplified setup which is suitable for cases where tenants have less autonomy, and don't need to implement FAST stages inside their reserved partition. This mode is activated by defining tenants in the `tenants` variable, while IAM configurations that apply to every tenant can be optionally set in the `tenants_config` variable. diff --git a/fast/stages-aw/2-networking-a-fedramp/README.md b/fast/stages-aw/2-networking-a-fedramp/README.md index c694b7b80..153e7d287 100644 --- a/fast/stages-aw/2-networking-a-fedramp/README.md +++ b/fast/stages-aw/2-networking-a-fedramp/README.md @@ -1,9 +1,9 @@ -# FedRAMP High Network +# FedRAMP High / Moderate Network -This stage deploys the networking infrastructure recommended with an Assured Workload FedRAMP High environment. +This stage deploys the networking infrastructure recommended with an Assured Workload FedRAMP High or FedRAMP Moderate environment.

- Networking diagram + Networking diagram

diff --git a/fast/stages-aw/2-networking-a-fedramp/images/Stellar-Engine-Network-FedRAMP-High.png b/fast/stages-aw/2-networking-a-fedramp/images/Stellar-Engine-Network-FedRAMP.png similarity index 100% rename from fast/stages-aw/2-networking-a-fedramp/images/Stellar-Engine-Network-FedRAMP-High.png rename to fast/stages-aw/2-networking-a-fedramp/images/Stellar-Engine-Network-FedRAMP.png diff --git a/fast/stages-aw/2-networking-a-fedramp/images/src/Stellar-Engine-Network-FedRAMP-High.drawio b/fast/stages-aw/2-networking-a-fedramp/images/src/Stellar-Engine-Network-FedRAMP.drawio similarity index 100% rename from fast/stages-aw/2-networking-a-fedramp/images/src/Stellar-Engine-Network-FedRAMP-High.drawio rename to fast/stages-aw/2-networking-a-fedramp/images/src/Stellar-Engine-Network-FedRAMP.drawio diff --git a/fast/stages-aw/2-networking-b-il5-ngfw/README.md b/fast/stages-aw/2-networking-b-il5-ngfw/README.md index 305be8455..8f487058e 100644 --- a/fast/stages-aw/2-networking-b-il5-ngfw/README.md +++ b/fast/stages-aw/2-networking-b-il5-ngfw/README.md @@ -102,10 +102,10 @@ Internal connectivity (e.g. between the landing landing VPC and the spokes) is r This is an options summary -- [VPC Peering](https://cloud.google.com/vpc/docs/vpc-peering) (used here to connect the landing landing VPC with the spokes, also used by [02-networking-vpn](../2-networking-b-vpn/)) +- [VPC Peering](https://cloud.google.com/vpc/docs/vpc-peering) (used here to connect the landing landing VPC with the spokes) - 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) (used here to connect the landing landing and dmz VPCs) and multi-NIC appliances with NCC/BGP support implemented [here](../2-networking-e-nva-bgp/) +- [Multi-NIC appliances](https://cloud.google.com/architecture/best-practices-vpc-design#multi-nic) (used here to connect the landing landing and dmz VPCs) and multi-NIC appliances with NCC/BGP support implemented here - Pros: provides 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 @@ -202,12 +202,12 @@ VPCs are defined in separate files, one for `landing` (landing and dmz), one for These files contain different resources: - **project** ([`projects`](../../../modules/project)): the "[host Google Cloud Project](https://cloud.google.com/vpc/docs/shared-vpc)" containing the VPCs and enabling the required APIs. -- **VPCs** ([`net-vpc`](../../../modules/net-vpc)): manages the subnets, the explicit routes for `{private,restricted}.googleapis.com` and the DNS inbound policy for the landing landing VPC. Non-infrastructural subnets are created leveraging resource factories. Sample subnets are shipped in [data/subnets](./data/subnets) and can be easily customized to fit users' needs. [PSA](https://cloud.google.com/vpc/docs/configure-private-services-access#allocating-range) are configured by the variable `psa_ranges` if managed services are needed. +- **VPCs** ([`net-vpc`](../../../modules/net-vpc)): manages the subnets, the explicit routes for `{private,restricted}.googleapis.com` and the DNS inbound policy for the landing landing VPC. Non-infrastructural subnets are created leveraging resource factories. Sample subnets are shipped in data/subnets and can be easily customized to fit users' needs. [PSA](https://cloud.google.com/vpc/docs/configure-private-services-access#allocating-range) are configured by the variable `psa_ranges` if managed services are needed. - **Cloud NAT** ([`net-cloudnat`](../../../modules/net-cloudnat)) (in the dmz landing VPC only): it manages the networking infrastructure required to enable the Internet egress. ### VPNs -The connectivity between on-premises and GCP (the landing landing VPC) is implemented with Cloud HA VPN ([`net-vpn`](../../../modules/net-vpn-ha)) and defined in [`vpn-onprem.tf`](./vpn-onprem.tf). The file implements a single logical connection between on-premises and the landing landing VPC, both in `us-east4` and `us-central1`. The relevant parameters for its configuration are found in the variables `vpn_onprem_primary_config` and `vpn_onprem_secondary_config`. +The connectivity between on-premises and GCP (the landing landing VPC) is implemented with Cloud HA VPN ([`net-vpn`](../../../modules/net-vpn-ha)) and defined in `vpn-onprem.tf`. The file implements a single logical connection between on-premises and the landing landing VPC, both in `us-east4` and `us-central1`. The relevant parameters for its configuration are found in the variables `vpn_onprem_primary_config` and `vpn_onprem_secondary_config`. ### Routing and BGP @@ -220,9 +220,9 @@ BGP sessions for landing landing to on-premises are configured through the varia ### Firewall **VPC firewall rules** ([`net-vpc-firewall`](../../../modules/net-vpc-firewall)) are defined per-vpc on each `vpc-*.tf` file and leverage a resource factory to massively create rules. -To add a new firewall rule, create a new file or edit an existing one in the `data_folder` directory defined in the module `net-vpc-firewall`, following the examples of the "[Rules factory](../../../modules/net-vpc-firewall#rules-factory)" section of the module documentation. Sample firewall rules are shipped in [data/firewall-rules/dmz](./data/firewall-rules/dmz) and in [data/firewall-rules/landing](./data/firewall-rules/landing), and can be easily customized. +To add a new firewall rule, create a new file or edit an existing one in the `data_folder` directory defined in the module `net-vpc-firewall`, following the examples of the "[Rules factory](../../../modules/net-vpc-firewall#rules-factory)" section of the module documentation. Sample firewall rules are shipped in data/firewall-rules/dmz and in data/firewall-rules/landing, and can be easily customized. -**Hierarchical firewall policies** ([`folder`](../../../modules/folder)) are defined in `main.tf` and managed through a policy factory implemented by the `net-firewall-policy` module, which is then applied to the `Networking` folder containing all the core networking infrastructure. Policies are defined in the `rules_file` file, to define a new one simply use the [firewall policy module documentation](../../../modules/net-firewall-policy/README.md#factory)". Sample hierarchical firewall rules are shipped in [data/hierarchical-ingress-rules.yaml](./data/hierarchical-ingress-rules.yaml) and can be easily customised. +**Hierarchical firewall policies** ([`folder`](../../../modules/folder)) are defined in `main.tf` and managed through a policy factory implemented by the `net-firewall-policy` module, which is then applied to the `Networking` folder containing all the core networking infrastructure. Policies are defined in the `rules_file` file, to define a new one simply use the [firewall policy module documentation](../../../modules/net-firewall-policy/README.md#factory)". Sample hierarchical firewall rules are shipped in data/hierarchical-ingress-rules.yaml and can be easily customised. ### DNS architecture diff --git a/fast/stages-aw/README.md b/fast/stages-aw/README.md index 05e1230c4..6fca78203 100644 --- a/fast/stages-aw/README.md +++ b/fast/stages-aw/README.md @@ -17,7 +17,7 @@ To achieve this, we rely on specific GCP functionality like [delegated role gran 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](CLEANUP.md). +To destroy a previous FAST deployment follow the instructions detailed in cleanup. ## Fast Stages Diagram @@ -33,10 +33,10 @@ To destroy a previous FAST deployment follow the instructions detailed in [clean ## Networking (2) -- [FedRAMP High/Moderate Compliant](2-networking-a-fedramp-high/README.md) +- [FedRAMP High/Moderate Compliant](/fast/stages-aw/2-networking-a-fedramp/README.md) - [IL5/IL4 Compliant](2-networking-b-il5-ngfw/README.md) -Manages centralized network resources in a separate stage, and is typically owned by the networking team. This stage implements a hub-and-spoke design, and includes connectivity via VPN to on-premises, and YAML-based factories for firewall rules (hierarchical and VPC-level) and subnets. Currently, two networking options (IL5 and FedRAMP High Compliant) are available, with a third lightweight networking option currently being developed, with recommended usage in IL2 and FedRAMP Moderate environments. +Manages centralized network resources in a separate stage, and is typically owned by the networking team. This stage implements a hub-and-spoke design, and includes connectivity via VPN to on-premises, and YAML-based factories for firewall rules (hierarchical and VPC-level) and subnets. Currently, two networking options (IL5/IL4 and FedRAMP High/Moderate Compliant) are available. ## Security (3) diff --git a/modules/analytics-hub/README.md b/modules/analytics-hub/README.md index 3482d797c..8a7b3d76b 100644 --- a/modules/analytics-hub/README.md +++ b/modules/analytics-hub/README.md @@ -137,7 +137,7 @@ module "analytics-hub" { ### Factory -Similarly to other modules, a rules factory (see [Resource Factories](../../blueprints/factories/)) is also included here to allow managing listings inside the same exchange via descriptive configuration files. +Similarly to other modules, a rules factory (see Resource Factories) is also included here to allow managing listings inside the same exchange via descriptive configuration files. Factory configuration is via one optional attributes in the `factory_config_path` variable specifying the path where tags files are stored. diff --git a/modules/billing-account/README.md b/modules/billing-account/README.md index 2d6a0e1c3..f7db8ff1f 100644 --- a/modules/billing-account/README.md +++ b/modules/billing-account/README.md @@ -32,7 +32,7 @@ provider "google" { ### IAM bindings -Billing account IAM bindings implement [the same interface](../../adrs/modules/20230816-iam-refactor.md) used for all other modules. +Billing account IAM bindings implement the same interface used for all other modules. ```hcl module "billing-account" { diff --git a/modules/cloud-function-v1/README.md b/modules/cloud-function-v1/README.md index 6b427e654..e966a74c1 100644 --- a/modules/cloud-function-v1/README.md +++ b/modules/cloud-function-v1/README.md @@ -418,8 +418,8 @@ module "cf-http" { ## Fixtures -- [cloudbuild-custom-pool.tf](../../tests/fixtures/cloudbuild-custom-pool.tf) -- [functions-default-sa-iam-grants.tf](../../tests/fixtures/functions-default-sa-iam-grants.tf) -- [pubsub.tf](../../tests/fixtures/pubsub.tf) -- [secret-credentials.tf](../../tests/fixtures/secret-credentials.tf) +- cloudbuild-custom-pool.tf +- functions-default-sa-iam-grants.tf +- pubsub.tf +- secret-credentials.tf diff --git a/modules/cloud-function-v2/README.md b/modules/cloud-function-v2/README.md index 366eac29d..984065f0e 100644 --- a/modules/cloud-function-v2/README.md +++ b/modules/cloud-function-v2/README.md @@ -355,8 +355,8 @@ module "cf-http" { ## Fixtures -- [cloudbuild-custom-pool.tf](../../tests/fixtures/cloudbuild-custom-pool.tf) -- [functions-default-sa-iam-grants.tf](../../tests/fixtures/functions-default-sa-iam-grants.tf) -- [pubsub.tf](../../tests/fixtures/pubsub.tf) -- [secret-credentials.tf](../../tests/fixtures/secret-credentials.tf) +- cloudbuild-custom-pool.tf +- functions-default-sa-iam-grants.tf +- pubsub.tf +- secret-credentials.tf diff --git a/modules/cloud-run-v2-se/README.md b/modules/cloud-run-v2-se/README.md index 0a651c41a..3870a6a8d 100644 --- a/modules/cloud-run-v2-se/README.md +++ b/modules/cloud-run-v2-se/README.md @@ -581,10 +581,10 @@ module "cloud_run" { ## Fixtures -- [cloudsql-instance.tf](../../tests/fixtures/cloudsql-instance.tf) -- [iam-service-account.tf](../../tests/fixtures/iam-service-account.tf) -- [pubsub.tf](../../tests/fixtures/pubsub.tf) -- [secret-credentials.tf](../../tests/fixtures/secret-credentials.tf) -- [shared-vpc.tf](../../tests/fixtures/shared-vpc.tf) -- [vpc-connector.tf](../../tests/fixtures/vpc-connector.tf) +- cloudsql-instance.tf +- iam-service-account.tf +- pubsub.tf +- secret-credentials.tf +- shared-vpc.tf +- vpc-connector.tf diff --git a/modules/cloud-run-v2/README.md b/modules/cloud-run-v2/README.md index 0a651c41a..3870a6a8d 100644 --- a/modules/cloud-run-v2/README.md +++ b/modules/cloud-run-v2/README.md @@ -581,10 +581,10 @@ module "cloud_run" { ## Fixtures -- [cloudsql-instance.tf](../../tests/fixtures/cloudsql-instance.tf) -- [iam-service-account.tf](../../tests/fixtures/iam-service-account.tf) -- [pubsub.tf](../../tests/fixtures/pubsub.tf) -- [secret-credentials.tf](../../tests/fixtures/secret-credentials.tf) -- [shared-vpc.tf](../../tests/fixtures/shared-vpc.tf) -- [vpc-connector.tf](../../tests/fixtures/vpc-connector.tf) +- cloudsql-instance.tf +- iam-service-account.tf +- pubsub.tf +- secret-credentials.tf +- shared-vpc.tf +- vpc-connector.tf diff --git a/modules/compute-mig/README.md b/modules/compute-mig/README.md index 01aec0163..f0382e25f 100644 --- a/modules/compute-mig/README.md +++ b/modules/compute-mig/README.md @@ -425,5 +425,5 @@ module "nginx-mig" { ## Fixtures -- [attached-disks.tf](../../tests/fixtures/attached-disks.tf) +- attached-disks.tf diff --git a/modules/compute-vm/README.md b/modules/compute-vm/README.md index 1928a8dce..3064b4f95 100644 --- a/modules/compute-vm/README.md +++ b/modules/compute-vm/README.md @@ -969,6 +969,6 @@ module "sole-tenancy" { ## Fixtures -- [iam-service-account.tf](../../tests/fixtures/iam-service-account.tf) -- [net-vpc-ipv6.tf](../../tests/fixtures/net-vpc-ipv6.tf) +- iam-service-account.tf +- net-vpc-ipv6.tf diff --git a/modules/data-catalog-tag-template/README.md b/modules/data-catalog-tag-template/README.md index 73246cfc4..732868321 100644 --- a/modules/data-catalog-tag-template/README.md +++ b/modules/data-catalog-tag-template/README.md @@ -72,7 +72,7 @@ module "data-catalog-tag-template" { ## Factory -Similarly to other modules, a rules factory (see [Resource Factories](../../blueprints/factories/)) is also included here to allow tag template management via descriptive configuration files. +Similarly to other modules, a rules factory (see Resource Factories) is also included here to allow tag template management via descriptive configuration files. Factory configuration is done via a single optional attribute in the `factory_config_path` variable specifying the path where tag template files are stored. diff --git a/modules/data-catalog-tag/README.md b/modules/data-catalog-tag/README.md index fa2f3379e..baf0843dd 100644 --- a/modules/data-catalog-tag/README.md +++ b/modules/data-catalog-tag/README.md @@ -88,7 +88,7 @@ module "data-catalog-tag" { ### Factory -Similarly to other modules, a rules factory (see [Resource Factories](../../blueprints/factories/)) is also included here to allow tags management via descriptive configuration files. +Similarly to other modules, a rules factory (see Resource Factories) is also included here to allow tags management via descriptive configuration files. Factory configuration is via one optional attributes in the `factory_config_path` variable specifying the path where tags files are stored. diff --git a/modules/dataproc/README.md b/modules/dataproc/README.md index 6f7356a24..ad5a9e10f 100644 --- a/modules/dataproc/README.md +++ b/modules/dataproc/README.md @@ -320,5 +320,5 @@ module "processing-dp-cluster" { ## Fixtures -- [gke-cluster-standard.tf](../../tests/fixtures/gke-cluster-standard.tf) +- gke-cluster-standard.tf diff --git a/modules/dns-response-policy/README.md b/modules/dns-response-policy/README.md index 010c09c5a..b55a53b5a 100644 --- a/modules/dns-response-policy/README.md +++ b/modules/dns-response-policy/README.md @@ -164,5 +164,5 @@ restricted: ## Fixtures -- [dns-response-policy.tf](../../tests/fixtures/dns-response-policy.tf) +- dns-response-policy.tf diff --git a/modules/dns/README.md b/modules/dns/README.md index fe2fdb90c..d88c91e26 100644 --- a/modules/dns/README.md +++ b/modules/dns/README.md @@ -211,6 +211,6 @@ module "public-dns" { ## Fixtures -- [compute-mig.tf](../../tests/fixtures/compute-mig.tf) -- [net-lb-app-int-cross-region.tf](../../tests/fixtures/net-lb-app-int-cross-region.tf) +- compute-mig.tf +- net-lb-app-int-cross-region.tf diff --git a/modules/iam-service-account/README.md b/modules/iam-service-account/README.md index e039fc87f..1f03225d3 100644 --- a/modules/iam-service-account/README.md +++ b/modules/iam-service-account/README.md @@ -2,7 +2,7 @@ This module allows simplified creation and management of one a service account and its IAM bindings. -The Service Account `key` can be generated with `openssl` library and only the public part uploaded to the Service Account, for more refer to the [Onprem SA Key Management](../../blueprints/cloud-operations/onprem-sa-key-management/) example. +The Service Account `key` can be generated with `openssl` library and only the public part uploaded to the Service Account, for more refer to the Onprem SA Key Management example. Note that outputs have no dependencies on IAM bindings to prevent resource cycles. diff --git a/modules/ncc-spoke-ra/README.md b/modules/ncc-spoke-ra/README.md index f20585242..5f9d4b156 100644 --- a/modules/ncc-spoke-ra/README.md +++ b/modules/ncc-spoke-ra/README.md @@ -163,5 +163,5 @@ module "spoke-ra" { ## Fixtures -- [compute-vm-nva.tf](../../tests/fixtures/compute-vm-nva.tf) +- compute-vm-nva.tf diff --git a/modules/net-address/README.md b/modules/net-address/README.md index 535b222ac..38a70d5d6 100644 --- a/modules/net-address/README.md +++ b/modules/net-address/README.md @@ -253,6 +253,6 @@ module "addresses" { ## Fixtures -- [cloudsql-instance.tf](../../tests/fixtures/cloudsql-instance.tf) -- [net-vpc-ipv6.tf](../../tests/fixtures/net-vpc-ipv6.tf) +- cloudsql-instance.tf +- net-vpc-ipv6.tf diff --git a/modules/net-firewall-policy/README.md b/modules/net-firewall-policy/README.md index bffad88a8..a1d5c8c14 100644 --- a/modules/net-firewall-policy/README.md +++ b/modules/net-firewall-policy/README.md @@ -165,7 +165,7 @@ module "firewall-policy" { ### Factory -Similarly to other modules, a rules factory (see [Resource Factories](../../blueprints/factories/)) is also included here to allow route management via descriptive configuration files. +Similarly to other modules, a rules factory (see Resource Factories) is also included here to allow route management via descriptive configuration files. Factory configuration is via three optional attributes in the `rules_factory_config` variable: diff --git a/modules/net-ipsec-over-interconnect/README.md b/modules/net-ipsec-over-interconnect/README.md index 8dd0a6471..48ef99ab2 100644 --- a/modules/net-ipsec-over-interconnect/README.md +++ b/modules/net-ipsec-over-interconnect/README.md @@ -2,7 +2,7 @@ This module allows for the provisioning of [HA VPN over Interconnect](https://cloud.google.com/network-connectivity/docs/interconnect/concepts/ha-vpn-interconnect?hl=it). Specifically, this module creates a VPN gateway, a configurable number of tunnels, and all the resources required to established IPSec and BGP with the peer routers. -The required pair of encrypted VLAN Attachments can be created leveraging the [net-vlan-attachment](../net-vlan-attachment/) module, as shown in the [IoIC Blueprint](../../blueprints/networking/ha-vpn-over-interconnect/). +The required pair of encrypted VLAN Attachments can be created leveraging the [net-vlan-attachment](../net-vlan-attachment/) module, as shown in the IoIC Blueprint. ## Examples diff --git a/modules/net-lb-app-ext-regional/README.md b/modules/net-lb-app-ext-regional/README.md index 68d54d322..83306a3cf 100644 --- a/modules/net-lb-app-ext-regional/README.md +++ b/modules/net-lb-app-ext-regional/README.md @@ -826,6 +826,6 @@ For deploying changes to load balancer configuration please refer to [net-lb-app ## Fixtures -- [compute-vm-group-bc.tf](../../tests/fixtures/compute-vm-group-bc.tf) -- [ssl-certificate.tf](../../tests/fixtures/ssl-certificate.tf) +- compute-vm-group-bc.tf +- ssl-certificate.tf diff --git a/modules/net-lb-app-ext/README.md b/modules/net-lb-app-ext/README.md index be91c2d0f..2e409166f 100644 --- a/modules/net-lb-app-ext/README.md +++ b/modules/net-lb-app-ext/README.md @@ -1091,5 +1091,5 @@ After provisioning this change, and verifying that the new certificate is provis ## Fixtures -- [compute-vm-group-bc.tf](../../tests/fixtures/compute-vm-group-bc.tf) +- compute-vm-group-bc.tf diff --git a/modules/net-lb-app-int-cross-region/README.md b/modules/net-lb-app-int-cross-region/README.md index 3e9fa5486..227e2f114 100644 --- a/modules/net-lb-app-int-cross-region/README.md +++ b/modules/net-lb-app-int-cross-region/README.md @@ -785,5 +785,5 @@ When deploying changes to load balancer configuration please refer to [net-lb-ap ## Fixtures -- [compute-mig.tf](../../tests/fixtures/compute-mig.tf) +- compute-mig.tf diff --git a/modules/net-lb-app-int/README.md b/modules/net-lb-app-int/README.md index 87eaeab54..953a46a8a 100644 --- a/modules/net-lb-app-int/README.md +++ b/modules/net-lb-app-int/README.md @@ -778,5 +778,5 @@ For deploying changes to load balancer configuration please refer to [net-lb-app ## Fixtures -- [compute-vm-group-bc.tf](../../tests/fixtures/compute-vm-group-bc.tf) +- compute-vm-group-bc.tf diff --git a/modules/net-lb-ext/README.md b/modules/net-lb-ext/README.md index 1d45eadbe..97cd2674f 100644 --- a/modules/net-lb-ext/README.md +++ b/modules/net-lb-ext/README.md @@ -233,6 +233,6 @@ For deploying changes to load balancer configuration please refer to [net-lb-app ## Fixtures -- [compute-mig.tf](../../tests/fixtures/compute-mig.tf) -- [compute-vm-group-bc.tf](../../tests/fixtures/compute-vm-group-bc.tf) +- compute-mig.tf +- compute-vm-group-bc.tf diff --git a/modules/net-lb-int/recipe-ilb-next-hop/README.md b/modules/net-lb-int/recipe-ilb-next-hop/README.md index 4234b2579..f29e4eb7d 100644 --- a/modules/net-lb-int/recipe-ilb-next-hop/README.md +++ b/modules/net-lb-int/recipe-ilb-next-hop/README.md @@ -4,7 +4,7 @@ This recipe shows how to bootstraps a minimal infrastructure for testing [ILB as The following diagram shows the resources created by this blueprint -![High-level diagram](diagram.png "High-level diagram") +!High-level diagram Two ILBs are configured on the primary and secondary interfaces of gateway VMs with active health checks, but only a single one is used as next hop by default to simplify testing. The second (right-side) VPC has default routes that point to the gateway VMs, to also use the right-side ILB as next hop set the `ilb_right_enable` variable to `true`. diff --git a/modules/net-vlan-attachment/README.md b/modules/net-vlan-attachment/README.md index a72cb9387..931d5c3fc 100644 --- a/modules/net-vlan-attachment/README.md +++ b/modules/net-vlan-attachment/README.md @@ -544,7 +544,7 @@ module "example-va-b-ew12" { ### IPSec for Dedicated Interconnect -Refer to the [HA VPN over Interconnect Blueprint](../../blueprints/networking/ha-vpn-over-interconnect/) for an all-encompassing example. +Refer to the HA VPN over Interconnect Blueprint for an all-encompassing example. ```hcl resource "google_compute_router" "encrypted-interconnect-underlay-router-ew8" { diff --git a/modules/net-vpc-firewall/README.md b/modules/net-vpc-firewall/README.md index b23a270c4..a2b2aa121 100644 --- a/modules/net-vpc-firewall/README.md +++ b/modules/net-vpc-firewall/README.md @@ -181,7 +181,7 @@ module "firewall" { ### Rules Factory -The module includes a rules factory (see [Resource Factories](../../blueprints/factories/)) for the massive creation of rules leveraging YaML configuration files. Each configuration file can optionally contain more than one rule which a structure that reflects the `custom_rules` variable. +The module includes a rules factory (see Resource Factories) for the massive creation of rules leveraging YaML configuration files. Each configuration file can optionally contain more than one rule which a structure that reflects the `custom_rules` variable. ```hcl module "firewall" { diff --git a/modules/net-vpc/README.md b/modules/net-vpc/README.md index 57570c508..f692b8c95 100644 --- a/modules/net-vpc/README.md +++ b/modules/net-vpc/README.md @@ -466,7 +466,7 @@ module "vpc" { ### Subnet Factory -The `net-vpc` module includes a subnet factory (see [Resource Factories](../../blueprints/factories/)) for the massive creation of subnets leveraging one configuration file per subnet. The factory also supports proxy-only and PSC subnets via the `purpose` attribute. The `name` attribute is optional and defaults to the file name, allowing to use the same name for subnets in different regions. The `context` attribute of `var.factories_config` can optionally contain the map `regions`, which allows for the templatization of the `region` attribute (e.g. see `config/subnets/subnet-simple.yaml` below) +The `net-vpc` module includes a subnet factory (see Resource Factories) for the massive creation of subnets leveraging one configuration file per subnet. The factory also supports proxy-only and PSC subnets via the `purpose` attribute. The `name` attribute is optional and defaults to the file name, allowing to use the same name for subnets in different regions. The `context` attribute of `var.factories_config` can optionally contain the map `regions`, which allows for the templatization of the `region` attribute (e.g. see `config/subnets/subnet-simple.yaml` below) ```hcl module "vpc" { diff --git a/modules/organization-se/README.md b/modules/organization-se/README.md index 525ae912a..23a4914c0 100644 --- a/modules/organization-se/README.md +++ b/modules/organization-se/README.md @@ -524,10 +524,10 @@ module "org" { | [org-policy-custom-constraints.tf](./org-policy-custom-constraints.tf) | None | google_org_policy_custom_constraint | | [organization-policies.tf](./organization-policies.tf) | Organization-level organization policies. | google_org_policy_policy | | [outputs.tf](./outputs.tf) | Module outputs. | | -| [tags.tf](./tags.tf) | None | google_tags_tag_binding · google_tags_tag_key · google_tags_tag_key_iam_binding · google_tags_tag_key_iam_member · google_tags_tag_value · google_tags_tag_value_iam_binding · google_tags_tag_value_iam_member | +| tags.tf | None | google_tags_tag_binding · google_tags_tag_key · google_tags_tag_key_iam_binding · google_tags_tag_key_iam_member · google_tags_tag_value · google_tags_tag_value_iam_binding · google_tags_tag_value_iam_member | | [variables-iam.tf](./variables-iam.tf) | None | | | [variables-logging.tf](./variables-logging.tf) | None | | -| [variables-tags.tf](./variables-tags.tf) | None | | +| variables-tags.tf | None | | | [variables.tf](./variables.tf) | Module variables. | | | [versions.tf](./versions.tf) | Version pins. | | @@ -549,11 +549,11 @@ module "org" { | [logging_exclusions](variables-logging.tf#L28) | Logging exclusions for this organization in the form {NAME -> FILTER}. | map(string) | | {} | | [logging_settings](variables-logging.tf#L35) | Default settings for logging resources. | object({…}) | | null | | [logging_sinks](variables-logging.tf#L45) | Logging sinks to create for the organization. | map(object({…})) | | {} | -| [network_tags](variables-tags.tf#L17) | Network tags by key name. If `id` is provided, key creation is skipped. The `iam` attribute behaves like the similarly named one at module level. | map(object({…})) | | {} | +| network_tags | Network tags by key name. If `id` is provided, key creation is skipped. The `iam` attribute behaves like the similarly named one at module level. | map(object({…})) | | {} | | [org_policies](variables.tf#L54) | Organization policies applied to this organization keyed by policy name. | map(object({…})) | | {} | | [org_policy_custom_constraints](variables.tf#L82) | Organization policy custom constraints keyed by constraint name. | map(object({…})) | | {} | -| [tag_bindings](variables-tags.tf#L81) | Tag bindings for this organization, in key => tag value id format. | map(string) | | {} | -| [tags](variables-tags.tf#L88) | Tags by key name. If `id` is provided, key or value creation is skipped. The `iam` attribute behaves like the similarly named one at module level. | map(object({…})) | | {} | +| tag_bindings | Tag bindings for this organization, in key => tag value id format. | map(string) | | {} | +| tags | Tags by key name. If `id` is provided, key or value creation is skipped. The `iam` attribute behaves like the similarly named one at module level. | map(object({…})) | | {} | ## Outputs diff --git a/modules/project/README.md b/modules/project/README.md index 0380ac2ea..d7f758e2a 100644 --- a/modules/project/README.md +++ b/modules/project/README.md @@ -189,7 +189,7 @@ The `service_agents` output provides a convenient way to access information abou > [!IMPORTANT] > You can only access a service agent's details through the `service_agents` output if its corresponding API is enabled through the `services` variable. -The complete list of Google Cloud service agents, including their names, default roles, and associated APIs, is maintained in the [service-agents.yaml](./service-agents.yaml) file. This file is regularly updated to reflect the [official list of Google Cloud service agents](https://cloud.google.com/iam/docs/service-agents) using the [`build_service_agents`](../../tools/build_service_agents.py) script. +The complete list of Google Cloud service agents, including their names, default roles, and associated APIs, is maintained in the [service-agents.yaml](./service-agents.yaml) file. This file is regularly updated to reflect the [official list of Google Cloud service agents](https://cloud.google.com/iam/docs/service-agents) using the `build_service_agents` script. #### Service Agent Aliases diff --git a/modules/pubsub/README.md b/modules/pubsub/README.md index 958044906..df5b556f1 100644 --- a/modules/pubsub/README.md +++ b/modules/pubsub/README.md @@ -238,6 +238,6 @@ module "pubsub" { ## Fixtures -- [bigquery-dataset.tf](../../tests/fixtures/bigquery-dataset.tf) -- [gcs.tf](../../tests/fixtures/gcs.tf) +- bigquery-dataset.tf +- gcs.tf