Overview

IAM Access Management is one of the most important preventative controls in securing assets (Data assets or Services assets).  It ensures that people can only gain access to things they’re supposed to have access to. When access control is broken, an attacker can obtain unauthorized access to information or systems that can put an organization at risk of a data breach or system compromise.

In 2021, the OWASP top ten moved broken access control from the fifth position to the first position in the list of top vulnerabilities in web applications. The most difficult aspects of broken access control are it is hard to catch. There are no error messages, and everything appears functioning as designed or as expected. That is why there is greater emphasis on getting the policies right.

IAM Policy design principles

There are two important and foundational design principles that you should follow while designing IAM policies.  

Zero Trust

Zero Trust means “Do not trust Anyone (Internal User, External User, Internal VM, Internal process, or Internal network User)”. With that rule, you design IAM policies. Zero trust adheres two core rules.

• Never trust, always verify (even if it's an internal service accessing another internal service, verification is required)
• Assume breach (assuming the access could be a security breach and build access permissions from there)

By implementing Zero Trust Model, we reduce the risk of unintentional and unauthorized access.

Least Privilege

The least privilege restricts access and permissions as much as possible, without interfering with users' normal usage. We achieve this by defining the minimum amount of privilege users in each role need to perform their work. And, the goal is to regularly audit usage, reduce unnecessary standing permissions wherever possible.

When we create IAM policies, follow the standard security advice of granting the least privilege or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.

We can always start with the minimum set of permissions and grant additional permissions as necessary. Try, fail, try again, add more, then make it perfect. Doing so is more secure than starting with permissions that are too wide and then trying to tighten them later.

OCI IAM Policies

As large ISVs or large enterprises move their workload to OCI, we need ways to write IAM policies to cover for a large number of resources. I will not talk about how to create IAM policies and the syntax of IAM policies. You can find those details from OCI documentation.

Tag based Access Control policies.

Tagging allows you to add metadata to resources, which enables you to define keys and values and associate those values with the resources. One of the two primary use cases of tagging is Access Control. You can use resource metadata in IAM policies to refine access policies and control who has CRUD permissions on the resources. You can find more information about tagging from OCI documentation.

Resource tag-based Access policies

Once tags are assigned to resources, you can leverage those tags to write IAM access policies. Below are some examples.

• Using lifecycle environment tags to allow Prod Administrators manage Prod resources and Non Prod Administrators manage Non Prod resources.

Allow group ProdAppAdmins to use network-family-resources in compartment Network where target.resource.tag.Operations.lifecycle=’PROD’

Allow group DevAppAdmins to use network-family-resources in compartment Network where target.resource.tag.Operations.lifecycle=’DEV’

• Above policy does not work well for create operation. Because IAM policy evaluation cannot check policy on resource tags for the resources that are not created yet. In such cases, we have to rely on compartment tags.

Allow group ProdNetworkAdmins to manage network-family-resources in compartment Network where any { target.resource.tag.Operations.lifecycle=’PROD’, target.resource.compartment.tag.Operations.lifecycle=’PROD’}

Allow group DevNetworkAdmins to manage network-family-resources in compartment Network where any { target.resource.tag.Operations.lifecycle=’DEV’, target.resource.compartment.tag.Operations.lifecycle=’DEV’}

• You could have multiple application resources and their respective Admin/non-admin groups. For those resources and groups, tags can be assigned. If we do that then with just one policy, we can control access to resources. Please note that tags assigned to request principal is a union or all tags assigned to user’s groups.

Allow any-user to manage network-family-resources in compartment Network where any { request.principal.group.tag.Operations.lifecycle=target.resource.tag.Operations.licecycle, request.principal.group.tag.Operations.lifecycle=target.resource.compartment.tag.Operations.lifecycle }

Policies based on user’s Identity Domain

• With the introduction of Identity domains, if you have SaaS domains or Apps specific domains then you can also write policy and allow users from the OCI domain to allow access to resources. For example, the last policy is using any-user principal. However, I want to make sure that it allows users from only the default domain.

Allow any-user to manage network-family-resources in compartment Network where all {

Any { request.principal.group.tag.Operations.lifecycle=target.resource.tag.Operations.licecycle, request.principal.group.tag.Operations.lifecycle=target.resource.compartment.tag.Operations.lifecycle }, request.user.domain.name=’Default’}

• If you want to allow user from the default domain permission to manage domain, then the policy would look like as below.

Allow group DomainAdmin to manage domains in compartment DomainsCompartment where target.domain.name=’TestDomain’

• If you want to allow a group administrator group from the default domain to manage groups in an application domain, then the policy would be as below. The user would also require read permission on the domains to be able to find the domain from the console.

Allow group GroupsAdmin to read domains in compartment DomainsCompartment

Allow group GroupsAdmin to manage groups in compartment DomainsCompartment where target.resource.domain.name=’TestDomain’

Conclusion

Advanced policies referenced in the blog help you implement Attribute based access control (ABAC) where attributes are tags assigned to resources and respective groups. ABAC provides scalability to support large volumes of compartments with a small number of IAM policies.

Resources

• Advanced IAM policies
• Tag based access control