Policy

A policy allows a group to work in certain ways with specific types of resources in a particular compartment

IAM administrator workflow

1. Define users, groups, and one or more compartments to hold the cloud resources for your organization.
2. Create one or more policies
3. Place users into the appropriate groups depending on the compartments and resources they need to work with.

Syntax

• Allow <subject> to <verb> <resource-type> in <location> where <conditions>

Verb	Types of Access Covered	Target User
inspect	Ability to list resources, without access to any confidential information or user-specified metadata that may be part of that resource.	Third-party auditors
read	Includes inspect plus the ability to get user-specified metadata and the actual resource itself.	Internal auditors
use	Includes read plus the ability to work with existing resources. Includes the ability to update the resource.	Day-to-day end-users of resources
manage	Includes all permissions for the resource.	Administrators

Use of Variables

You use variables when adding a condition to policy; 2 types

• Request: relevant to the request itself

• Variable: request.operation represents the API operation being requested (e.g. ListUsers)

• Target: relevant to the resource(s) being acted upon in the request.

• Variable: target.group.name represents the name of the group 

A variable name is prefixed accordingly with either request or target followed by a period.

Examples:

Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'

Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'

allow group PHX-admin to manage all-resources in tenancy where request.region=’phx’

Common Policies (Oracle Documents)

• Network Admins: Manage a cloud Network
• Allow group NetworkAdmins to manage virtual-network-family in tenancy
• Users: Launch instances compute (Create and start)
• Allow group InstanceLaunchers to manage instance-family in compartment ABC
• Users: Launch instances volumes (Create and start) 
• Allow group InstanceLaunchers to manage volume-family in compartment ABC
• Users: Launch instances use networks
• Allow group InstanceLaunchers to use virtual-network-family in tenancy

Policy Inheritance

Compartments inherit any policies from their parent compartment.

Example: OCI has a built-in policy for Administrators

Allow group Administrators to manage all-resources in tenancy.
Due to policy inheritance, the Administrators group can also do anything in any of the compartments in tenancy.

Policy Attachment

• When you create a policy you must attach it to a compartment (or tenancy). 

• Where you attach the policy, it controls who can modify the policy or delete it.

• Attach the policy to the tenancy (root compartment), then anyone with access to manage policies in the tenancy can then change or delete it.

• Attach the policy to a child compartment, then anyone with access to manage the policies in that child compartment (e.g. compartment admin) can change or delete it.

Example: Three-level compartments

• Path to compartmentC from compartmentA is compartmentB:compartmentC

• Path to compartment compartmentC from the root is: compartmentA: compartmentB: compartmentC

• The path to compartment compartmentC from compartmentB is compartmentC

• The path to compartment compartmentC from compartmentC is compartmentC

Scenario 1: Allow NetworkAdmins to manage VCNs in CompartmentC,  attach this policy to CompartmentC or to its parent, CompartmentB,

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentC

Scenario 2: Attach the same policy to CompartmentA 

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC




Scenario 3: To attach this policy to the tenancy (root)

Allow group NewtworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC

Moving Compartments

• You can move a compartment to a different parent compartment within the same tenancy.

• When you move a compartment, all its contents (sub-compartments and resources) are moved with it.

• Two compartments with the same parent cannot have the same name

Policy Implications when moving compartments

Policies that specify the compartment hierarchy down to the compartment being moved will automatically be updated when the policy is attached to a shared ancestor of the current and target parent.

Two conditions:

1. Have a shared ancestor (parent or grandparent)

2. The policy is defined up to the target compartment that will be moved. 

Groups with Permissions in the Current Compartment Lose Access; Groups with Permissions in the Destination Compartment Gain Access

The following figure shows a compartment hierarchy in which compartment C, a child of A:B is moved to the hierarchy A:D.

The tenancy has the following policies defined for compartments B and D:

Policy1: Allow group G1 to manage instance-family in compartment A:B

Policy2: Allow group G2 to manage instance-family in compartment A:D

Impact when compartment C is moved from B to D:

Group G1 can no longer manage instance-families in compartment C.

Group G2 can now manage instance-families in compartment C.

Ensure that you are aware not only of what groups lose permissions when you move a compartment but also what groups will gain permissions.

Unallowed move

For example, assume compartment A and compartment B are both under the root compartment. Under compartment A is a subcompartment, also called compartment B. You cannot move the compartment B to the parent compartment B.