Oracle Enterprise Landing Zone Network Firewall

Any user who is a member of the OCI tenancy administrators group can deploy OELZ. By default, OELZ deployment requires tenancy administrator privileges to deploy the network firewall feature and privileges to create a compartment in the root compartment.

When working with Terraform, consider how to manage the state of the infrastructure. The local configuration file (tf file) contains the desired state of the infrastructure, and the Terraform state file (terraform.tfstate) contains the actual state of configured resources in the OCI tenancy.

1. The Terraform state must be protected against unintentional changes.

   The Terraform tfstate file (readable text) terraform.tfstate contains the OELZ Network Firewall state. To ensure accuracy of the OELZ deployment, don't update the state file manually. Instead, let Terraform manage the update; or if you need to make a manual change, use Terraform CLI state management commands. Terraform automatically backs up the state file in terraform.tfstate.backup in the same folder as terraform.tfstate. If you can't recover from a corrupted or lost terraform.tfstate, use the Terraform state backup.

2. Terraform might overwrite changes made by other means to its managed resources.

   When you provision infrastructure resources with Terraform, the expectation is that only Terraform will manage the OCI tenancy resources. However, there are situations where quick changes are made outside of Terraform. For example, changes might be made by way of the OCI Console. If you resume using Terraform later and changes are detected, Terraform overrides the manual changes. You can accept or import the resource changes to the state file. Terraform can import existing resources to the state, but doesn't generate the configuration.

   Before importing existing resources, you must manually add the imported resources to the configuration files. We recommend this approach only for advanced users. This information doesn't cover manually adding the imported resources.

The hub-and-spoke architecture deployed in OELZ provides several benefits, including:

1. Isolation: Each hub-and-spoke has a separate virtual cloud network (VCN), which provides an additional layer of isolation and security, better management and control over resource access, and limits the blast radius of any security incident.
2. Scalability: According to your requirements, the spoke can be added or removed to support different use cases. This allows for a flexible and scalable architecture that can adapt to changing business needs.
3. Networking: A hub provides a central point for all network traffic to flow through, simplifying overall network architecture and improving security by using the network firewall feature. Resources in different spokes can communicate with each other over the hub-and-spoke network without having to traverse the internet.
4. Resource management: Each spoke can be managed and administered independently for better resource allocation and efficient use of OCI resources. Different teams or business units can also have more control and management of their resources.
5. Cost optimization: By centralizing specific resources such as network firewall and VPN gateways in the hub, managing the resources can be more cost-effective.
6. Governance: Having a central hub makes it easier to apply governance rules and policies across the whole infrastructure, providing a clear view of your resources and activity.

In OELZ v2, a hub network is created in a VCN in each environment's shared network infrastructure compartment. The spoke networks are created in each workload compartment, using DRG attachment through a Dynamic Routing Gateway. This lets the spoke networks access the shared resources in the hub network while maintaining their isolation. If you need more spokes, you can also use the Workload Expansion Stack. In the hub, OELZ will create two subnets (public and private); in the spoke VCN, three subnets (web, app, and db) are created. By default, the network firewall will be deployed in the hub VCN, and you can choose if the network firewall should be part of the public or private subnet.

The hub-and-spoke architecture is a flexible and scalable design pattern that can be used to build complex network architectures in OCI, which means OELZ v2 lets you have a pre-configured environment that's ready to use quickly.

Greenfield deployment refers to setting up an OELZ with a network firewall feature on a clean, new environment that has no previous installation or configuration in the OCI tenancy home region. A Greenfield OCI tenancy deployment is a way of provisioning the OELZ resources and adding network firewall resources.

Brownfield deployment refers to deploying a new firewall feature on top of the existing OELZ environment in the OCI tenancy. Brownfield deployment gives you flexibility, letting you install a network firewall on top of the OELZ baseline in the future, if needed.

For more information, see the Brownfield Deployment Example.

1. Go to the following folder:

   templates/enterprise-landing-zone

2. In the existing example.tfvars* file, provide the variable values.

