Fix all internal links
This commit is contained in:
Julio Castillo
parent
f84957270f
commit
2728c4aac1
|
|
@ -57,7 +57,7 @@ All notable changes to this project will be documented in this file.
|
|||
|
||||
## [7.0.0] - 2021-10-21
|
||||
|
||||
- new cloud operations example showing how to deploy infrastructure for [Compute Engine image builder based on Hashicorp Packer](./cloud-operations/packer-image-builder)
|
||||
- new cloud operations example showing how to deploy infrastructure for [Compute Engine image builder based on Hashicorp Packer](./examples/cloud-operations/packer-image-builder)
|
||||
- **incompatible change** the format of the `records` variable in the `dns` module has changed, to better support dynamic values
|
||||
- new `naming-convention` module
|
||||
- new `cloudsql-instance` module
|
||||
|
|
@ -83,7 +83,7 @@ All notable changes to this project will be documented in this file.
|
|||
- fix `scheduled-asset-inventory-export-bq` module
|
||||
- output custom role information from the `organization` module
|
||||
- enable multiple `vpc-sc` perimeters over multiple modules
|
||||
- new cloud operations example showing how to [restrict service usage using delegated role grants](./cloud-operations/iam-delegated-role-grants)
|
||||
- new cloud operations example showing how to [restrict service usage using delegated role grants](./examples/cloud-operations/iam-delegated-role-grants)
|
||||
- **incompatible change** multiple instance support has been removed from the `compute-vm` module, to bring its interface in line with other modules and enable simple use of `for_each` at the module level; its variables have also slightly changed (`attached_disks`, `boot_disk_delete`, `crate_template`, `zone`)
|
||||
- **incompatible change** dropped the `admin_ranges_enabled` variable in `net-vpc-firewall`. Set `admin_ranges = []` to get the same effect
|
||||
- added the `named_ranges` variable to `net-vpc-firewall`
|
||||
|
|
@ -96,8 +96,8 @@ All notable changes to this project will be documented in this file.
|
|||
- add support for CMEK keys in Data Foundation end to end example
|
||||
- add support for VPC-SC perimeters in Data Foundation end to end example
|
||||
- fix `vpc-sc` module
|
||||
- new networking example showing how to use [Private Service Connect to call a Cloud Function from on-premises](./networking/private-cloud-function-from-onprem/)
|
||||
- new networking example showing how to organize [decentralized firewall](./networking/decentralized-firewall/) management on GCP
|
||||
- new networking example showing how to use [Private Service Connect to call a Cloud Function from on-premises](./examples/networking/private-cloud-function-from-onprem/)
|
||||
- new networking example showing how to organize [decentralized firewall](./examples/networking/decentralized-firewall/) management on GCP
|
||||
|
||||
## [5.0.0] - 2021-06-17
|
||||
|
||||
|
|
|
|||
18
README.md
18
README.md
|
|
@ -20,14 +20,14 @@ The examples in this repository are split in several main sections: **foundation
|
|||
|
||||
Currently available examples:
|
||||
|
||||
- **foundations** - [single level hierarchy](./foundations/environments/) (environments), [multiple level hierarchy](./foundations/business-units/) (business units + environments)
|
||||
- **networking** - [hub and spoke via peering](./networking/hub-and-spoke-peering/), [hub and spoke via VPN](./networking/hub-and-spoke-vpn/), [DNS and Google Private Access for on-premises](./networking/onprem-google-access-dns/), [Shared VPC with GKE support](./networking/shared-vpc-gke/), [ILB as next hop](./networking/ilb-next-hop), [PSC for on-premises Cloud Function invocation](./networking/private-cloud-function-from-onprem/), [decentralized firewall](./networking/decentralized-firewall)
|
||||
- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./data-solutions/cmek-via-centralized-kms/), [Cloud Storage to Bigquery with Cloud Dataflow](./data-solutions/gcs-to-bq-with-dataflow/)
|
||||
- **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](.//cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./cloud-operations/packer-image-builder), [On-prem SA key management](./cloud-operations/onprem-sa-key-management)
|
||||
- **third party solutions** - [OpenShift cluster on Shared VPC](./third-party-solutions/openshift)
|
||||
- **factories** - [Example environments](./factories/example-environments), [Hierarchical Firewall Policies](./factories/firewall-hierarchical-policies), [VPC Firewall Rules](./factories/firewall-vpc-rules), [Subnets](./factories/subnets)
|
||||
- **foundations** - [single level hierarchy](./examples/foundations/environments/) (environments), [multiple level hierarchy](./examples/foundations/business-units/) (business units + environments)
|
||||
- **networking** - [hub and spoke via peering](./examples/networking/hub-and-spoke-peering/), [hub and spoke via VPN](./examples/networking/hub-and-spoke-vpn/), [DNS and Google Private Access for on-premises](./examples/networking/onprem-google-access-dns/), [Shared VPC with GKE support](./examples/networking/shared-vpc-gke/), [ILB as next hop](./examples/networking/ilb-next-hop), [PSC for on-premises Cloud Function invocation](./examples/networking/private-cloud-function-from-onprem/), [decentralized firewall](./examples/networking/decentralized-firewall)
|
||||
- **data solutions** - [GCE/GCS CMEK via centralized Cloud KMS](./examples/data-solutions/cmek-via-centralized-kms/), [Cloud Storage to Bigquery with Cloud Dataflow](./examples/data-solutions/gcs-to-bq-with-dataflow/)
|
||||
- **cloud operations** - [Resource tracking and remediation via Cloud Asset feeds](.//examples/cloud-operations/asset-inventory-feed-remediation), [Granular Cloud DNS IAM via Service Directory](./examples/cloud-operations/dns-fine-grained-iam), [Granular Cloud DNS IAM for Shared VPC](./examples/cloud-operations/dns-shared-vpc), [Compute Engine quota monitoring](./examples/cloud-operations/quota-monitoring), [Scheduled Cloud Asset Inventory Export to Bigquery](./examples/cloud-operations/scheduled-asset-inventory-export-bq), [Packer image builder](./examples/cloud-operations/packer-image-builder), [On-prem SA key management](./examples/cloud-operations/onprem-sa-key-management)
|
||||
- **third party solutions** - [OpenShift cluster on Shared VPC](./examples/third-party-solutions/openshift)
|
||||
- **factories** - [Example environments](./examples/factories/example-environments), [Hierarchical Firewall Policies](./examples/factories/firewall-hierarchical-policies), [VPC Firewall Rules](./examples/factories/firewall-vpc-rules), [Subnets](./examples/factories/subnets)
|
||||
|
||||
For more information see the README files in the [foundations](./foundations/), [networking](./networking/), [data solutions](./data-solutions/), [cloud operations](./cloud-operations/) and [factories](./factories/) folders.
|
||||
For more information see the README files in the [foundations](./examples/foundations/), [networking](./examples/networking/), [data solutions](./examples/data-solutions/), [cloud operations](./examples/cloud-operations/) and [factories](./examples/factories/) folders.
|
||||
|
||||
## Modules
|
||||
|
||||
|
|
@ -40,8 +40,8 @@ The current list of modules supports most of the core foundational and networkin
|
|||
Currently available modules:
|
||||
|
||||
- **foundational** - [folder](./modules/folder), [organization](./modules/organization), [project](./modules/project), [service accounts](./modules/iam-service-account), [logging bucket](./modules/logging-bucket), [billing budget](./modules/billing-budget), [naming convention](./modules/naming-convention)
|
||||
- **networking** - [VPC](./modules/net-vpc), [VPC firewall](./modules/net-vpc-firewall), [VPC peering](./modules/net-vpc-peering), [VPN static](./modules/net-vpn-static), [VPN dynamic](./modules/net-vpn-dynamic), [VPN HA](./modules/net-vpn-ha), [NAT](./modules/net-cloudnat), [address reservation](./modules/net-address), [DNS](./modules/dns), [L4 ILB](./modules/net-ilb), [Service Directory](./modules/service-directory), [Cloud Endpoints](./modules/cloudenpoints)
|
||||
- **compute** - [VM/VM group](./modules/compute-vm), [MIG](./modules/compute-mig), [GKE cluster](./modules/gke-cluster), [GKE nodepool](./modules/gke-nodepool), [COS container](./modules/cos-container) (coredns, mysql, onprem, squid)
|
||||
- **networking** - [VPC](./modules/net-vpc), [VPC firewall](./modules/net-vpc-firewall), [VPC peering](./modules/net-vpc-peering), [VPN static](./modules/net-vpn-static), [VPN dynamic](./modules/net-vpn-dynamic), [VPN HA](./modules/net-vpn-ha), [NAT](./modules/net-cloudnat), [address reservation](./modules/net-address), [DNS](./modules/dns), [L4 ILB](./modules/net-ilb), [Service Directory](./modules/service-directory), [Cloud Endpoints](./modules/endpoints)
|
||||
- **compute** - [VM/VM group](./modules/compute-vm), [MIG](./modules/compute-mig), [GKE cluster](./modules/gke-cluster), [GKE nodepool](./modules/gke-nodepool), [COS container](./modules/cloud-config-container/cos-generic-metadata/) (coredns, mysql, onprem, squid)
|
||||
- **data** - [GCS](./modules/gcs), [BigQuery dataset](./modules/bigquery-dataset), [Pub/Sub](./modules/pubsub), [Datafusion](./modules/datafusion), [Bigtable instance](./modules/bigtable-instance), [Cloud SQL instance](./modules/cloudsql-instance)
|
||||
- **development** - [Cloud Source Repository](./modules/source-repository), [Container Registry](./modules/container-registry), [Artifact Registry](./modules/artifact-registry), [Apigee Organization](./modules/apigee-organization), [Apigee X Instance](./modules/apigee-x-instance)
|
||||
- **security** - [KMS](./modules/kms), [SecretManager](./modules/secret-manager), [VPC Service Control](./modules/vpc-sc)
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Data Platform Foundations - Resources (Step 2)
|
||||
|
||||
This is the second step needed to deploy Data Platform Foundations, which creates resources needed to store and process the data, in the projects created in the [previous step](./../environment/). Please refer to the [top-level README](../README.md) for prerequisites and how to run the first step.
|
||||
This is the second step needed to deploy Data Platform Foundations, which creates resources needed to store and process the data, in the projects created in the [previous step](../01-environment/README.md). Please refer to the [top-level README](../README.md) for prerequisites and how to run the first step.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Manual pipeline Example
|
||||
|
||||
Once you deployed projects [step 1](../infra/tf-phase1/README.md) and resources [step 1](../infra/tf-phase2/README.md) you can use it to run your data pipeline.
|
||||
Once you deployed projects [step 1](../01-environment/README.md) and resources [step 2](../02-resources/README.md) you can use it to run your data pipeline.
|
||||
|
||||
Here we will demo 2 pipelines:
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ You can now connect to the GCE instance with the following command:
|
|||
gcloud compute ssh vm-example
|
||||
```
|
||||
|
||||
You can run now the simple pipeline you can find [here](./script/data_ingestion/). Once you have installed required packages and copied a file into the GCS bucket, you can trigger the pipeline using internal ips with a command simila to:
|
||||
You can run now the simple pipeline you can find [here](./scripts/data_ingestion/). Once you have installed required packages and copied a file into the GCS bucket, you can trigger the pipeline using internal ips with a command simila to:
|
||||
|
||||
```hcl
|
||||
python data_ingestion.py \
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ This sample creates several distinct groups of resources:
|
|||
- one project in the shared folder to set up and host centralized audit log exports
|
||||
- one project in the shared folder to hold services used across environments like GCS, GCR, KMS, Cloud Build, etc.
|
||||
|
||||
The number of resources in this sample is kept to a minimum so as to make it generally applicable, more resources can be easily added by leveraging other [modules from our bundle](../../modules/), or from other sources like the [CFT suite](https://github.com/terraform-google-modules).
|
||||
The number of resources in this sample is kept to a minimum so as to make it generally applicable, more resources can be easily added by leveraging other [modules from our bundle](../../../modules/), or from other sources like the [CFT suite](https://github.com/terraform-google-modules).
|
||||
|
||||
## Shared services
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ This sample creates several distinct groups of resources:
|
|||
- one top-level project to set up and host centralized audit log exports (optional)
|
||||
- one top-level shared services project
|
||||
|
||||
The number of resources in this sample is kept to a minimum so as to make it generally applicable, more resources can be easily added by leveraging other [modules from our bundle](../../modules/), or from other sources like the [CFT suite](https://github.com/terraform-google-modules).
|
||||
The number of resources in this sample is kept to a minimum so as to make it generally applicable, more resources can be easily added by leveraging other [modules from our bundle](../../../modules/), or from other sources like the [CFT suite](https://github.com/terraform-google-modules).
|
||||
|
||||
## Shared services project
|
||||
|
||||
|
|
|
|||
|
|
@ -46,5 +46,5 @@ It is meant to be used as a starting point for most Shared VPC configurations, a
|
|||
|
||||
### Decentralized firewall management
|
||||
|
||||
<a href="./decentralized-firewall/" title="Decentralized firewall management"><img src="./decentralized-firewall/diagram.png" align="left" width="280px"></a> This [example](./decentralized-firewall/) shows how a decentralized firewall management can be organized using [firewall-yaml](../modules/net-vpc-firewall-yaml) module.
|
||||
<a href="./decentralized-firewall/" title="Decentralized firewall management"><img src="./decentralized-firewall/diagram.png" align="left" width="280px"></a> This [example](./decentralized-firewall/) shows how a decentralized firewall management can be organized using the [firewall factory](../factories/firewall-vpc-rules/).
|
||||
<br clear="left">
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Decentralized firewall management
|
||||
|
||||
This sample shows how a decentralized firewall management can be organized using the [firewall-yaml](../../modules/net-vpc-firewall-yaml) module.
|
||||
This sample shows how a decentralized firewall management can be organized using the [firewall factory](../../factories/firewall-vpc-rules/).
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ A single pre-existing project is used in this example to keep variables and comp
|
|||
|
||||
A few APIs need to be enabled in the project, if `apply` fails due to a service not being enabled just click on the link in the error message to enable it for the project, then resume `apply`.
|
||||
|
||||
The VPN used to connect the GKE masters VPC does not account for HA, upgrading to use HA VPN is reasonably simple by using the relevant [module](../../modules/net-vpn-ha).
|
||||
The VPN used to connect the GKE masters VPC does not account for HA, upgrading to use HA VPN is reasonably simple by using the relevant [module](../../../modules/net-vpn-ha).
|
||||
|
||||
|
||||
<!-- BEGIN TFDOC -->
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ This sample creates several distinct groups of resources:
|
|||
|
||||
## Operational considerations
|
||||
|
||||
A single pre-existing project is used in this example to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project. The provided project needs a valid billing account and the Compute and DNS APIs enabled. You can easily create such a project with the [project module](../../modules/project) or with the following commands:
|
||||
A single pre-existing project is used in this example to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project. The provided project needs a valid billing account and the Compute and DNS APIs enabled. You can easily create such a project with the [project module](../../../modules/project) or with the following commands:
|
||||
|
||||
``` shell
|
||||
MY_PROJECT_ID="<desired project id>"
|
||||
|
|
@ -30,7 +30,7 @@ gcloud alpha billing projects link --billing-account=XXXXXX-XXXXXX-XXXXXX $MY_PR
|
|||
gcloud services enable --project=$MY_PROJECT_ID {compute,dns}.googleapis.com
|
||||
```
|
||||
|
||||
The example does not account for HA, but the VPN gateways can be easily upgraded to use HA VPN via the [net-vpn-ha module](../../modules/net-vpn-ha).
|
||||
The example does not account for HA, but the VPN gateways can be easily upgraded to use HA VPN via the [net-vpn-ha module](../../../modules/net-vpn-ha).
|
||||
|
||||
If a single router and VPN gateway are used in the hub to manage all tunnels, particular care must be taken in announcing ranges from hub to spokes, as Cloud Router does not explicitly support transitivity and overlapping routes received from both sides create unintended side effects. The simple workaround is to announce a single aggregated route from hub to spokes so that it does not overlap with any of the ranges advertised by each spoke to the hub.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# On-prem DNS and Google Private Access
|
||||
|
||||
This example leverages the [on prem in a box](../../modules/cloud-config-container/onprem) module to bootstrap an emulated on-premises environment on GCP, then connects it via VPN and sets up BGP and DNS so that several specific features can be tested:
|
||||
This example leverages the [on prem in a box](../../../modules/cloud-config-container/onprem) module to bootstrap an emulated on-premises environment on GCP, then connects it via VPN and sets up BGP and DNS so that several specific features can be tested:
|
||||
|
||||
- [Cloud DNS forwarding zone](https://cloud.google.com/dns/docs/overview#fz-targets) to on-prem
|
||||
- DNS forwarding from on-prem via a [Cloud DNS inbound policy](https://cloud.google.com/dns/docs/policies#create-in)
|
||||
|
|
@ -199,7 +199,7 @@ curl www.onprem.example.org -s |grep h1
|
|||
|
||||
A single pre-existing project is used in this example to keep variables and complexity to a minimum, in a real world scenarios each spoke would probably use a separate project.
|
||||
|
||||
The VPN-s used to connect to the on-premises environment do not account for HA, upgrading to use HA VPN is reasonably simple by using the relevant [module](../../modules/net-vpn-ha).
|
||||
The VPN-s used to connect to the on-premises environment do not account for HA, upgrading to use HA VPN is reasonably simple by using the relevant [module](../../../modules/net-vpn-ha).
|
||||
|
||||
|
||||
<!-- BEGIN TFDOC -->
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Specific modules also offer support for non-authoritative bindings (e.g. `google
|
|||
|
||||
## Compute/Container
|
||||
|
||||
- [COS container](./cos-container) (coredns, mysql, onprem, squid)
|
||||
- [COS container](./cloud-config-container/onprem/) (coredns, mysql, onprem, squid)
|
||||
- [GKE cluster](./gke-cluster)
|
||||
- [GKE nodepool](./gke-nodepool)
|
||||
- [Managed Instance Group](./compute-mig)
|
||||
|
|
@ -49,7 +49,7 @@ Specific modules also offer support for non-authoritative bindings (e.g. `google
|
|||
- [GCS](./gcs)
|
||||
- [Pub/Sub](./pubsub)
|
||||
- [Bigtable instance](./bigtable-instance)
|
||||
- [Cloud SQL instance](./modules/cloudsql-instance)
|
||||
- [Cloud SQL instance](./cloudsql-instance)
|
||||
|
||||
## Development
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ The emulated on-premises infrastructure is composed of:
|
|||
- an Nginx container serving a simple static web page
|
||||
- a [generic Linux container](./docker-images/toolbox) used as a jump host inside the on-premises network
|
||||
|
||||
A [complete scenario using this module](../../../networking/onprem-google-access-dns) is available in the networking examples.
|
||||
A [complete scenario using this module](../../../examples/networking/onprem-google-access-dns) is available in the networking examples.
|
||||
|
||||
The module renders the generated cloud config in the `cloud_config` output, to be used in instances or instance templates via the `user-data` metadata.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ module "folder" {
|
|||
|
||||
### Firewall policy factory
|
||||
|
||||
In the same way as for the [organization]()../organization) module, the in-built factory allows you to define a single policy, using one file for rules, and an optional file for CIDR range substitution variables. Remember that non-absolute paths are relative to the root module (the folder where you run `terraform`).
|
||||
In the same way as for the [organization](../organization) module, the in-built factory allows you to define a single policy, using one file for rules, and an optional file for CIDR range substitution variables. Remember that non-absolute paths are relative to the root module (the folder where you run `terraform`).
|
||||
|
||||
```hcl
|
||||
module "folder" {
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Google Service Account Module
|
||||
|
||||
This module allows simplified creation and management of one a service account and its IAM bindings. A key can optionally be generated and will be stored in Terraform state. To use it create a sensitive output in your root modules referencing the `key` output, then extract the private key from the JSON formatted outputs. Alternatively, the `key` can be generated with `openssl` library and only public part uploaded to the Service Account, for more refer to the [Onprem SA Key Management](../../cloud-operations/onprem-sa-key-management/) example.
|
||||
This module allows simplified creation and management of one a service account and its IAM bindings. A key can optionally be generated and will be stored in Terraform state. To use it create a sensitive output in your root modules referencing the `key` output, then extract the private key from the JSON formatted outputs. Alternatively, the `key` can be generated with `openssl` library and only public part uploaded to the Service Account, for more refer to the [Onprem SA Key Management](../../examples/cloud-operations/onprem-sa-key-management/) example.
|
||||
|
||||
## Example
|
||||
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ This example spins up a simple HTTP server and combines four modules:
|
|||
- [`compute-vm`](../compute-vm) to manage the instance template and unmanaged instance group
|
||||
- this module to create an Internal Load Balancer in front of the managed instance group
|
||||
|
||||
Note that the example uses the GCE default service account. You might want to create an ad-hoc service account by combining the [`iam-service-accounts`](../iam-service-accounts) module, or by having the GCE VM module create one for you. In both cases, remember to set at least logging write permissions for the service account, or the container on the instances won't be able to start.
|
||||
Note that the example uses the GCE default service account. You might want to create an ad-hoc service account by combining the [`iam-service-account`](../iam-service-account) module, or by having the GCE VM module create one for you. In both cases, remember to set at least logging write permissions for the service account, or the container on the instances won't be able to start.
|
||||
|
||||
```hcl
|
||||
module "cos-nginx" {
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ module "firewall" {
|
|||
|
||||
|
||||
### Rules Factory
|
||||
The module includes a rules factory (see [Resource Factories](../../factories/)) for the massive creation of rules leveraging YaML configuration files. Each configuration file can optionally contain more than one rule which a structure that reflects the `custom_rules` variable.
|
||||
The module includes a rules factory (see [Resource Factories](../../examples/factories/)) for the massive creation of rules leveraging YaML configuration files. Each configuration file can optionally contain more than one rule which a structure that reflects the `custom_rules` variable.
|
||||
|
||||
```hcl
|
||||
module "firewall" {
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ module "vpc" {
|
|||
```
|
||||
|
||||
### Subnet Factory
|
||||
The `net-vpc` module includes a subnet factory (see [Resource Factories](../../factories/)) for the massive creation of subnets leveraging one configuration file per subnet.
|
||||
The `net-vpc` module includes a subnet factory (see [Resource Factories](../../examples/factories/)) for the massive creation of subnets leveraging one configuration file per subnet.
|
||||
|
||||
|
||||
```hcl
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Some care must be takend with the `groups_iam` variable (and in some situations
|
|||
Hirerarchical firewall policies can be managed in two ways:
|
||||
|
||||
- via the `firewall_policies` variable, to directly define policies and rules in Terraform
|
||||
- via the `firewall_policy_factory` variable, to leverage external YaML files via a simple "factory" embedded in the module ([see here](../../factories) for more context on factories)
|
||||
- via the `firewall_policy_factory` variable, to leverage external YaML files via a simple "factory" embedded in the module ([see here](../../examples/factories) for more context on factories)
|
||||
|
||||
Once you have policies (either created via the module or externally), you can associate them using the `firewall_policy_association` variable.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue