On OCI, access is granted by writing policies, statements that allow a group to take certain actions on certain resources within a certain scope. Policies are precise and powerful, and that precision is exactly why they reward discipline and punish carelessness. A policy written too broadly grants more than anyone intended, and a sprawl of overlapping policies becomes impossible to reason about, which is its own security weakness because nobody can state with confidence what access actually exists.
The goal of writing policies well is a set that is least privilege, readable, and structured around compartments, so that the access in your estate maps cleanly onto how your resources are organised. This guide covers how to get there and, just as importantly, the mistakes that lead to the opposite: over permissioning and policy sprawl that quietly erode the security the policies were meant to provide.
How an OCI policy is built
A policy statement allows a group to perform a set of actions on a type of resource within a scope, usually a compartment. The shape is consistent: a subject, a verb describing how much they can do, a resource type, and the location it applies to. The verbs range from the ability to inspect, through the ability to read, up to the ability to use and to manage, and choosing the right verb is the heart of least privilege. Granting the ability to manage when the group only needs to read is the most common form of over permissioning, and it is easy to do because the broader verb always works.
Understanding this structure is what lets you grant narrowly. The discipline is to ask, for each grant, what is the least the group needs to do its job, and to choose the verb and resource type that express exactly that. A policy set built this way is not only more secure, it is more readable, because each statement says plainly what it permits and why.
Compartments are the structure policies hang on
Policies grant access within a scope, and that scope is usually a compartment. Compartments are how OCI organises resources, and a clear compartment design is what makes least privilege practical. When environments and workloads are separated into compartments, you can grant a group access to exactly the compartment it needs and no others, which contains access naturally. When everything sits in one flat compartment, fine grained access becomes far harder, because there is no boundary to grant against.
This is why policy design and compartment design go together. A good compartment structure, covered in the broader security writing, gives policies clean boundaries to work with, and policies written against those boundaries are easy to understand. Before writing many policies, it is worth getting the compartment design right, because policies built on a messy compartment structure inherit the mess. The identity side of this, the groups that policies grant to, is covered in our identity domains guide.
The common mistakes
| Mistake | Why it happens | The fix |
|---|---|---|
| Granting manage when read suffices | The broad verb always works, so it is the path of least resistance | Choose the least verb that does the job |
| Granting at the wrong scope | Granting at a broad scope to avoid thinking about boundaries | Grant at the narrowest compartment that works |
| Granting to individuals | It seems quicker than setting up a group | Grant to groups, manage through membership |
| Policy sprawl | New policies added without removing old ones | Review and consolidate, remove what is unused |
| Unreadable statements | Policies written without thought to who reads them later | Write each statement to be self explanatory |
Policy sprawl deserves particular attention because it grows quietly. Each individual policy may be reasonable, but as policies accumulate without anyone removing the ones no longer needed, the set becomes a thicket that nobody fully understands. An estate where no one can state with confidence what access exists is insecure regardless of how careful each individual grant was, because the gaps and overlaps hide in the volume. Regular review and consolidation is the antidote, and it is ongoing work rather than a one time cleanup.
Writing for the reader, not just the machine
A policy is read by people as well as enforced by the platform, and writing for the reader is a security practice in its own right. A policy set that a reviewer can understand at a glance is one whose mistakes get caught, while a set that is dense and unstructured hides its mistakes. Group related statements logically, keep the scope clear, and resist the temptation to write clever, broad statements that cover many cases at the cost of being hard to reason about. The readable policy and the secure policy are usually the same policy.
This connects to the wider discipline of posture management and review covered in the complete security guide. Policies are not written once and forgotten. They are reviewed, audited, and adjusted as the estate changes, and a policy set written to be readable is one that survives that review process intact rather than decaying into sprawl.
A framework for writing policies
- Get compartments right first. A clean compartment design gives policies the boundaries they need.
- Grant to groups. Attach access to groups, never to individual users.
- Choose the least verb. Grant the minimum capability that does the job, not the broadest that works.
- Scope narrowly. Grant at the smallest compartment that meets the need.
- Write for the reader. Make each statement self explanatory so reviews catch mistakes.
- Review and consolidate. Remove unused policies regularly to prevent sprawl.
Testing what a policy set actually permits
Writing a policy is only half the work. The other half is being able to answer, at any time, what access the policy set actually grants, because a set you cannot reason about is a set you cannot trust. The most valuable habit is to periodically ask the reverse question of each sensitive resource: who can reach this, and why. If the answer is longer than expected or includes groups whose need is unclear, the policy set has drifted toward over permissioning even if each statement looked reasonable when written.
This kind of review is far easier when the policies were written to be readable and scoped to clean compartments in the first place, which is the practical payoff of the discipline described above. A tidy policy set answers the who can reach this question quickly, while a sprawling one hides the answer in volume. Building the set to be auditable is therefore not a separate task from building it securely, it is the same task, because access you cannot audit is access you cannot defend.
Bringing it together
Effective OCI policies are least privilege, readable, and built on a clean compartment design. Choose the least verb that does the job, scope to the narrowest compartment, grant to groups rather than individuals, write each statement to be understood, and review the set regularly so it does not sprawl into something nobody can reason about. Policies written this way are both more secure and easier to live with, and they hold up as the estate grows. The identity foundation they depend on is in our identity domains guide, and the full picture is in the complete security guide. When you want your access model designed and reviewed properly, our security and compliance service covers it end to end.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.