Fix decentralized-firewall count
This commit is contained in:
parent
6be11dc013
commit
e4cdc8bea7
|
@ -2,22 +2,22 @@
|
||||||
|
|
||||||
This example shows how a decentralized firewall management can be organized using the [firewall factory](../../factories/net-vpc-firewall-yaml/README.md).
|
This example shows how a decentralized firewall management can be organized using the [firewall factory](../../factories/net-vpc-firewall-yaml/README.md).
|
||||||
|
|
||||||
This approach is a good fit when Shared VPCs are used across multiple application/infrastructure teams. A central repository keeps environment/team
|
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.
|
specific folders with firewall definitions in `yaml` format.
|
||||||
|
|
||||||
In the current blueprint multiple teams can define their [VPC Firewall Rules](https://cloud.google.com/vpc/docs/firewalls)
|
In the current blueprint multiple teams can define their [VPC Firewall Rules](https://cloud.google.com/vpc/docs/firewalls)
|
||||||
for [dev](./firewall/dev) and [prod](./firewall/prod) environments using team specific subfolders. Rules defined in the
|
for [dev](./firewall/dev) and [prod](./firewall/prod) environments using team specific subfolders. Rules defined in the
|
||||||
[common](./firewall/common) folder are applied to both dev and prod environments.
|
[common](./firewall/common) folder are applied to both dev and prod environments.
|
||||||
|
|
||||||
> **_NOTE:_** Common rules are meant to be used for situations where [hierarchical rules](https://cloud.google.com/vpc/docs/firewall-policies)
|
> **_NOTE:_** Common rules are meant to be used for situations where [hierarchical rules](https://cloud.google.com/vpc/docs/firewall-policies)
|
||||||
do not map precisely to requirements (e.g. SA, etc.)
|
do not map precisely to requirements (e.g. SA, etc.)
|
||||||
|
|
||||||
This is the high level diagram:
|
This is the high level diagram:
|
||||||
|
|
||||||
![High-level diagram](diagram.png "High-level diagram")
|
![High-level diagram](diagram.png "High-level diagram")
|
||||||
|
|
||||||
The rules can be validated either using an automated process or a manual process (or a combination of
|
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](https://github.com/23andMe/Yamale)
|
the two). There is an blueprint of a YAML-based validator using [Yamale](https://github.com/23andMe/Yamale)
|
||||||
in the [`validator/`](validator/) subdirectory, which can be integrated as part of a CI/CD pipeline.
|
in the [`validator/`](validator/) subdirectory, which can be integrated as part of a CI/CD pipeline.
|
||||||
<!-- BEGIN TFDOC -->
|
<!-- BEGIN TFDOC -->
|
||||||
|
|
||||||
|
@ -51,5 +51,5 @@ module "test" {
|
||||||
root_node = "organizations/0123456789"
|
root_node = "organizations/0123456789"
|
||||||
}
|
}
|
||||||
|
|
||||||
# tftest modules=9 resources=50
|
# tftest modules=7 resources=50
|
||||||
```
|
```
|
||||||
|
|
Loading…
Reference in New Issue