# Oci Landing Zone Setup > > - **Type:** Skill - **Install:** `agentstack add skill-selvarajmurugesan90-ops-engineering-skills-oci-landing-zone-setup` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [selvarajmurugesan90](https://agentstack.voostack.com/s/selvarajmurugesan90) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [selvarajmurugesan90](https://github.com/selvarajmurugesan90) - **Source:** https://github.com/selvarajmurugesan90/ops-engineering-skills/tree/main/plugins/cloud/skills/oci-landing-zone-setup ## Install ```sh agentstack add skill-selvarajmurugesan90-ops-engineering-skills-oci-landing-zone-setup ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # OCI Landing Zone Setup ## Purpose OCI has no separate-account model like AWS or GCP-project model — a single **tenancy** is the entire organization, and everything inside it is organized by **Compartments**, a hierarchical logical container that is simultaneously the OU-equivalent grouping construct *and* the place resources actually live. Get the compartment design wrong and every workload ends up flat in the root compartment with IAM policies that can't be scoped cleanly, no separation between security tooling and application resources, and no way to delegate administration without granting tenancy-wide access. This skill defines a landing zone aligned to Oracle's **CIS OCI Landing Zone** reference architecture: a compartment hierarchy that encodes environment/function boundaries, IAM policies written in OCI's plain-language policy grammar and scoped per compartment, Identity Domains for identity isolation, Cloud Guard and Security Zones for guardrail enforcement, and a hub network built on the Dynamic Routing Gateway (DRG) — so new workloads land compliant and network-connected from the first `terraform apply`. ## When to use - Standing up a brand-new OCI tenancy or bringing an ungoverned "everything in the root compartment" tenancy under proper compartment governance. - Designing the compartment hierarchy and deciding which IAM policies, Cloud Guard targets, and Security Zone recipes apply at which compartment level. - Onboarding a new team, product, or environment as an OCI compartment. - Implementing or migrating to Oracle's CIS OCI Landing Zone Terraform reference architecture instead of hand-rolled, console-managed compartments and policies. - Setting up Identity Domains for isolated identity realms (e.g. a separate domain for external partner or B2C access) rather than overloading the default domain. - Auditing an existing tenancy for compartment drift, over-broad policies attached at the tenancy (root) level, or resources sitting directly in a parent compartment instead of a purpose-built leaf compartment. - Explaining how OCI's tenancy/compartment/Identity Domain model maps to (and differs from) AWS Organizations/OUs, Azure Management Groups/subscriptions, or GCP folders/projects. ## Prerequisites & environment - An OCI tenancy already provisioned, with **Administrators** group membership (or a narrower delegated-admin policy) for whoever runs the initial compartment/policy bootstrap. - Know that the tenancy's **home region is permanent** — chosen at sign-up and never changeable — while additional regions are opt-in via `oci iam region-subscription create`. Decide the home region and the initial subscribed-region set before building anything region-specific (Vault keys, Identity Domains, and some other resources have region affinity). - OCI CLI ≥ 3.40 and Terraform ≥ 1.5 with the `oci` provider ≥ 5.x if using infrastructure as code — pin the provider version, since Identity Domain resources changed materially between provider 4.x and 5.x generations. - Decide up front: Oracle's open-source **CIS OCI Landing Zone** Terraform reference architecture (opinionated, aligned to the CIS OCI Foundations Benchmark, fastest path to a compliant baseline) vs. a fully custom compartment/policy Terraform module for teams with unusual compartment topology needs. - Decide the **Identity Domain strategy**: the tenancy ships with one default Identity Domain; only create additional domains when you need a genuinely isolated identity realm (e.g. external partners, a sandbox for testing IAM changes safely) — each extra domain is a separate user/group namespace with its own licensing tier (`free`, `premium`, `oracle-apps-premium`, `external-user`). - A budget for FastConnect (dedicated interconnect) provisioning lead time if hybrid connectivity to on-premises or another cloud is in scope — unlike a VPN, a physical circuit has a multi-week turnaround. ## Step-by-step guidance 1. **Design the compartment hierarchy before creating any resource.** A defensible starting structure, modeled on the CIS OCI Landing Zone: ``` Tenancy (root compartment) ├── Security │ ├── (Cloud Guard, Vault, centralized Object Storage log archive) ├── Network │ ├── (DRG hub, hub VCN, FastConnect/Site-to-Site VPN) ├── Workloads │ ├── Production │ │ ├── payments-prod │ │ └── checkout-prod │ └── NonProduction │ ├── payments-dev │ └── checkout-staging └── Sandbox └── individual developer compartments ``` Unlike an AWS OU (which only ever contains accounts) or a GCP folder (which only contains projects), an OCI compartment can hold **both** sub-compartments **and** resources directly — put actual workload resources only in leaf compartments (`checkout-prod`, not `Workloads` or `Production`), or IAM policies scoped to the leaf become unenforceable because resources leak into the parent. 2. **Create the compartment hierarchy** with Terraform: ```hcl resource "oci_identity_compartment" "network" { compartment_id = var.tenancy_ocid name = "Network" description = "Hub networking resources" enable_delete = false } resource "oci_identity_compartment" "workloads_prod" { compartment_id = oci_identity_compartment.workloads.id name = "Production" description = "Production workload compartments" } resource "oci_identity_compartment" "checkout_prod" { compartment_id = oci_identity_compartment.workloads_prod.id name = "checkout-prod" description = "checkout-prod workload" } ``` Or via CLI for a quick bootstrap: ```bash oci iam compartment create \ --compartment-id \ --name Network \ --description "Hub networking resources" ``` 3. **Write IAM policies scoped to compartments**, using OCI's plain-language policy grammar (`Allow to in compartment `), referencing nested compartments with a colon-separated path: ```hcl resource "oci_identity_policy" "network_admins" { compartment_id = var.tenancy_ocid name = "network-admins-policy" description = "Network team manages networking resources" statements = [ "Allow group NetworkAdmins to manage virtual-network-family in compartment Network", "Allow group NetworkAdmins to manage virtual-network-family in compartment Workloads:Production:checkout-prod", ] } resource "oci_identity_policy" "checkout_team_delegated_admin" { compartment_id = oci_identity_compartment.checkout_prod.id name = "checkout-team-admin-policy" description = "Delegate self-service admin within the leaf compartment only" statements = [ "Allow group CheckoutTeam to manage all-resources in compartment checkout-prod", ] } ``` The four policy verbs (`inspect` \ --display-name "audit-log-archive" \ --source '{"kind":"logging","logSources":[{"compartmentId":"","logGroupId":"_Audit_Include_Subcompartment"}]}' \ --target '{"kind":"objectStorage","namespace":"","bucketName":"security-audit-logs"}' ``` 8. **Enable Cloud Guard tenancy-wide and layer Security Zones on production compartments.** Cloud Guard is OCI's detective posture service (the rough analog of AWS GuardDuty + Security Hub, or Azure Defender for Cloud / GCP Security Command Center): ```bash oci cloud-guard configuration update \ --compartment-id \ --reporting-region us-ashburn-1 \ --status ENABLED \ --self-manage-resources false ``` Security Zones go further than Cloud Guard's detect-and-alert model — attaching a Security Zone recipe to `Workloads:Production` **blocks** the non-compliant API call itself (e.g. creating a public Object Storage bucket, or a boot volume without encryption) rather than only flagging it after the fact, closer to an SCP/Org Policy hard guardrail than a Config rule. 9. **Set compartment-scoped budgets** so a runaway Sandbox workload alerts before it becomes a cost surprise: ```bash oci budgets budget create \ --compartment-id \ --target-compartment-id \ --amount 5000 \ --reset-period MONTHLY \ --display-name "sandbox-monthly-budget" ``` 10. **Validate with a canary compartment.** Vend one throwaway leaf compartment through the full pipeline, confirm the delegated-admin policy, Dynamic Group, Security Zone enforcement, and centralized logging all behave as expected, then delete it before opening the pipeline to real workload teams. ## Best practices - Never put workload resources directly in `Workloads`, `Production`, or any non-leaf compartment — reserve non-leaf compartments purely for grouping and policy inheritance, exactly the discipline the AWS/Azure/ GCP landing-zone skills apply to OUs/Management Groups/folders. - Grant the **narrowest policy verb** (`inspect`/`read`/`use` before reaching for `manage`) and scope every statement to a specific compartment path — avoid `manage all-resources in tenancy`, the OCI equivalent of `AdministratorAccess`/`Owner`/`roles/owner`. - Prefer **Dynamic Groups + instance/resource principal authentication** over embedding API signing keys in workload configuration — this is OCI's version of eliminating long-lived credentials (see `cloud-iam-hardening`). - Keep the **default Identity Domain for internal workforce identities** and create additional Identity Domains only for genuinely isolated populations (external partners, a B2C customer-facing app) — extra domains are a real isolation boundary, not a free organizational nicety. - Treat **Security Zones as the primary preventive guardrail** for production compartments and **Cloud Guard as the detective layer** everywhere else — they're complementary, not substitutes for one another. - Version the compartment/policy/network Terraform in Git and run the canary-compartment validation in CI before merging changes that touch shared policy statements. - Budget-alert every compartment, not just Sandbox — production compartments benefit from anomaly detection just as much, just tuned to a higher threshold. ## Common pitfalls - **Symptom:** A policy statement referencing `in compartment Production` grants access far more broadly than intended, or a policy written for a leaf compartment silently does nothing. **Fix:** Nested compartments must be referenced by their full colon-separated path (`Workloads:Production:checkout-prod`), not just the leaf name, once there's ambiguity across the hierarchy — or, conversely, granting `manage ... in compartment Production` also applies to every sub-compartment beneath it (including `NonProduction` siblings if the hierarchy was flattened incorrectly). Confirm the actual compartment path with `oci iam compartment list --compartment-id-in-subtree true` before trusting a policy's scope. - **Symptom:** A policy statement referencing a group in a non-default Identity Domain (e.g. an isolated `Partners` domain) fails to grant access, even though the group clearly exists. **Fix:** Groups outside the default Identity Domain must be qualified with the domain name in policy statements — `Allow group Partners/PartnerViewers to read object-family in compartment Shared`, not just `Allow group PartnerViewers to ...`. Forgetting the domain prefix is the single most common OCI multi-domain policy authoring mistake. - **Symptom:** Resources keep appearing directly in the `Production` or `Workloads` compartment instead of a team's leaf compartment, and the team's delegated-admin policy doesn't apply to them. **Fix:** Because OCI compartments can hold resources at every level of the hierarchy (unlike an AWS OU or GCP folder), nothing stops an engineer from creating a resource one level too high. Enforce leaf-only resource placement with a Security Zone recipe requiring resources to live in a tagged "leaf" compartment, and periodically audit with `oci search resource structured-search` for resources sitting in non-leaf compartments. - **Symptom:** A Terraform apply that provisions Vault keys or an Identity Domain in a newly subscribed region fails or behaves inconsistently with the home region's equivalent resource. **Fix:** Some resources (Vault master encryption keys, Identity Domains) have region affinity and don't automatically replicate to newly subscribed regions the way compartments and policies (which are tenancy-wide) do. Explicitly provision the region-scoped resource in each subscribed region rather than assuming it inherits from the home region. - **Symptom:** A Dynamic Group's matching rule stops granting access after a compute instance is moved to a different compartment as part of a reorg. **Fix:** Dynamic Group matching rules keyed on `instance.compartment.id` are evaluated live — moving the instance changes which dynamic groups it matches, silently revoking (or granting) access. Prefer matching on a stable freeform/defined tag (`instance.tag.namespace.key = 'value'`) over compartment ID when instances are expected to move between compartments during their lifecycle. ## Worked example **Scenario:** A company with one flat OCI tenancy (all resources sitting in the root compartment, one shared Administrators-group login for everyone) needs a real landing zone before launching a second product line and before OCI resources fail their first security audit. 1. Create the compartment hierarchy: `Security`, `Network`, `Workloads` (with `Production`/`NonProduction`), and `Sandbox`, all under the tenancy root, using the Terraform module shown above. 2. Migrate the existing legacy application's resources into `Workloads:Production:legacy-app` via compartment move operations (`oci iam compartment ... ` resource moves are per-resource-type; plan this as a tracked migration, not a bulk operation). 3. Enable Cloud Guard tenancy-wide and attach a Security Zone recipe to `Workloads:Production` blocking public bucket creation and unencrypted boot volumes. 4. Stand up the hub VCN and DRG in `Network`, with FastConnect ordered for the primary on-premises connection and a Site-to-Site VPN configured as immediate failover while the physical circuit provisions. 5. Create `Workloads:Production:checkout-prod` and `Workloads:NonProduction:checkout-staging` for the new product line, each with a DRG attachment to the hub, a delegated-admin policy scoped to `CheckoutTeam`, and a Dynamic Group granting the compartment's compute instances read access to Vault secrets in `Security` — no embedded API keys anywhere in the deployment. 6. Route Audit and VCN Flow Logs through a Service Connector Hub into an Object Storage bucket in `Security` with a retention rule, and set a compartment-scoped budget on `Sandbox`. 7. Result: two product lines, a compliant compartment hierarchy, Security Zone guardrails enforced (not just monitored) on production, and zero long-lived API keys in the new workload's deployment path. ## Cross-references - [aws-landing-zone-setup](../aws-landing-zone-setup/SKILL.md) - [azure-landing-zone-setup](../azure-landing-zone-setup/SKILL.md) - [gcp-landing-zone-setup](../gcp-landing-zone-setup/SKILL.md) - [cloud-iam-hardening](../cloud-iam-hardening/SKILL.md) ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [selvarajmurugesan90](https://github.com/selvarajmurugesan90) - **Source:** [selvarajmurugesan90/ops-engineering-skills](https://github.com/selvarajmurugesan90/ops-engineering-skills) - **License:** Apache-2.0 Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-selvarajmurugesan90-ops-engineering-skills-oci-landing-zone-setup - Seller: https://agentstack.voostack.com/s/selvarajmurugesan90 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.