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, VPN connections, 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 Learn Best Practices for Setting Up Your Tenancy and Overview of 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.

If you're new to policies, see Getting Started with Policies and Common Policies.

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 Peering using an LPG (VCNs in the Same Tenancy) or Local Peering using an LPG (VCNs in Different Tenancies).

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 Peering with a Legacy DRG and Remote Peering with an Upgraded DRG.

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.

Be aware that the inspect verb not only returns general information about the cloud network's components (for example, the name and OCID of a security list, or of a route table). It also includes the contents of the component (for example, the actual rules in the security list, the routes in the route table, and so on).

Also, the following types of abilities are available only with the manage verb, not the use verb:

Update (enable/disable) internet-gateways
Update security-lists
Update route-tables
Update dhcp-options
Attach a Dynamic Routing Gateway (DRG) to a Virtual Cloud Network (VCN)
Create an IPSec connection between a DRG and customer-premises equipment (CPE)
Peer VCNs

Important

Each VCN has various components that directly affect the behavior of the network (route tables, security lists, DHCP options, Internet Gateway, and so on). When you create one of these components, you establish a relationship between that component and the VCN, which means you must be allowed in a policy to both create the component and manage the VCN itself. However, the ability to update that component (to change the route rules, security list rules, and so on) does NOT require permission to manage the VCN itself, even though changing that component can directly affect the behavior of the network. This discrepancy is designed to give you flexibility in granting least privilege to users, and not require you to grant excessive access to the VCN just so the user can manage other components of the network. Be aware that by giving someone the ability to update a particular type of component, you're implicitly trusting them with controlling the network's behavior.

For more information about policy verbs, see Policy Basics.

Peering Policies

For policies used in connecting a DRG to VCNs and DRGs in other regions and tenancies, see IAM Policies for Routing Between VCNs.