Access Control

This topic gives basic information about using compartments  and IAM policies  to control access to your cloud network.

Compartments and Your Cloud Network

Anytime you create a cloud resource such as a virtual cloud network (VCN) or compute instance, you must specify which IAM compartment you want the resource in. A compartment is a collection of related resources that can only be accessed by certain groups that have been given permission by an administrator in your organization. The administrator creates compartments and corresponding IAM policies to control which users in your organization access which compartments. Ultimately, the goal is to ensure that each person can only access the resources they need.

If your company is starting to try out Oracle Cloud Infrastructure, only a few people need to create and manage the VCN and its components, launch instances into the VCN, and attach block storage volumes to those instances. Those few people need access to all these resources, so all those resources could be in the same compartment.

In an enterprise production environment with a VCN, your company can use multiple compartments to more easily control access to certain types of resources. For example, your administrator could create Compartment_A for your VCN and other networking components. The administrator could then create Compartment_B for all the compute instances and block storage volumes that the HR organization uses, and Compartment_C for all the instances and block storage volumes that the Marketing organization uses. The administrator would then create IAM policies that give users only the level of access they need in each compartment. For example, the HR instance administrator is not entitled to modify the existing cloud network. So they would have full permissions for Compartment_B, but limited access to Compartment_A (just what's required to launch instances into the network). If they tried to modify other resources in Compartment_A, the request would be denied.

Network resources such as VCNs, subnets, route tables, security lists, service gateways, NAT gateways, VPNs, and FastConnect connections can be moved from one compartment to another. When you move a resource to a new compartment, inherent policies apply immediately.

For more information about compartments and how to control access to your cloud resources, see Setting Up Your Tenancy and Overview of Oracle Cloud Infrastructure Identity and Access Management.

IAM Policies for Networking

The simplest approach to granting access to Networking is the policy listed in Let network admins manage a cloud network. It covers the cloud network and all the other Networking components (subnets, security lists, route tables, gateways, and so on). To also give network admins the ability to launch instances (to test network connectivity), see Let users launch Compute instances.


For reference material for writing more detailed policies for Networking, see Details for the Core Services.

Individual Resource-Types

If you'd like, you can write policies that focus on individual resource-types (for example, security lists only) instead of the broader virtual-network-family. The instance-family resource-type also includes several permissions for VNICs, which reside in a subnet but attach to an instance. For more information, see Details for Verb + Resource-Type Combinations and Virtual Network Interface Cards (VNICs).

There's a resource-type called local-peering-gateways that is included within virtual-network-family and includes two other resource-types related to local VCN peering (within region):

  • local-peering-from
  • local-peering-to

The local-peering-gateways resource-type covers all permissions related to local peering gateways (LPGs). The local-peering-from and local-peering-to resource-types are for granting permission to connect two LPGs and define a peering relationship within a single region. For more information, see Local VCN Peering (Within Region).

Similarly, there's a resource-type called remote-peering-connections that is included within virtual-network-family and includes two other resource-types related to remote VCN peering (across regions):

  • remote-peering-from
  • remote-peering-to

The remote-peering-connections resource-type covers all permissions related to remote peering connections (RPCs). The remote-peering-from and remote-peering-to resource-types are for granting permission to connect two RPCs and define a peering relationship across regions. For more information, see Remote VCN Peering (Across Regions).

Nuances of Different Verbs

If you'd like, you can write policies that limit the level of access by using a different policy verb ( manage versus use, and so on). If you do, there are some nuances to understand about the policy verbs for Networking.



  • Update (enable/disable) internet-gateways
  • Update security-lists
  • Update route-tables
  • Update dhcp-options
  • Peer VCNs


For more information about policy verbs, see Policy Basics.