1a657b31d3
This is the first version that supports `gateway_api_config` block |
||
|---|---|---|
| .. | ||
| firewall | ||
| validator | ||
| README.md | ||
| backend.tf.sample | ||
| diagram.png | ||
| main.tf | ||
| outputs.tf | ||
| variables.tf | ||
| versions.tf | ||
README.md
Decentralized firewall management
This example shows how a decentralized firewall management can be organized using the firewall factory.
This approach is a good fit when Shared VPCs are used across multiple application/infrastructure teams. A central repository keeps environment/team
specific folders with firewall definitions in yaml format.
In the current blueprint multiple teams can define their VPC Firewall Rules for dev and prod environments using team specific subfolders. Rules defined in the common folder are applied to both dev and prod environments.
NOTE: Common rules are meant to be used for situations where hierarchical rules do not map precisely to requirements (e.g. SA, etc.)
This is the high level diagram:
The rules can be validated either using an automated process or a manual process (or a combination of
the two). There is an blueprint of a YAML-based validator using Yamale
in the validator/ subdirectory, which can be integrated as part of a CI/CD pipeline.
Variables
| name | description | type | required | default |
|---|---|---|---|---|
| billing_account_id | Billing account id used as default for new projects. | string |
✓ | |
| prefix | Prefix used for resource names. | string |
✓ | |
| root_node | Hierarchy node where projects will be created, 'organizations/org_id' or 'folders/folder_id'. | string |
✓ | |
| ip_ranges | Subnet IP CIDR ranges. | map(string) |
{…} |
|
| project_services | Service APIs enabled by default in new projects. | list(string) |
[…] |
|
| region | Region used. | string |
"europe-west1" |
Outputs
| name | description | sensitive |
|---|---|---|
| fw_rules | Firewall rules. | |
| projects | Project ids. | |
| vpc | Shared VPCs. |