OCI IAM and compartments: an access structure you can audit

An Oracle Cloud Infrastructure (OCI) tenancy usually starts with a few resources and grows to host applications from different teams, external vendors and production environments. If each resource stays where its first administrator created it, authorizations end up depending on exceptions that are hard to review.

The goal of this article is a structure in which anyone on the team can explain who manages each set of resources and why they have access. It proposes criteria for OCI IAM with identity domains and indicates, at each point, where to verify the service rules.

Identity, resources and network: three separate domains

A compartment organizes resources and is the scope to which access policies apply. According to the compartments documentation, they span the whole tenancy and are available in every subscribed region. A compartment named «Production» neither selects a region nor controls traffic.

An identity domain manages a population of users and their identity configuration, including federation, sign-in and security policies. The identity domains section describes the default domain and the use of additional ones. Creating several is only justified by a real need to separate users or administration.

Network segmentation, finally, is defined in VCNs, subnets and security rules. Separating resources into compartments organizes responsibilities but does not restrict connections between applications. An IAM review does not replace a connectivity review.

Compartments by responsibility

The design starts from an inventory of workloads, environments and owners. One possible structure distinguishes Platform, Production and NonProduction, with per-application compartments when there are different teams or permissions. It is a proposal to be adjusted to each organization's dependencies and to who approves changes.

The criterion for creating a compartment is a concrete administration or access need that is clearer when separated. A branch per resource or per person has the opposite effect. If two sets share owner, permissions and lifecycle, a single location usually requires fewer exceptions.

Shared services deserve special attention. A central network may depend on a team different from the one deploying applications, which requires defining the permissions each side needs to consume it. Documenting those dependencies before writing policies avoids the habitual fix of granting general administration for every permissions error.

The IAM security structure guidance in Oracle's adoption framework recommends separating production and non-production workloads and keeping the structure manageable. That guidance is a good starting point, provided exceptions are recorded. A small team needs rules it can sustain when one of its members is away.

Task-based policies

A policy describes four elements: the authorized principal, the access level, the resources and the scope. The introduction to IAM policies explains them and notes that some operations require permissions on several resource types. Approving a task therefore means reviewing its dependencies as well as the main resource.

We recommend forming groups by task (operating an application, administering the network) rather than by job title. For each group, the actions and resources involved are written down first, and only then are permissions chosen from the service reference. A group's name restricts nothing: effective access is determined by policies.

In tenancies with domains, groups are identified by domain and name, according to the subject syntax, which also documents the behavior of the default domain. Keeping the domain explicit in internal documentation avoids confusion between groups with similar names.

Tenancy administration is reserved for the functions that need it. When an operation fails, the right procedure is to identify the missing permission, not to extend the group to all resources. Each authorization should be linked to the task that motivated it and to whoever approved it, so its validity can be reviewed.

Inheritance and delegation

Child compartments inherit the authorizations of their parents. A broad grant on a higher branch reaches any application added later, as the documentation on policy inheritance explains. Before assuming a new branch has limited access, the policies of its ancestors must be reviewed.

Where a policy is attached also matters, because it determines who can modify or delete it. Management may belong to the central team or to each compartment owner; in either case, delegating policy administration requires a specific review, because it allows changing other people's access rules.

A useful tool is a matrix with groups in rows and tasks in columns. With a representative account from each group, one authorized operation and one that must fall outside its scope are tested, in production and non-production. A test performed only with an administrator hides both missing and excessive permissions.

Automation identities

An application that calls OCI APIs needs its own operational identity. Dynamic groups group resources through matching rules, and policies grant them access to services. Their membership changes as resources matching the rule appear or disappear.

That property has a consequence: if the rule includes every instance in a compartment, any future matching instance gets the same access. The scope of the rule should be reviewed together with who can create resources in that location and whether they all really need the same capabilities.

For each integration, it is worth recording the resource that makes the calls, the target service, the required access and the authentication mechanism that service supports. This separates deployment permissions from those the application needs at run time.

Periodic review and evidence

Moving resources between compartments requires reviewing dependencies and permissions: the destination's policies start to apply and some dependencies behave differently depending on the service. Oracle details the implications of moving resources, which should be consulted before reorganizing an existing workload.

The structure is considered ready when each item in the following list has an owner and evidence of verification. The same review can be built into onboarding new applications and into staff changes.

• Each compartment has an identified owner and environment.
• Groups and their authorizations are reviewed across the whole chain of parent compartments.
• It is documented who can modify policies and dynamic group rules.
• Allowed tasks and accesses that must be denied are tested.
• Dependencies are documented before moving resources or changing owners.

OCI Audit records calls to supported public endpoints and allows querying events to investigate activity; its scope and exceptions are in the official documentation. The available evidence should be verified per service, and the review of relevant changes needs an assigned owner.

Xterra Engine designs OCI compartment and policy structures, and delivers them with their permissions matrix tested.