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
This commit is contained in:
committed by
GitHub
parent
d6d582e636
commit
27f1cc2b79
@@ -38,9 +38,11 @@ FAST uses YAML-based factories to deploy subnets and firewall rules and, as its
|
||||
|
||||
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.
|
||||
|
||||
<!-- TODO: move CI/CD documentation to its own file -->
|
||||
|
||||
### Multitenant organizations
|
||||
|
||||
FAST has built-in support for multitenancy implemented in [an optional stage 1](./stages/1-tenant-factory/). Tenants can optionally be created with FAST compatibility, allowing them independent use of stages 1+ in their own context.
|
||||
FAST has built-in support for multitenancy implemented in [an add-on stage](./addons/1-resman-tenants/). Tenants can optionally be created with FAST compatibility, allowing them independent use of stages 1+ in their own context.
|
||||
|
||||
The following diagram is a high-level overview of stages used with multitenancy.
|
||||
|
||||
@@ -64,12 +66,3 @@ Since we expect users to customize FAST to their specific needs, we strive to ma
|
||||
We also recognize that FAST users don't need all of its features. Therefore, you don't need to use our project factory or our GKE implementation if you don't want to. Instead, remove those stages or pieces of code and keep what suits you.
|
||||
|
||||
Those familiar with Python will note that FAST follows many of the maxims in the [Zen of Python](https://www.python.org/dev/peps/pep-0020/#id2).
|
||||
|
||||
## Roadmap
|
||||
|
||||
Besides the features already described, FAST also includes:
|
||||
|
||||
- Stage to deploy environment-specific multitenant GKE clusters following Google's best practices
|
||||
- Stage to deploy a fully featured data platform
|
||||
- Reference implementation to use FAST in CI/CD pipelines
|
||||
- Static policy enforcement (planned)
|
||||
|
||||
Reference in New Issue
Block a user