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.
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.
If you'd like, you can write policies that focus on individual resource-types (for example, security lists only) instead of the broader
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-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 define a peering relationship within a single region. For more information, see Local VCN Peering using Local Peering Gateways.
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 define a peering relationship across regions. For more information, see Remote VCN Peering using a Legacy 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 (
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 Policy Basics.