oracle-quickstart/terraform-oci-open-lz

The OCI Open LZ is a set of open and secure landing zone blueprints to simplify the onboarding and running of organizations, business units, and subsidiaries into OCI - by customers, partners, or ISVs. Use it to create your own OCI Landing Zone.

The OCI Operating Entities Landing Zone

Simplifying the Onboarding and Running of OCI

 

 

Welcome to the OCI Operating Entities Landing Zone, also known as OCI Open LZ, a set of open assets and best practices to simplify the onboarding and running of OCI.

The objective of the OCI Open LZ is to increase OCI security and scalability while reducing the design and implementation timelines, associated costs, and efforts - with the following artifacts:

1. Blueprints: Complete landing zone designs with 100% declarative IaC runtime models, ready to onboard organizations and their functional divisions – identified as Operating Entities (OEs).
2. Workloads Extensions: for reducing your time-to-production with ready-made designs and pre-built IaC configurations on common workloads.
3. Add-ons: to help our customers, partners, and the general IT community to create, configure, and run OCI landing zones with best practices and lower efforts.

 

Select Your Blueprint

There are three blueprints available to onboard OCI. Choose the most suitable according to your objectives, review the design, and run the model.

BLUEPRINT	DIAGRAM	SIZE	OBJECTIVE	ORGANIZATIONAL SCOPE
One-OE -- new --		M	A new model to onboard one Operating Entity with its environments, platforms, and projects in one tenancy.	One OU, LoB, OpCo, or Department.
Multi-OE		L	Onboards multiple Operating Entities with a shared services model, with OE-dedicated environments, platforms, and projects, sharing one tenancy.	Several OUs, LoBs, OpCos, or Departments.
Multi-Tenancy*		X-XXL	Uses the One-OE and Multi-OE to onboard all your organizations or customers into several tenancies, while providing your centralized services, shared services, managed services, cloud services, PaaS, or SaaS.	All Your Organizations, OUs, Partners, or Customers.

(*) The multi-tenancy landing zone is available on demand, and it's applicable to all OCI flavors (Public, DRCC, Alloy, etc.)

 

Note these blueprints can be used directly as OCI Standard Landing Zones or as a guide or starting point for a Tailored Design. You can also extend your Landing Zone with ready-made pluggable Workload Extensions to reduce your time-to-production with OCI best practices.

 

Where Do You Start

The following activities are proposed as guidance to understand the overall OCI landing zone strategy and create your OCI-tailored landing zone.

 

#	ACTIVITY	ASSETS	DESCRIPTION
1	PREPARE	EMEA OCI Landing Zones - Video	Understand OCI Landing Zones, approach, and strategy in 13 minutes.
2	PREPARE	EMEA OCI Landing Zones - Git	Review standard landing zones, tailored landing zones, and workload extensions concepts.
3	ENABLE	OCI Learn LZ	Use the OCI Learn LZ exercises to understand how to design and configure OCI Landing Zones.
4	SELECT	OCI Open LZ Blueprints	Select you prefered blueprint from the options above.
4	DESIGN	One-OE Multi-OE Network Hubs	Use the selected OCI Open LZ blueprint to design - in drawio - your functional, security, network, and operations view, with all the diagrams in a reusable format. For network use our Hub Menu to select your prefered topology.
5	CONFIGURE	Declarative IaC	Learn about the OCI IaC declarative approach and use the OCI Open LZ runtime configurations as your IaC templates. These configurations are easily adjustable to any other landing zone model.
6	RUN	One-OE Multi-OE	Run your configurations using Terraform CLI or Oracle Resource Manager (ORM) as described in the blueprint runtimes documentation.
7	EXTEND	Workload Extensions	Extend your Landing Zone wit ready-made pluggable workload extensions to reduce your time-to-production with OCI best practices.

 

License

Copyright (c) 2024 Oracle and/or its affiliates.

Licensed under the Universal Permissive License (UPL), Version 1.0.

See LICENSE for more details.

terraform-oci-open-lz's Issues

network_security_groups created through inject_into_existing_vcns have autogenerated names

network_security_groups created through inject_into_existing_vcns have autogenerated names - the attribute display_name seems to be ignored.

Cannot create IPSec tunnels phases configuration details

IPSec tunnels can be created but we're missing the key configuration parameter to be able to create the working tunnels as the phases details.

Needs to be reviewed and fixed.

Optional input file

Run the Configurations step has given command as

