Released on July/2021, CIS OCI Landing Zone V2 expands V1 capabilities quite significantly. One of the new features is the ability for a user that does not have broad permissions in the tenancy to provision the Landing Zone.
Tenancy administrators sometimes do not feel comfortable granting broad permissions for policies, groups and compartments creation in the tenancy. This is especially prevalent in proof of concepts type of scenarios.
In V1, the Landing Zone required a user with broad permissions in the tenancy in order to be provisioned. Typically, but not necessarily, this user was a member of the Administrators group. That has changed. Now with V2, the Landing Zone can be provisioned by a user with narrower permissions. However, some requirements need to be satisfied. Specifically, the Landing Zone requires policies and groups created at the Root compartment level and broad permissions at the compartment where it is going to be provisioned. For simplification purposes, this post uses the term "non-admin" for referring to a user with narrower permissions or one that does not have the permissions to broadly create resources at the Root compartment level.
While these requirements can be implemented by tenancy administrators on their own, Landing Zone v2 provides a helper Terraform root module, the pre-config module, that is expected to be executed by a user with broad permissions (typically a member of the Administrators group).
The diagram below depicts the resources that are provisioned by the pre-config module:
By design, deploying the Landing Zone as a "non-admin" requires an enclosing compartment, represented in dark gray color. The diagram shows a single Enclosing compartment directly in the Root compartment, but the module actually supports the creation of up to five compartments anywhere in the tenancy's compartments hierarchy. Five compartments is a soft limit enforced by the Terraform code and has no connection to OCI compartments limits. You can disable such enforcement by changing enclosing_compartment_names variable's validation condition in variables.tf file.
An enclosing compartment works as a placeholder for one or multiple Landing Zones. Although we typically see a single Landing Zone on each enclosing compartment, multiple Landing Zones is also an option if the same set of groups are going to be used for provisioning and managing the Landing Zones.
For each enclosing compartment, the module creates one Provisioning Group and one set of Management Groups by default, along with policies granting them the necessary permissions.
The Provisioning Group is granted broad permissions in the enclosing compartment (Provisioning Policy in green inside the Enclosing compartment) and the least necessary permissions in the Root compartment for provisioning Landing Zone's required resources (Provisioning Policy in green in the Root compartment).
Likewise, Management Groups are granted the least necessary permissions in the Root compartment for managing Landing Zone required resources (Mgmt Policy in yellow in the Root compartment). The Read-Only Policy grants the necessary inspect and read permissions (plus use on cloud-shell) on resources in the Root compartment. Again, these groups and policies are created for each enclosing compartment.
Additionally, one policy is created for the OCI services (Services Policy, in blue) required by the Landing Zone, namely Cloud Guard, Vulnerability Scanning and OS Management.
Users then assigned to the Provisioning Group will be able to provision Landing Zone resources in the Enclosing compartment and the few required resources in the Root compartment.
The following sections describe the settings available in the module.
The enclosing compartments behavior is controlled by the following variables:
Existing groups for provisioning and management can be reused, if so desired. In this case, the provided groups are used to provision and manage all Landing Zone enclosing compartments. To accomplish this, you can instruct the Terraform module using the following variables:
There is also an option for determining services policy creation behavior:
Two deployment use cases are addressed in this section for exemplification.
Deploying the pre-config module in such a way that:
1) One default enclosing compartment (name defaulted to cislz-top-cmp) is created in the Root compartment.
2) One group is created for further provisioning the Landing Zone in the enclosing compartment.
3) One set of groups is created for managing the Landing Zone.
This is the simplest deployment possible as no defaults need to be changed. Have your quickstart-input.tfvars or terraform.tfvars file like:tenancy_ocid = "ocid1.tenancy.oc1..aaaaaaaa1111111111bbbbbbbbbb2222222ccccccc3333333333q"
Deploying the pre-config module in such a way that:
1) Two enclosing compartments (dev an test) are created under a designated parent compartment (cis_landing_zone).
2) An existing group is reused for further provisioning the Landing Zones in each enclosing compartment.
3) The same existing set of groups is reused for managing each Landing Zone.
When configuring the variables, optionally enter a Unique Prefix. It gets prepended to all resource names, except to Enclosing Compartment Names that you specify.
Click the Show Advanced Options checkbox for overriding the module's default behavior.
In the Compartments section, enter two names for the enclosing compartments that you want to create (dev and test). Then pick the parent compartment by expanding the tree in the Enclosing Compartments Parent dropdown box.
In the Groups section, check both boxes and enter the existing group names for provisioning and managing the Landing Zones. These groups will be entitled to act on resources (according to their granted permissions) in the Landing Zones specified by Enclosing Compartment Names above. Leaving those boxes unchecked will make the module create one group for provisioning and one set of groups for managing each one of the Landing Zones specified by Enclosing Compartment Names.
Leave the Policies section intact, as we do want to grant services policies.
Once the tenancy is configured for Landing Zone provisioning, the next step is assigning users to the provisioning groups so they can create Landing Zone resources in their own enclosing compartments while leveraging all the infrastructure put in place by the pre-config module. Refer to Deployment Modes for CIS OCI Landing Zone for details.