Oracle Cloud Infrastructure Documentation

Oracle Enterprise Landing Zone v2 Implementation

User

You must be a member of the administrators group for the tenancy to deploy OELZ v2. You also need to have an API key entry defined. Once you are defined as the member of the administrators group and the API key is defined, your OCI CLI config resembles:

[DEFAULT]
user=ocid1.xxxxxx.xxxxxx.xxxxxx.....  #ocid of the user
fingerprint=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx #user api key fingerprint
tenancy=ocid1.xxxxxx.xxxxxx.xxxxxx..... #tenancy ocid
region=us-phoenix-1 #or desired region
key_file=<path to your private keyfile> # TODO

Region

OELZ v2 should be deployed to the tenancy's home region.

Tenancy

Tenancy is the tenancy to which you intend to deploy OELZ v2.

Logging Analytics

The OCI Logging Analytics service should be enabled for the tenancy. To check the current status of Logging Analytics for the tenancy, in the OCI Console go to the Logging Analytics page. If Logging Analytics hasn't been enabled, a notice is displayed at the top of the page letting you know the service hasn't been enabled for the tenancy.

To enable Logging Analytics

  • In the Console, at the top of the page click Start Using Logging Analytics.

    Wait for the onboarding steps to complete. No further action is required as the OELZ v2 configures the required data sources.

Resource Limits

Most initial resource limits a new tenancy comes with should be sufficient for one OELZ v2 deployment that has two environments and one workload.

There are some resource limits that you need to increase to deploy OELZ v2.

The following information lists the Terraform OCI resource requirements for deploying OELZ v2.

OCI Terraform Resource NameCount
oci_announcements_service_announcement_subscription2
oci_announcements_service_announcement_subscriptions_filter_group4
oci_bastion_bastion2
oci_budget_alert_rule2
oci_budget_budget2
oci_cloud_guard_cloud_guard_configuration2
oci_cloud_guard_target2
oci_core_cpe1
oci_core_default_security_list4
oci_core_drg2
oci_core_drg_attachment4
oci_core_internet_gateway2
oci_core_ipsec1
oci_core_ipsec_connection_tunnel_management2
oci_core_nat_gateway4
oci_core_route_table6
oci_core_security_list4
oci_core_service_gateway4
oci_core_subnet10
oci_core_vcn4
oci_events_rule12
oci_identity_authentication_policy1
oci_identity_compartment13
oci_identity_domain2
oci_identity_dynamic_group1
oci_identity_policy49
oci_identity_tag7
oci_identity_tag_default7
oci_identity_tag_namespace3
oci_kms_key3
oci_kms_vault2
oci_log_analytics_log_analytics_log_group4
oci_logging_log18
oci_logging_log_group2
oci_monitoring_alarm68
oci_objectstorage_bucket7
oci_ons_notification_topic20
oci_sch_service_connector16
oci_streaming_stream2
oci_streaming_stream_pool2
oci_vulnerability_scanning_host_scan_recipe2
oci_vulnerability_scanning_host_scan_target2

To check the limits in the tenancy

  1. In the Console, open the navigation menu and click Governance & Administration. Under Tenancy Management, click Limits, Quotas and Usage.

  2. Under the Service option, select Service Connector Hub. The limit, used, and available amounts are displayed.

For details on limits, quotas, and usage and how to request, and increase them, see Service Limits.

You can request to raise the limits on the Request a service Limit Increase. page.

Compartment Architecture

The following diagram illustrates the OELZ v2 compartment architecture.


Diagram of Oracle Landing Zone Compartment Architecture

Compartment Structure

For OELZ v2, the compartment architecture is as follows:

OELZ v2 Home Compartment

Prod

  • Shared Infrastructure
    • Network
    • Security
  • Workload
  • Logging
  • Backup

Non Prod

  • Shared Infrastructure
    • Network
    • Security
  • Workload
  • Logging
  • Backup

Environments

Environments are full infrastructure deployments that have their own hub-and-spoke network, identity domain, user groups, and so on.

