Announcing the newest milestone in OCI’s Zero Trust journey, Oracle Cloud Infrastructure (OCI) is introducing IAM Deny policies, now available in General Availability. As part of OCI’s Zero Trust initiative, IAM Deny adds explicit deny statements to IAM, which is designed to make it easier for customers to enforce least privilege, control access paths, and strengthen security boundaries across large, multi-compartment environments. Tailored for enterprises managing complex tenancies, IAM Deny helps streamline policy management, strengthen security postures, and simplify compliance efforts. This blog explores IAM Deny’s capabilities and its impact on enabling more secure cloud operations. 

Addressing Complex Access Control Needs

Until now, OCI IAM has used allow policies with a default-deny model, which has worked well for many access scenarios. But as organizations grow with global operations, multi-region deployments, and larger administrative teams managing policies and delegating responsibilities can become increasingly complex.

IAM Deny introduces explicit deny statements that take precedence over allow policies, allowing organizations to define clear, enforceable access boundaries. This empowers users who can manage policies to establish tenancy-wide guardrails while safely delegating policy management to users who can manage policies in child compartments, enabling strong, scalable access control in even the most security-conscious environments.

Key benefits of IAM Deny include:

  • Stronger Guardrails: Root administrators can set broad, tenancy-wide restrictions to establish a secure baseline.
  • Empowered Delegation: Root admins can apply targeted restrictions (e.g., Deny group DevOps to manage network-family in compartment ProjectX) while granting user who can manage policies in child compartment autonomy over specific resources, balancing control with flexibility.
  • Simplified Policy Management: Deny policies remove the need for complex exclusions in allow statements. Without them, admins must add multiple where clauses to each allow policy to block specific services, operations, or networks- a tedious and error-prone task in large environments. Deny rules provide a cleaner, more reliable way to enforce restrictions and prevent accidental access or overwrites by compartment administrators.
  • Improved Auditability: Explicit deny rules make permissions clearer and easier to monitor, helping security teams respond to incidents quickly and support compliance efforts.
  • Consistent Regulatory Compliance: Deny statements enforce organizational boundaries uniformly, including restricting access from unauthorized networks such as the internet, designed to simplify adherence to internal policies and external security regulations.

These enhancements make IAM Deny valuable for all organizations, and especially critical to those operating in regulated environments, where policy clarity, delegation control, and operational efficiency are essential.

Capabilities of IAM Deny

IAM Deny integrates seamlessly into the OCI IAM policy editor, employing a familiar syntax:

Deny <subject> to <metaverb> <resource-type> in <scope> [where <conditions>]

It utilizes existing meta-verbs (manage, use, read, inspect) with a subtractive permission hierarchy—denying a higher-level permission (e.g., manage) blocks only that level, preserving lower permissions (e.g., read, inspect). Key features include:

  • Deny-First Evaluation: Deny statements are evaluated before allow policies in the compartment hierarchy, so that root-level restrictions override child-compartment configurations.
  • Default Administrator Exemption: Deny policies do not apply to the “default administrator group”, preventing lockouts and enabling root admins to correct misconfigurations.
  • Granular Conditions: Administrators can target specific services, regions, or resources for precise control.
  • Cross-Tenancy Flexibility: Deny statements enable precise control in multi-tenancy environments, supporting delegated administration by defining clear access boundaries. For example, you can endorse the ‘Devs’ group to use an object-family in ‘PartnerTenancy’ while denying them the ability to manage that object-family in the same tenancy, designed to enable flexible and secure cross-tenancy operations.
  • Policy Integration: Deny and allow statements coexist within the same policy editor, offering flexibility to craft combined or separate policies as needed.

Example Usecase

Consider a public sector organization managing its cloud operations across multiple regions with delegated administration. They can secure network configurations while still permitting storage management using:

Deny group ProjectAdmins to manage network-family in compartment GovProject

Allow group ProjectAdmins to manage object-family in compartment GovProject

These policies are designed to enforce strong security boundaries while enabling teams to perform their responsibilities effectively by allowing storage actions while preventing network changes. To further safeguard the environment in a particular compartment, the organization wants to prevent sub-admins from creating deny policies by adding:

Deny group ProjectAdmins to manage policies in compartment GovProject where target.policy.type=’DENY’

Further, they want to block access from untrusted external networks by defining a network source for those IP ranges and applying:

Deny any-user to access all-resources in tenancy where request.networksource.name=’RestrictedRegion’

Finally, to help ensure sensitive operations occur only in approved regions, they enforce:

Deny group DataTeam to manage object-family in tenancy where request.region != ‘us-ashburn-1’

Together, these policies are designed to allow the organization to delegate tasks safely, enforce network-based restrictions, and maintain region-specific boundaries,  all while leveraging IAM Deny to help ensure clear, predictable, and secure access control.

Next Steps

IAM Deny represents a pivotal evolution of OCI IAM, equipping enterprises to secure tenancies, simplify policy management, and meet regulatory needs with ease. For detailed guidance, explore the OCI IAM documentation, FAQ and best practices.