terraform plan
-var-file ../examples/oci-open-lz/shared/oci-credentials.tfvars.json
-var-file ../examples/oci-open-lz/shared/open_lz_shared_identity.auto.tfvars.json
-var-file ../examples/oci-open-lz/shared/open_lz_shared_network.auto.tfvars.json
-state ../examples/oci-open-lz/shared/terraform.tfstate

but if we don't want to use any component from network side, we should have option not to pass that command line argument.

Need a way to be able to ignore the changes in Oracle-Tags namespace

While not modifying any defined_tags in any resource (default null), with any plan/apply operation the orchestrator will try (not effectively change) the Oracle-Tags.CreatedBy and Oracle-Tags.CreatedOn to null values. These tags will be reset to the inherited values at creation time, as they get their values from the default tenancy-wide Oracle Tags namespace.

Different parties desire a way to ignore the changes on these tags.

This best solution so far is to configure the provider with the option:

provider "oci" {
region = var.home_region
tenancy_ocid = var.tenancy_ocid
user_ocid = var.user_ocid
fingerprint = var.fingerprint
private_key_path = var.private_key_path
private_key_password = var.private_key_password
ignore_defined_tags = ["Oracle-Tags.CreatedBy", "Oracle-Tags.CreatedOn"] <---------
}

region Vs home_region

oci-credentials.tfvars.json.template has two parameters "region" and "home_region" but usecase associated with them is not mentioned and not clear which one to use. Better we add detail in "Setup Terraform Authentication" section.

examples/shared should have a reference to LBaaS certificates creation

The provided example creates a LB with a certificate that has a reference to pre-existing local certificates folder:

                        "certificates": {
                            "LB-SHARED-CERT-1-KEY": {
                                "ca_certificate": "~/certs/ca.crt",
                                "certificate_name": "lb1-cert1",
                                "private_key": "~/certs/my_cert.key",
                                "public_certificate": "~/certs/my_cert.crt"
                            }
                        },

We should indicate the need to have valid PEM certificates for the Load Balancer. For educational purposes, and if the user has not trusted CA certificates we can point to a public reference with instructions on how to setup self-signed certificates in the shared MD documentation or a link to a secondary MD with some instructions like:

	a. Create a Self-Signed Root CA:
	openssl req -x509 -sha256 -days 1825 -newkey rsa:2048 -keyout ca.key -out ca.crt
	
	b. Create a cert key and certificate signing request (CSR):
	openssl req -nekey rsa:2048 -nodes -keyout my_cert.key -out my_cert.csr
	
	c. Sign the certificate CSR with Root CA:
	cat my_cert.txt
	authorityKeyIdentifier=keyid,issuer 
	basicConstraints=CA:FALSE 
	subjectAltName = @alt_names [alt_names] 
	DNS.1 = oe01.com
	
	openssl x509 -req -CA ca.crt -CAkey ca.key -in my_cert.csr -out my_cert.crt -days 365 -CAcreateserial -extfile my_cert.txt
	
	d. Check the cert:
	openssl x509 -text -noout -in my_cert.crt

Unknown type 'IPSEC_TUNNEL' while creating a DRT Attachment of type IPSEC_TUNNEL

While creating an IPSEC_TUNNEL DRG attachment type and configuring in the network_details the type as IPSEC_TUNNEL, we got an error on apply operation with "Error: unknown type 'IPSEC_TUNNEL' was specified.

Is something different is specified in the type argument we got an error like: "Error: expected network_details.0.type to be one of [IPSEC_TUNNEL LOOPBACK REMOTE_PEERING_CONNECTION VCN].

Issue creating compartments from examples/oci-open-lz/shared/open_lz_shared_identity.auto.tfvars.json

When running the module I am seeing the following:

$ terraform plan -var-file ./oci-credentials.tfvars.json -var-file ../examples/oci-open-lz/shared/open_lz_shared_identity.auto.tfvars.json -var-file ../examples/oci-open-lz/shared/open_lz_shared_network.auto.tfvars.json -state ../examples/oci-open-lz/shared/terraform.tfstate

Error: Invalid value for input variable
│
│ on identity.tf line 9, in module "cislz_compartments":
│ 9: compartments_configuration = var.compartments_configuration
│
│ The given value is not suitable for
│ module.cislz_compartments.var.compartments_configuration declared at
│ ....\terraform-oci-cis-landing-zone-iam\compartments\variables.tf:12,1-38:
│ attribute "compartments": incorrect map element type: attribute "children":
│ incorrect map element type: attribute "children": incorrect map element
│ type: attribute "tag_defaults": incorrect map element type: attribute
│ "tag_id" is required.

