Least-privilege IAM policies for workloads (compartment-first)

Problem

IAM policies tend to grow the same way: someone is blocked, someone writes a broad statement to unblock them, and that statement lives forever. Tenancy-wide grants and "manage all-resources" lines are the usual result, and they are hard to walk back once other things depend on them.

I wanted a default that is easy to follow under time pressure. Scope every statement to a compartment, name the resource family, and pick the verb that matches the job.

Options and trade-offs

• Tenancy-level policies: quick to write and a large blast radius. I keep them for a few shared administrative duties with tightly limited verbs.
• Compartment-first policies: they line up with ownership and cost boundaries. The price is that you need a compartment structure and consistent names.
• Conditional policies: precise, using where clauses on bucket, secret or operation. They also need documentation and testing, or they turn into puzzles.

My recommendation

Start in the compartment that owns the workload. OCI's verbs run from inspect to read to use to manage, so give runtime principals read or use and keep manage for operators. Prefer resource families such as instance-family or object-family over all-resources, and review the policy set on a schedule so it does not drift.

Worked example

Here is the shape I aim for with an application compartment called apps. Runtime access is narrow, and the platform team gets a separate, more powerful statement.

# Runtime: what the app itself needs
Allow dynamic-group app-runtimes to read objects in compartment apps
  where target.bucket.name = 'app-config'
Allow dynamic-group app-runtimes to use log-content in compartment apps
 
# Operators: separate group, separate statements
Allow group platform-admins to manage instance-family in compartment apps
Allow group platform-admins to read policies in compartment apps

Compare that with what usually shows up in a review:

Allow group developers to manage all-resources in tenancy

The second line is shorter and works on day one, which is why it keeps appearing. It is also impossible to explain to an auditor. When delegating to a sub-team, use a compartment path such as A:B so the grant follows the hierarchy.

Be careful with the ability to manage policies. Whoever can manage policies in a compartment can usually grant themselves more, so I keep that permission with a very small group.

Checklist

1. Use read or use for runtime principals, and keep manage for people who operate the service.
2. Scope by compartment, and by compartment path when delegating.
3. Write one purpose per statement, and add a short comment on who, what and why.
4. Use resource families instead of all-resources.
5. Put a condition on the statements that touch sensitive buckets or secrets.
6. Review grants on a schedule and remove the stale ones.

Where this doesn't apply

Incident response across many compartments is a case where a temporary tenancy-level grant is sensible. Time-box it, write down who approved it, and delete it when the incident closes.

One honest limitation

Narrow policies mean more statements, and more statements need maintenance. A naming convention and a template for new compartments, set up early, keep that from becoming the bottleneck.

Sources

• OCI Documentation: Policy Syntax
• OCI Documentation: Policy Reference (verbs and resource families)
• OCI Documentation: Managing Compartments