Files
hunfabric/fast/addons/README.md
Ludovico Magnocavallo 27f1cc2b79 Implement FAST stage add-ons, refactor netsec as add-on (#2800)
* security fixes

* change netsec to be a virtual stage in resman

* remove netsec bits from security stage, leave CAs in place

* netsec - security profile groups

* export regions to networking tfvars

* netsec - trust stores

* netsec refactor, untested

* netsec plan working

* netsec apply

* netsec apply errors

* netsec diagram

* update diagram

* move addon stages to addons folder

* remove top-level assets folder

* deprecate and remove fast plugins

* addon tests

* dynamic addon providers and cicd, untested

* stage 1 addons in stage 0, refactor stage 0 cicd

* addons and cicd refactor in stage 0 with tests

* refactor stage 0 cicd

* readd removed block

* small bootstrap cicd fixes

* refactor stage 1 cicd

* resman tests

* remove plugins from networking tests

* fix fast tests

* ngfw addon outputs

* try to fix unrelated tflint error in bootstrap

* remove common tfvars from bootstrap tests to fix linter errors

* tfdoc

* minimal readmes and links fixes

* tfdoc

* trim down test inventories

* fix plan test

* tfdoc

* allow configuring output files names

* fix tls inspection after adding count to project module

* comment fixes

* tfdoc
2025-01-09 18:14:11 +00:00

2.2 KiB

FAST add-ons

Each of the folders contained here is a separate "add-on" that can be used to add extra functionality to a specific stage.

Add-ons can be thought of as additional thin layers on top of a stage, that reuse its IaC resources and leverage the same IAM configuration: the same service accounts are used to run the add-on, and state configuration is stored in the same bucket as their "parent stage" under a different prefix.

The only dedicated resources that can be optionally defined for add-ons are to enable CI/CD functionality, so that a dedicated repository can be used to host the add-on code and pipeline.

Add-ons are currently only implemented for stage 1 (resource management and VPC-SC), and stage 2 (networking, project factory, security).

Add-on configuration

To configure an add-on:

  • its "parent stage" (the stage the add-on augments) needs to be enabled and applied, so that the IaC and IAM configurations the add-on uses are present
  • the fast_addon variable in the stage controlling the "parent stage" (boostrap for a stage 1 add-on, resource management for a stage 2 add-on) is configured and the stage applied, so that the add-on provider and optional CI/CD resources are created
  • the provider and relevant FAST output variable files are linked or copied in the add-on folder (e.g. via the fast-links.sh script)

At this point the add-on can be run, and operate on the same folders, projects and resources controlled by its "parent stage".

Add-ons typically generate their own FAST output variable files, which can be optionally consumed by downstream stages.

This is an example configuration of the fast_addon variable in the resource management stage, to enable running the NGFW networking add-on. The CI/CD configuration block is optional, and commented out here.

fast_addon = {
  networking-ngfw = {
    parent_stage = "2-networking"
    # cicd_config = {
    #   identity_provider = "github-test"
    #   repository = {
    #     name   = "test/ngfw"
    #     type   = "github"
    #     branch = "main"
    #   }
    # }
  }
}

This configuration will create tfvars/2-networking-ngfw-providers.tf and tfvars/2-networking-ngfw-r-providers.tf provider files in the GCS output bucket and local folder (if configured).