3. Run the following:

   • terraform init
   • terraform plan -var-file="example.tfvars" -out oelz_nfw.out
   • terraform apply oelz_nfw.out

Identity

Terraform CLI runs under the identity information passed to the Terraform provider. In OELZ, the identity is defined in:

• tenancy_ocid = "<tenancy_ocid>"
• user_ocid = "<user_ocid>"
• fingerprint = "<user_api_key_fingerprint>"
• private_key_path = "<path_to_user_private_key_file>"

The fingerprint and private key pair are obtained in the OCI Console when an API key is created for the user. Save the private key file locally and provide its path (absolute or relative) to the private_key_path variable.

1. In Github, download the repository as a .zip file.

   You can get the zip file from Github and upload it to Resource Manager. To get the zip file, expand the Code button on the repository home page, and then select the Download ZIP option.

2. In the Console, open the navigation menu and click Developer Services, and then click Resource Manager.

3. On the Resource Manager page, click Create a stack.

4. Select My configuration as the origin of the Terraform configuration.

5. Below Stack configuration, select .Zip file, and then upload the zip file that you downloaded earlier.

6. Click Configure variables and provide the variable values.

7. Click Next.

8. Review the stack values, and then click Create to create the stack.

9. On the Stacks page, use the appropriate buttons to plan, apply, or destroy the stack.

You can run Terraform code using OCI Resource Manager.

1. In the Console, log in to the tenancy and enter Stacks in the search bar.

2. Click Create stack.

3. On the Create stack page, select Template.

4. Below Stack configuration, click Select template.

5. Click the Architecture tab, and then select Oracle Enterprise Landing Zone v2.

6. After you provide the variable values, click Next.

7. Review the stack values, and click Create to create the stack.

   A stack is the Resource Manager term for a Terraform configuration and provides an isolated scope for the Terraform state. The stack manages only a single Terraform configuration and uses multiple stacks (one for each configuration) for addressing multiple OELZ configurations.

   For more information, see Overview of Resource Manager.

• enable_network_firewall_prod = "true"
• enable_traffic_threat_log_prod = "true"
• nfw_subnet_type_prod = "private"
• nfw_instance_name_prod = "nfw_name"
• nfw_instance_policy_prod = "nfw_name_policy"

• enable_network_firewall_nonprod = "true"
• enable_traffic_threat_log_nonprod = "false"
• nfw_subnet_type_nonprod = "public"
• nfw_instance_name_nonprod = "nfw_name"
• nfw_instance_policy_nonprod = "nfw_name_policy"

1. Go to the following folder:

   templates/enterprise-landing-zone

2. Provide variable values in the existing example.tfvars file. Add the following network firewall-related variables in the example.tfvars file:

   • enable_network_firewall_prod = "true"
   • enable_traffic_threat_log_prod = "true"
   • nfw_subnet_type_prod = "private"
   • nfw_instance_name_prod = "nfw_name"
   • nfw_instance_policy_prod = "nfw_name_policy"

3. Use any deployment scenario described previously. This example uses the Terraform CLI method.

4. Run the following:

   • terraform init

   • terraform plan -var-file="example.tfvars" -out oelz_nfw.out

   • terraform apply oelz_nfw.out

     Network firewall provisioning typically takes 45-50 minutes.