Defining explicit default_security_list expects to define display_name

When defining explicitly a default_security_list in a VCN (to have the absolute control of the entries on it with the JSON config), it is expecting a display_name, not defined in the variables.tf of the orchestrator:

Error:

Error: Unsupported attribute
│ 
│   on networking.tf line 42, in locals:
│   42:               display_name   = vcn_value.default_security_list.display_name
│     ├────────────────
│     │ vcn_value.default_security_list is object with 6 attributes
│ 
│ This object does not have an attribute named "display_name".
╵

orchestrator variables.tf:
    
default_security_list = optional(object({
          compartment_id  = optional(string),
          compartment_key = optional(string),
          defined_tags    = optional(map(string)),
          freeform_tags   = optional(map(string)),
          ingress_rules = optional(list(object({

fix with:
    
        default_security_list = optional(object({
          compartment_id  = optional(string),
          compartment_key = optional(string),
          defined_tags    = optional(map(string)),
          freeform_tags   = optional(map(string)),
          **_display_name    = optional(string),_**

typo for variables user_ocid & tenancy_ocid

file https://github.com/oracle-quickstart/terraform-oci-open-lz/tree/master/examples/oci-open-lz/shared/oci-credentials.tfvars.json.template

Has this content:

tenancy_id should be tenancy_ocid
and
user_id should be user_ocid

Regards,

Error: Iteration over null value

Terraform plan for /examples/oci-open-lz/op01_manage_shared_services example giving below error:

Error: Iteration over null value
│
│ on .terraform/modules/cislz_groups/groups/main.tf line 24, in locals:
│ 24: users = { for u in data.oci_identity_users.these.users : u.name => u }
│ ├────────────────
│ │ data.oci_identity_users.these.users is null
│
│ A null value cannot be used as the collection in a 'for' expression.

Open LZ v1.3.0 can not create compartments in enclosing compartments

Error in orchestrator coming from the update to the IAM core module v0.1.6/comparments as this version changed the default_parent_ocid and parent_ocid for default_parent_id and parent_id and this was not changed in the orchestrator.

To modify files:

variables.tf:

variable "compartments_configuration" {
description = "The compartments configuration. Use the compartments attribute to define your topology. OCI supports compartment hierarchies up to six levels."
type = object({
derive_keys_from_hierarchy = optional(bool) # Whether identifying keys should be derived from the provided compartments hierarchy
module_name = optional(string) # The module name.
tags_dependency = optional(map(any)) # Map of objects containing the externally managed tags this module may depend on. All map objects must have the same type and must contain at least an 'id' attribute (representing the tag OCID) of string type.
default_parent_ocid = optional(string) # the default parent for all top (first level) compartments. Use parent_ocid attribute within each compartment to specify different parents.
default_defined_tags = optional(map(string)) # applies to all compartments, unless overriden by defined_tags in a compartment object
default_freeform_tags = optional(map(string)) # applies to all compartments, unless overriden by freeform_tags in a compartment object
enable_delete = optional(bool) # whether or not compartments are physically deleted when destroyed. Default is false.
compartments = map(object({
name = string
description = string
parent_ocid = optional(string)

For:

variable "compartments_configuration" {
description = "The compartments configuration. Use the compartments attribute to define your topology. OCI supports compartment hierarchies up to six levels."
type = object({
derive_keys_from_hierarchy = optional(bool) # Whether identifying keys should be derived from the provided compartments hierarchy
module_name = optional(string) # The module name.
tags_dependency = optional(map(any)) # Map of objects containing the externally managed tags this module may depend on. All map objects must have the same type and must contain at least an 'id' attribute (representing the tag OCID) of string type.
default_parent_id = optional(string) # the default parent for all top (first level) compartments. Use parent_ocid attribute within each compartment to specify different parents.
default_defined_tags = optional(map(string)) # applies to all compartments, unless overriden by defined_tags in a compartment object
default_freeform_tags = optional(map(string)) # applies to all compartments, unless overriden by freeform_tags in a compartment object
enable_delete = optional(bool) # whether or not compartments are physically deleted when destroyed. Default is false.
compartments = map(object({
name = string
description = string
parent_id = optional(string)

Configuration needs to use this default_parent_id & parent_id accordingly.