Oracle Cloud Infrastructure Documentation

Policy Basics

To govern control of your resources, you need at least one policy. Each policy consists of one or more policy statements that follow this basic syntax:

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>

Policy statements begin with the word Allow. Policies only allow access; they cannot deny it. Instead, all access is implicitly denied, meaning users can only do what they have been granted permission for. A tenancy administrator defines the groups and compartments; the available resource types are determined by Oracle.

If you want a policy to apply to the tenancy and not a compartment inside the tenancy, change the end of the policy statement as follows:

Allow group <group_name> to <verb> <resource-type> in tenancy

A basic feature of policies is the concept of inheritance: compartments inherit any policies from their parent compartment. If a group has a particular level of access to certain resource types in a compartment, then those same permissions apply in all subcompartments of the compartment where this policy is applied. The simplest example is the Administrators group in the tenancy: the built-in policy allows the administrators to manage all the resources in the tenancy root compartment. Because of policy inheritance, the administrators have full access to all operations and all resources in every compartment.

Resource Types

The resource types that you can use in policies are either individual or family types. The family resource types make policy writing easier, as they include multiple individual resource types that are often managed together. For example, the virtual-network-family type brings together a variety of types related to the management of VCNs: vcns, subnets, route-tables, security-lists, and so on. If you need to write a more granular policy, use an individual resource type to give access to only those specific resources. Note that there are other ways to make policies more granular, such as the ability to specify conditions under which the access is granted.

With future service updates, it is possible that resource type definitions are changed or added. These are typically reflected automatically in the resource family type for that service, so your policies remain current.

Some operations require access to multiple resource types. For example, launching an instance requires the permission to create instances and to work with a cloud network. Or creating a volume backup requires access to both the volume and the volume backup. That means you have separate statements to give access to each resource type.

These individual statements do not have to be in the same policy. A user can gain the required access from being in different groups. For example, a user could be in one group that gives the required level of access to the volumes resource type, and in another group that gives the required access to the volume-backups resource type. The sum of the individual statements, regardless of their location in the overall set of policies, allows the user to create a volume backup.

Policy Attachment

Another basic feature of policies is the concept of attachment. When you create a policy you must attach it to a compartment; or to the tenancy, which is the root compartment. Where you attach it controls who can then modify it or delete it. If you attach a policy to the tenancy, it can only be modified by the Administrators group, and not by users with only access to a subcompartment.

If you instead attach the policy to a child compartment, then anyone with access to manage the policies in that compartment can change or delete it. In practical terms, you can give compartment administrators – a group with access to manage all resources in the compartment – access to manage their own compartment's policies, without giving them broader access to manage policies that reside in the tenancy.

To attach a policy to a compartment, you must be in that compartment when you create the policy. As part of a policy statement you specify the compartment it applies to, so if you try to attach the policy to a different compartment you get an error. Policy attachment occurs at the time of creation, which means a policy can be attached to one compartment only.