5. Deploy one more spokes using OELZ Workload Expansion.

   • Go to the following folder: templates/elz-workload

   • Provide variable values in the existing workload_extension-variables.tfvars file. Workload extension variable samples:

     • enable_compartment_delete = false
     • workload_compartment_name = <"Workload Compartment Name">
     • environment_compartment_id = < Environment OCID where network firewall is deployed >
     • workload_expansion_flag = true
     • environment_prefix = "< Production or Non-Production Environment >"
     • workload_prefix = "WRKTEST01"
     • identity_domain_id = < Identity Domain OCID Where Network Firewall Deployed >
     • identity_domain_name = < Identity Domain Name Where Network Firewall Deployed >
     • security_compartment_name = < Security Compartment Name >
     • security_compartment_id = < Security Compartment ID >
     • workload_admin_group_name = "TEST-WRK1-ADMIN"
     • application_admin_group_name = "TEST-WRK1-ADMIN-APP"
     • database_admin_group_name = "TEST-WRK1-ADMIN-DB"
     • idcs_endpoint = < Identity Domain IDCS Endpoint >
     • security_admin_group_name = "OCI-ELZ-UGP-P-SEC-ADMIN"
     • network_admin_group_name = "OCI-ELZ-UGP-P-NET-ADMIN"
     • workload_spoke_vcn_cidr = "10.5.0.0/16"
     • workload_private_spoke_subnet_web_cidr_block = "10.5.1.0/24"
     • workload_private_spoke_subnet_app_cidr_block = "10.5.2.0/24"
     • workload_private_spoke_subnet_db_cidr_block = "10.5.3.0/24"
     • enable_nat_gateway_spoke = true
     • enable_service_gateway_spoke = true
     • drg_id = < DRG OCID Value >
     • hub_public_subnet_cidr_block = "10.1.1.0/24"
     • hub_private_subnet_cidr_block = "10.1.2.0/24"
     • workload_name = "WSPK1"
     • enable_network_monitoring_alarms = false
     • enable_security_monitoring_alarms = false
     • enable_workload_monitoring_alarms = false
     • # workload_topic_endpoints = [""]

   • Make a backup of the providers.tf file.

   • Copy providers.standalone file content to the providers.tf file.

   • Run the following:

     • terraform init
     • terraform plan -var-file="workload_extension-variables.tfvars" -out oelz_wrkspoke1.out
     • terraform apply oelz_wrkspoke1.out

   • Add the baseline spoke route on the newly created spoke route table. Update the following variable in the workload_extension-variables.tfvars file:

     • workload_topic_endpoints = ["< SPOKE CIDR BLOCK>"]

   • Run the following: (This step reverts the Wrk Spoke VCN Security List to the default. For example, manually added Wrk Spoke VCN Security rules will be deleted.)

     • terraform plan -var-file="workload_extension-variables.tfvars" -out oelz_nfw_spoke_route.out
     • terraform apply oelz_nfw_spoke_route.out

   • Merge the backup of the providers.tf file to the provider.tf file.

   • Go to the following folder:

     templates/enterprise-landing-zone

   • Add the newly created spoke routes on the existing hub-and-spoke route table. Update the following variables in the example.tfvars file:

     • prod_workload_compartment_names = [ < New Workload Compartment Name > ]
     • prod_additional_workload_subnets_cidr_blocks = [ < New Spoke VCN CIDR > ]

   • Run the following: (This step will revert the network firewall policy, hub-and-spoke VCN security list to the default. For example, manually added network firewall policy and hub-and-spoke VCN security rules will be deleted.)

     • terraform plan -var-file="workload_extension-variabes"
     • terraform plan -var-file="example.tfvars" -out oelz_nfw_wrkspoke_route.out
     • terraform apply oelz_nfw_wrkspoke_route.out

1. Go to the following folder:

   templates/enterprise-landing-zone

2. Provide OELZ baseline variable values in the existing example.tfvars file. Don't add any network firewall-related variables to the example.tfvars file.

3. Run the following:

   • terraform init
   • terraform plan -var-file="example.tfvars" -out oelz_baseline.out
   • terraform apply oelz_baseline.out

4. Update the network firewall variables in the existing example.tfvars file:

   • enable_network_firewall_prod = "true"
   • enable_traffic_threat_log_prod = "true"
   • nfw_subnet_type_prod = "private"
   • nfw_instance_name_prod = "nfw_name"
   • nfw_instance_policy_prod = "nfw_name_policy"

5. Run the following:

   • terraform plan -var-file="example.tfvars" -out oelz_nfwonbaseline.out
   • terraform apply oelz_nfwonbaseline.out

To deploy more workload spokes, follow the steps supplied in the Greenfield Deployment Example.