X

Best Practices from Oracle Development's A‑Team

Tenancy Pre Configuration For Deploying CIS OCI Landing Zone as a non-Administrator

Andre Correa Neto
Cloud Solutions Architect

Introduction

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 pre-config Module

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.

Environment Settings

  • home_region: the tenancy home region, where the resources are deployed.
  • unique_prefix: if provided, a prefix is added to all resource names created by the module, except for compartment names if enclosing_compartment_names are specified.

Compartments Settings

The enclosing compartments behavior is controlled by the following variables:

  • enclosing_compartment_names: the names of the enclosing compartments that will be created to hold Landing Zone compartments. If not provided, one compartment is created with a default name ending in 'top-cmp'. You can specify up to five enclosing compartments.
  • existing_enclosing_compartments_parent_ocid: the enclosing compartments parent compartment OCID, defining where enclosing compartments are created. If not provided, the enclosing compartments are created in the Root compartment. Later on, you can safely change this value to another compartment OCID and rerun the module. The enclosing compartments will be moved accordingly.

Groups Settings

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:

  • use_existing_provisioning_group: Whether an existing group will be used for Landing Zone provisioning. If false, one group is created for each compartment defined by enclosing_compartment_names variable.
  • existing_provisioning_group_name: The name of an existing group to be used for provisioning all resources in the compartments defined by enclosing_compartment_names variable. Ignored if use_existing_provisioning_group is false.
  • use_existing_groups: Whether existing groups are to be reused for managing the Landing Zone. If false, one set of groups is created for each compartment defined by enclosing_compartment_names variable. If checked, existing group names must be provided and this single set will be able to manage resources in all those compartments.
  • existing_iam_admin_group_name: the existing group to manage IAM resources.
  • existing_cred_admin_group_name: the existing group to manage IAM credentials.
  • existing_security_admin_group_name: the existing group to manage security resources.
  • existing_network_admin_group_name: the existing group to manage network resources.
  • existing_appdev_admin_group_name: the existing group to manage application development related resources.
  • existing_database_admin_group_name: the existing group to manage database resources.
  • existing_auditor_group_name: the existing group to audit the tenancy.
  • existing_announcement_reader_group_name: the existing group to read announcements in the tenancy.

Policies Settings

There is also an option for determining services policy creation behavior:

  • grant_services_policies: Whether services policies should be granted. If these policies already exist in the root compartment, set it to false for avoiding policies duplication. Useful if the module is reused across distinct stacks or configurations.

 

Deploying the pre-config Module

Two deployment use cases are addressed in this section for exemplification.

Using Terraform CLI

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"
user_ocid = "ocid1.user.oc1..aaaaaaaa1111111111bbbbbbbbbb2222222ccccccc3333333333a"
fingerprint = "c1:19:41:11:65:aa:68:bb:2e:33:80:dd:36:44:54:i9"
private_key_path = "../private_key.pem"
private_key_password = ""
home_region = "us-ashburn-1"
unique_prefix = "cislz"

 

Using OCI Resource Manager

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.

To use the pre-config module, make sure to choose the pre-config folder in the Working Directory dropdown box  when creating the Resource Manager Stack.

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.

Next Steps

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.

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha