OCI policies read like English, which is why they are easy to get dangerously wrong

allow group Developers to manage all-resources in compartment dev is a sentence anyone can read, and that readability is one of OCI's best design decisions. It is also why OCI tenancies accumulate over-broad policies faster than clouds with verbose JSON: nobody feels the weight of what they just granted.

Understand what the verbs mean

OCI has four verbs, and they are cumulative:

• inspect — list resources. Note that for some resource types this includes metadata you may consider sensitive.
• read — inspect plus retrieve the contents. For a vault secret, read means reading the secret.
• use — read plus work with existing resources, but not create or delete. For most resource types this is the useful middle ground.
• manage — everything, including delete.

The mistake is reaching for manage when use was meant. A group that operates a service needs use; a group that provisions it needs manage. Splitting those two is the single largest reduction in blast radius available in an OCI tenancy.

Aggregate resource types (instance-family, virtual-network-family, database-family) are convenient and broad. all-resources should appear only in the Administrators policy, and ideally not even there.

Dynamic groups: the way workloads authenticate without credentials

A dynamic group is a rule that matches resources rather than users:

ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaa'}

Instances, functions, autonomous databases and other resource principals that match the rule can then be granted permissions directly. The workload calls the API and authenticates as itself — no API signing key, no key file on disk, no rotation.

Two rules for writing them:

Match on the narrowest attribute available. A dynamic group matching every instance in the tenancy, granted manage objects, means any compromised VM can read and delete every bucket. Match on compartment plus a defined tag, so membership is intentional rather than incidental.

Write the policy against the dynamic group with a where clause. allow dynamic-group app-servers to manage objects in compartment data where target.bucket.name = 'uploads' is defensible. Without the clause you granted the whole compartment.

Every API signing key in a config file is a candidate for replacement. As on other clouds, the long-lived key is the credential that leaks — the same argument as GCP service account keys, and the same fix.

Conditions, which most tenancies never use

OCI policy supports where clauses on a rich set of variables, and they are underused:

• where request.region = 'eu-madrid-1' — pin a group's authority to one region.
• where target.resource.tag.Ops.Environment = 'test' — tag-based scoping, so a developer group can manage anything tagged test in production compartments without touching production resources.
• where request.user.mfaTotpVerified = 'true' — require MFA for the operation. This is the one worth applying to every administrative policy.
• where request.permission = '...' — exclude specific destructive permissions from an otherwise broad grant.

The findings that repeat in OCI reviews

• manage all-resources in the tenancy granted to more than the Administrators group. Frequently to a CI group, because it was easier than enumerating.
• API signing keys for users, especially for a shared "automation" user. A user with an API key and broad policy is an account without MFA, and it is usually the weakest point in the tenancy.
• Dynamic groups matching a whole compartment with manage on a family.
• Policies written at the root compartment that were meant for one workload, granting tenancy-wide authority as a side effect.
• Public buckets. Object Storage buckets default to private, but pre-authenticated requests are easy to create, long-lived and transferable. Audit them: they are OCI's equivalent of a presigned URL left in a Slack thread, and the same S3 lessons apply.

Verify rather than assume

The OCI policy simulator and oci iam policy list across compartments let you answer "what can this group actually do" without guessing. Run it for your three most privileged groups and read the combined result — inheritance means the answer is often broader than any single policy suggests.

Also enable audit logging to a dedicated compartment with retention, and Cloud Guard with the OCI CIS benchmark recipe, which flags most of the findings above automatically. We run this pass as part of a security assessment.

What to do this week

List every policy statement containing manage all-resources or manage on a -family at the tenancy root. For each, ask whether use would do and whether the compartment could be narrower. That review is an afternoon and it typically removes most of the excess authority in a tenancy.