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 be accessed only by certain groups that have been given permission by an administrator in your organization. The administrator will create compartments and corresponding IAM policies to control which users in your organization have access to which compartments. Ultimately, the goal is to ensure that each person has access to only 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 will want to use multiple compartments to make it easier to 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, seeSetting Up Your Tenancy and Overview of Oracle Cloud Infrastructure Identity and Access Management.
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.
If you'd like, you can write policies that focus on individual resource-types (for example, just security lists) instead of the broader
virtual-network-family. Be aware that 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 For instance-family Resource Types 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-gateways resource-type covers all permissions related to local peering gateways (LPGs). The
local-peering-to resource-types are for granting permission to connect two LPGs and form 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-connections resource-type covers all permissions related to remote peering connections (RPCs). The
remote-peering-to resource-types are for granting permission to connect two RPCs and form 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 (
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
- Update (enable/disable)
- 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
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 Verbs.