Environments are designed to ensure isolation among themselves. Each environment can contain multiple workloads.

OELZ v2 initially sets up two environments, one for Prod and one for Nonprod. Infrastructure resources within each environment have a single letter abbreviation (such as N or P) to indicate which environment they are part of.

Future elz-environment templates will let you easily add new environments to an existing OELZ v2.

Workloads

Workloads exist in environments, and are the shell for you to deploy an application or service into. They provide infrastructure, such as a compartment, in which you can put application resources, user groups to manage the application, network and logging infrastructure, and so on.

OELZ v2 sets up one initial workload configuration in each environment. Future elz-workload templates will let you easily add additional workloads to a deployed environment within OELZ v2.

Note: Workload compartments and networks contain a user provided workload_name suffix in their names. This lets multiple workloads, each with their own separate compartment and networks, be deployed.

Identity Domain

Each environment has its own identity domain. This exists in the Security compartment of each environment. The identity domain applies to all resources under the environment compartment. OELZ v2 supports only the new identity domains in OCI (Henosis), and not the previous Oracle Identity Cloud Service (IDCS) domains.

Each domain has its own users and groups, and can be federated and configured separately.

Networking

Each environment has its own independent network configuration. The network architecture is a hub-and-spoke design. It's built around OCI's dynamic routing gateway (DRG), which acts as a central router. It can connect multiple virtual networks and VPN or OCI FastConnect links to on-premises networks.

Each environment has one hub virtual cloud network (VCN) that hosts network infrastructure shared among all workloads, such as load balancers and firewalls. There is one public and one private subnet.

For each workload deployed in an environment, there is one spoke network. This has three private subnets, one each for Web, DB, and Application resource.

The elz-network-extension template can add VPN or FastConnect links between an environment's DRG and an on-premises network.

OELZ v2 Deployment

If You Already Have Oracle Cloud Infrastructure

If you already have infrastructure deployed in OCI and want to explore a best-practices infrastructure architecture with OELZ v2, you can create a new Child Tenancy in which to deploy OELZ v2. This helps guarantee there are no conflicts with existing infrastructure.

Note: Child tenancies have their own resource limits, which you should verify meet requirements for deploying OELZ v2.

How to Deploy

You can launch OELZ v2 through Oracle Resource Manager or from the Terraform CLI.

To deploy OELZ v2 from the Terraform CLI

  1. Install Terraform on the system you are deploying from. OELZ v2 works with Terraform 1.0.0 and later, including the latest version (currently 1.3.9). If you don't have Terraform installed, the Terraform Download page has links to the correct package for your system and installation instructions.

  2. Set up API keys to work with your OCI account. Follow the instructions for Required Keys and OCIDs.

  3. Go to the GitHub page to clone the Terraform template.

  4. In the repository, change to the templates/enterprise-landing-zone/ directory. This is the main template for OELZ v2. (The other templates let you deploy other components, such as additional environments or workloads, or deploy pieces of the OELZ v2 architecture for use in your own custom infrastructure designs.)

  5. Create a terraform.tfvars file in the directory, and then populate it with the required variables or override existing variables.

    For a reference of configuration variable values, see Oracle Enterprise Landing Zone v2 Configuration.

    For a list of all available configuration variables, see the Input Variables Reference in the README.

    Note: An example tfvars file is included for reference. We recommend using this file to run the stack from the CLI because of the large number of variables to manage.

  6. From the root of the module, run the following commands to deploy the terraform:

    • terraform init
    • terraform plan
    • terraform apply

    When it completes the process, Terraform provisions your resources and provides outputs.

For more information, see:

To deploy OELZv2 by using Resource Manager

