History

Dan Farmer 52eb83758f Fix compute-vm:CloudKMS test for provider>=4.54.0 * TF provider >= 4.54.0 now returns `rsa_encrypted_key` for `google_compute_disk.disks["attached-disk"]` (see hashicorp/terraform-provider-google#4448) * Add this field to expected model to fix test assertion failure * Update required TF provider to 4.55.0 (latest) since the assertion will now fail with <4.54.0, which do not return `rsa_encrypted_key` * Updated the whole repo on advice from @ludoo		2023-02-28 15:10:22 +00:00
..
firewall	Rename examples folder to blueprints	2022-09-09 16:38:43 +02:00
validator	Rename examples folder to blueprints	2022-09-09 16:38:43 +02:00
README.md	Fix decentralized firewall test	2023-02-25 19:26:11 +01:00
backend.tf.sample	Rename examples folder to blueprints	2022-09-09 16:38:43 +02:00
diagram.png	Rename examples folder to blueprints	2022-09-09 16:38:43 +02:00
main.tf	Remove redundant ttls	2022-10-25 12:11:07 +02:00
outputs.tf	Rename examples folder to blueprints	2022-09-09 16:38:43 +02:00
variables.tf	Normalize prefix handling in blueprints (#1003 )	2022-11-23 11:09:00 +01:00
versions.tf	Fix compute-vm:CloudKMS test for provider>=4.54.0	2023-02-28 15:10:22 +00:00

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.

Test

module "test" {
  source             = "./fabric/blueprints/networking/decentralized-firewall"
  billing_account_id = "ABCDE-12345-ABCDE"
  prefix             = "prefix"
  root_node          = "organizations/0123456789"
}

# tftest modules=9 resources=50