Examples showing how different IAM components work together.
The goal of this scenario is to show how the different IAM components work together, and basic features of policies.
In this scenario, Acme Company has two teams that will be using Oracle Cloud Infrastructure resources for infrastructure: Project A and Project B. In reality, your company may have many more.
Acme Company plans to use a single virtual cloud network (VCN) for both teams, and wants a network administrator to manage the VCN.
Acme Company also wants the Project A team and Project B team to each have their own set of instances and block storage volumes. The Project A team and Project B teams shouldn't be able to use each other's instances. These two teams also shouldn't be allowed to change anything about the VCN set up by the network administrator. Acme Company wants each team to have administrators for that team's resources. The administrators for the Project A team can decide who can use the Project A cloud resources, and how. Same for the Project B team.
Acme Company Gets Started with Oracle Cloud Infrastructure
Acme Company signs up to use Oracle Cloud Infrastructure and tells Oracle that an employee named Wenpei will be the default administrator. In response, Oracle:
- Creates a tenancy for Acme Company (see the following diagram).
- Creates an IAM user account for Wenpei in the tenancy.
- Creates the Administrators group in the tenancy and places Wenpei in that group.
- Creates a policy in Acme Company's tenancy that gives the Administrators group access to manage all of the resources in the tenancy. Here's that policy:
Allow group Administrators to manage all-resources in tenancy
The Default Administrator Creates Some Groups and Another Administrator
Wenpei next creates several groups and users (see the following diagram). She:
- Creates groups called NetworkAdmins, A-Admins, and B-Admins (these last two are for Project A and Project B within the company)
- Creates a user called Alex and puts him in the Administrators group.
- Leaves the new groups empty.
To learn how to create groups, see Managing Groups. To learn how to create users and put them in groups, see User Management.
The Default Administrator Creates Some Compartments and Policies
Wenpei next creates compartments to group resources together (see the following diagram). She:
- Creates a compartment called Networks to control access to the Acme Company's VCN, subnets, Site-to-Site VPN, and other components from Networking.
- Creates a compartment called Project-A to organize Project A team's cloud resources and control access to them.
- Creates a compartment called Project-B to organize Project B team's cloud resources and control access to them.
To learn how to manage compartments, see Managing Compartments.
Wenpei then creates a policy to give the administrators for each compartment their required level of access. She attaches the policy to the tenancy, which means that only users with access to manage policies in the tenancy can later update or delete the policy. In this scenario, that is only the Administrators group. The policy includes multiple statements that:
- Give the NetworkAdmins group access to manage networks and instances (for the purposes of easily testing the network) in the Networks compartment
- Give both the A-Admins and B-Admins groups access to use the networks in the Networks compartment (so they can create instances into the network).
- Give the A-Admins group access to manage all resources in the Project-A compartment.
- Give the B-Admins group access to manage all resources in the Project-B compartment.
Here's what that policy looks like (notice it has multiple statements in it):
Allow group NetworkAdmins to manage virtual-network-family in compartment Networks Allow group NetworkAdmins to manage instance-family in compartment Networks Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks Allow group A-Admins to manage all-resources in compartment Project-A Allow group B-Admins to manage all-resources in compartment Project-B
Notice the difference in the verbs (
manage, use), as well as the
virtual-network-family, instance-family, all-resources).
For more information about them, see Verbs and
Resource-Types.To learn how to create
policies, see Creating a policy.
A-Admins and B-Admins can use the virtual-network-family in the compartment Networks. However, they can't create instances in that compartment. They can only create instances in the Project-A or Project-B compartment. Remember, a compartment is a logical grouping, not a physical one, so resources that make up or reside on the same VCN can belong to different compartments.
Acme Company wants to let the administrators of the Project-A and Project-B compartments decide which users can use the resources in those compartments. So Wenpei creates two more groups: A-Users and B-Users. She then adds six more statements that give the compartment admins the required access they need in order to add and remove users from those groups:
Allow group A-Admins to use users in tenancy where target.group.name='A-Users' Allow group A-Admins to use groups in tenancy where target.group.name='A-Users' Allow group B-Admins to use users in tenancy where target.group.name='B-Users' Allow group B-Admins to use groups in tenancy where target.group.name='B-Users' Allow group A-Admins,B-Admins to inspect users in tenancy Allow group A-Admins,B-Admins to inspect groups in tenancy
Notice that this policy doesn't let the project admins create new users or manage credentials for the users. It lets them decide which existing users can be in the A-Users and B-Users groups. The last two statements are necessary for A-Admins and B-Admins to list all the users and groups, and confirm which users are in which groups.
Policies attached to the tenancy:
An Administrator Creates New Users
At this point, Alex is in the Administrators group and now has access to create new users. So he provisions users named Leslie, Jorge, and Cheri and places them in the NetworkAdmins, A-Admins, and B-Admins groups, respectively. Alex also creates other users who will eventually be put in the A-Users and B-Users groups by the admins for Project A and Project B.
Policies attached to the tenancy:
The Network Admin Sets Up the Network
Leslie (in the NetworkAdmins group) has access to manage
instance-family in the Networks compartment. She creates a virtual cloud network (VCN) with a single subnet in that compartment. She also sets up an Internet gateway for the VCN, and updates the VCN's route table to allow traffic via that gateway. To test the VCN's connectivity to the on-premises network, she launches an instance in the subnet in the VCN. As part of the launch request, she must specify which compartment the instance should reside in. She specifies the Networks compartment, which is the only one she has access to. She then confirms connectivity from the on-premises network to the VCN by logging in to the instance via SSH from the on-premises network.
Leslie terminates her test instance and lets Jorge and Cheri know that the VCN is up and running and ready to try out. She lets them know that their compartments are named Project-A and Project-B respectively. For more information about setting up a cloud network, see Networking. For information about launching instances into the network, see Compute.
Compartment Admins Set Up Their Compartments
Jorge and Cheri now need to set up their respective compartments. Each admin needs to do the following:
- Launch instances in their own compartment
- Put users in their "users" group (e.g., A-Users)
- Decide the type of access to give those users, and accordingly attach a policy to their compartment
Jorge and Cheri both launch instances into the subnet in the VCN, into their respective team's compartments. They create and attach block volumes to the instances. Only the compartment admins can launch/terminate instances or attach/detach block volumes in their respective team's compartments.
Network Topology and Compartment Access Are Different Concepts
It's important to understand the difference between the network topology of the VCN and the access control that the compartments provide. The instances Jorge launched reside in the VCN from a network topology standpoint. But from an access standpoint, they're in the Project-A compartment, not the Networks compartment where the VCN is. Leslie (the Networks admin) can't terminate or reboot Jorge's instances, or launch new ones into the Project-A compartment. But Leslie controls the instances' network, so she controls what traffic will be routed to them. If Jorge had specified the Networks compartment instead of the Project-A compartment when launching his instances, his request would have been denied. The story is similar for Cheri and the Project-B compartment.
But it's also important to note that Wenpei and Alex in the Administrators group do have access to the resources inside the compartments, because they have access to manage all kinds of resources in the tenancy. Compartments inherit any policies attached to their parent compartment (the tenancy), so the Administrators access also applies to all compartments within the tenancy.
Next, Jorge puts several of the users that Alex created into the A-Users group. Cheri does the same for B-Users.
Then Jorge writes a policy that gives users the level of access they need in the Project-A compartment.
Allow group A-Users to use instance-family in compartment Project-A Allow group A-Users to use volume-family in compartment Project-A Allow group A-Users to inspect virtual-network-family in compartment Networks
This lets them use existing instances (with attached block volumes) that the compartment admins already launched in the compartment, and stop/start/reboot them. It does not let A-Users create/delete or attach/detach any volumes. To give that ability, the policy would need to include
Jorge attaches this policy to the Project-A compartment. Anyone with the ability to manage policies in the compartment can now modify or delete this policy. Right now, that is only the A-Admins group (and the Administrators group, which can do anything throughout the tenancy).
Cheri creates and attaches her own policy to the Project-B compartment, similar to Jorge's policy:
Allow group B-Users to use instance-family in compartment Project-B Allow group B-Users to use volume-family in compartment Project-B Allow group B-Users to inspect virtual-network-family in compartment Networks
Now the A-Users and B-Users can work with the existing instances and attached volumes in the Project-A and Project-B compartments, respectively. Here's what the layout looks like:
Policies attached to the tenancy:
Policy attached and managed by Jorge:
Policy attached and managed by Cheri:
For more information about basic and advanced features of policies, see How Policies Work. For examples of other typical policies your organization might use, see Common Policies.