If you're logged into the Console, click Deploy to Oracle Cloud, which takes you directly to Resource Manager. If you use this option, you can go to Step 11 to continue the process. Otherwise, start from Step 1.

  1. On the Console home page, go to Developer Services, Resource Manager, Stacks.

  2. Choose the compartment you want to create the stack in and select Create stack.

  3. Select Source code control system for the Terraform source.

  4. In the Stack Configuration box, under Source Code Management Type, select GitHub.

  5. In the Configuration source provider option, if you have a provider set up for public GitHub, select the provider, and then go to Step 9. Otherwise select Create configuration source provider.

  6. If you don't have a Personal Access Token for your GitHub account, log in to GitHub and create one. The option is available in Settings, Developer settings, Personal access tokens, Tokens (classic) on the GitHub site. The token must have the repo scope.

  7. To create the configuration provider for GitHub in OCI, complete the Create configuration source provider form as follows:

    • Name: GitHub
    • Description: (optional) Public Github Repositories
    • Select the Public Endpoint option.
    • Type: GitHub
    • Server URL: https://github.com/
    • Personal Access Token: Your Personal Access Token

  8. Click Create to create the config provider.

  9. For Repository, select oci-landing-zones.

  10. For Branch, select main.

  11. For Working directory, select templates/enterprise-landing-zone.

  12. For Name, give the stack a name or accept the default name.

  13. In the Create in Compartment dropdown, select the compartment to store the stack in.

  14. In the Terraform Version dropdown, make sure to select a minimum of 1.0.x. Lower Terraform versions are not supported.

    After completing the Stack Creation Wizard, you're prompted to enter values for variables. For a reference of configuration variable values, see Oracle Enterprise Landing Zone v2 Configuration.

    For a list of all available configuration variables, see the Input Variables Reference in the README.

  15. After completing the required input, click Next to review the stack values and create the stack.

    In the Stack page, use the appropriate buttons to plan, apply, or destroy your stack.

For more information, see Resource Manager Overview.

Tear Down and Destroy an OELZ v2 Stack

Tearing down an OELZ v2 stack requires a manual process because of dependencies or conditions outside of Terraform's scope. Use the following information if you need to delete an entire OELZ v2 stack.

To clean up resources

  1. Complete bucket removal for each environment. Navigate to the audit bucket, default bucket, and service event bucket in the logging compartment, and archive bucket in the home compartment. For each bucket:

    • Delete the retention rules: On the bucket page, go to Resource, Retention Rules.
    • Delete all the objects in the bucket: On the bucket page, go to Resource, Objects.
    • Delete the bucket.

  2. Delete and deactivate the identity domain for each environment as follows:

    • Deactivate the identity domain created in the security compartment for each environment: On the Identity Domain page, go to More actions, Deactivate.
    • Delete the identity domain.

  3. Delete the Vault/Key for each environment. Consider the following information:

    • The vault can't be deleted immediately. Vaults have a minimum 7-day waiting period before deletion. When the vault is deleted, all data encrypted with keys in the vault becomes unreadable.
    • You can move the vault and the Master Encryption Key (MKEK) to another compartment outside of OELZ v2 (before deleting it) in order to delete the landing zone. Alternatively, you can schedule a deletion for the key and the vault, and then wait to delete OELZ v2 when the vault and key have been deleted.

  4. Delete the logging analytics as follows:

    • Purge the log by going to the Administration page of OCI Logging Analytics, selecting the storage in the Resources section, and then selecting Purge Logs.
    • Optionally, you can delete the Logging Analytics group.

When these resources have been removed, you can use Terraform to delete the rest of OELZ v2.

If you are using the Terraform CLI

  • Run terraform destroy to remove other resources.

If you are using Resource Manager

  • Go to the corresponding stack created and click Destroy.

Known Issues

The following temporary issues can occur when deploying OELZ v2:

  • 400-InvalidParameter Error in CreateServiceConnector operation: Can occasionally happen if logs take longer than normal to create when setting up the logging infrastructure. This error corrects itself when the logs are created. Later Apply jobs in Resource Manager or invocations of terraform apply should succeed.
  • 429-TooManyRequests Error: A tenancy making a large number of OCI API requests in rapid succession may be throttled by the API. The solution is to wait a few minutes and retry the Terraform operation. This rarely occurs with apply, but can occasionally occur for destroy runs, since delete operations are much faster than create, and Terraform makes many API calls.