This blog is about restricting access for the use of networks and network-configurations within a tenant. It is a typical requirement when corporate network administrators manage networks and give e.g. developers only the possibility to use existing topologies and settings like networks, subnets, internet or private access, firewall-settings, routings and so on.
A common best practice is to separate responsibilities in any tenant. Several standards (like ITIL), security checklists (like CIS) or templates (like terraform landing zones) recommend, test or implement this segregation of duties. The typical segregation of duties in OCI can be implemented with groups (e.g. a network group, a security group) and compartments. Compartments are logical containers to separate resources. So e.g. seperate developers with a dedicated compartment or do it more fine grained and define a development compartment per project. For more see IAM best practices: https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/best-practices-for-iam-on-oci.pdf
Going with compartments might become too complex some times due to the number of compartments. And for some restricted or limited resources, like corporate private network setup it might not be feasible. OCI offers a so called tagging mechanism. Widely used for cost tracking (e.g. which project produces which costs) tagging could also be used for limiting access and available functionalities of resources. This is a second dimension to compartments. E.g in a network compartment you can define subnets which will be available for development while others within the same compartment are for production only. This blog will follow this approach and use network functionality as sample, first using separate network compartment and in the next step tagging.
Short recap of how OCI tenant works
You create local Users or get federated Users
Optional separate Usermanagements within OCI can be setup (IDCS: Stripes, IAM Domains)
Users are members of groups
Groups are entitled through policies to use resources (e.g. create compute instance)
Policies work with inheritance within compartment structure
Resources are assigned to a compartment (logical container)
Resources (instances, services) can be in dynamic groups
Dynamic Groups are entitled through policies to use resources (e.g. use buckets or key management)
A sample illustrates this:
For a more realistic setup see landing zone setup: https://docs.oracle.com/en/solutions/cis-oci-benchmark/index.html
The blog follows a sample setup with
- the default IAM Domain where the ones with admin privileges live (this is the ootb domain within each tenant). Here are also the corp. developers.
- an extra IAM Domain for free use for developers with the assumption that developers also need to create and entitle some testusers and app integrations (as this IAM domain is bound to a compartment they can not interfere with the rest of the tenant; developers need not to have a manage all in the developer compartment)
- a Network compartment with all Network resource which could be in further subcompartments
In the sample setup the use case should be to create a compute instance as developer in the developer compartment in the subcompartment Computeproject.
As written assume the developer is not allowed to create his own networks as a corp network should be used or for any other reason.
To entitle a Developer to do so he needs the entitlement to manage instances and use an existing network. To connect an instance to a network OCI uses VNics. A primary VNic is created within instance creation and a primary private IP address from the selected subnet is assigned. So simplified this looks:
Recap of policies.
A policy looks like Allow <subject> to <verb> <resource-type> in <location> where <conditions>
Polices need an allow as OCI starts with deny-all.
In the sample the subject is the group where the developer is assigned to. For group I take a group named developers. An OCI group belongs to an IAM or IAM domain. As the Developers are from corporate with Admin privileges they are here in the default domain. Another setup would be to put them in one or more extra IAM domains (not treated here).
Policies belong to a compartment and use inheritance along the compartment structure.
For easier overview, if you manage policies in tenant the policies are put in root. In the where clause they can the compartment restriction. A policy sees only one hierarchy level, so to specify a compartment which is more than one hierarchy level away the path has to be specified like compartmentLevel1:compartmentLevel2:compartmentLevel3.
The policy reference used here is ‘core’ which includes compute and network: https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/corepolicyreference.htm
With this the setup follows:
- Polices are defined in root
- Developers Group is defined in default IAM
To allow create compute instances in the Compartment intended for this developer project:
Allow group developers to manage instance-family in compartment DeveloperCompartment:Computeproject
To allow to put the compute instance in an existing subnet in the NetworkCompartment:
Allow group developers to use subnets in compartment NetworkCompartment
grabbed from https://docs.oracle.com/en-us/iaas/Content/Identity/Reference/corepolicyreference.htm: To launch instances using the Console, also need inspect vcns
The Subnet resource is quite limited on using resources, especially no security list change etc.
Here the explanation: https://docs.oracle.com/en-us/iaas/Content/Identity/policiesgs/policies_topic-Verbs.htm
(grabbed from this: 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…)
The operations can in addition been limited in where clause, this goes to:
any {request.permission=’SUBNET_READ’, request.permission=’SUBNET_ATTACH’, request.permission=’SUBNET_DETACH’}
But that’s not all as you need at least one VNic per instance:
Allow group developers to use vnics in compartment NetworkCompartment
This allows only READ + VNIC_ATTACH, VNIC_DETACH, VNIC_CREATE, VNIC_DELETE, VNIC_UPDATE. Means Security Groups and Network Security Groups and Creating PrivateIPs is not auto included but could be added. E.g. If network groups are used/assigned in addition to secure trafic between instance groups.
Allow group developers to use network-security-groups in compartment NetworkCompartment
From a command line it could be used now. But using the UI requires additional list (this is less than read) permissions as the UI begins always with a list using the overview or any selector. This needs:
allow group developers to inspect virtual-network-family in compartment NetworkCompartment
depending on the UI it can be restricted more to only be able to select a VCN but nor have a look into it like for security lists. Policy would look like this:
allow group developers to inspect VCNs in compartment NetworkCompartment
Summarized:
Allow group developers to inspect virtual-network-family in compartment NetworkCompartment [see explanation above] Allow group developers to use subnets in compartment NetworkCompartment Allow group developers to use vnics in compartment NetworkCompartment Allow group developers to manage instance-family in compartment DeveloperCompartment:Computeproject
Now it should work with the UI. It’s obvious how this set of policies could be extended to subcompartments in network compartment.
Extend to Tagging.
Short Recap of tagging:
There are Free-form which consist simply of a key and a value And there are Defined Tags. They are used within defined tag Namespaces. This requires an IAM policy be allowed. You can’t use free-form tags to control access to resources. That is, you can’t include free-form tags in IAM policies You need defined tags, see https://docs.oracle.com/en-us/iaas/Content/Tagging/Concepts/understandingfreeformtags.htm
Used in policy it would end in a where condition like target.resource.tag.Operations.Environment = ‘Development’.
BTW you can use auto-tagging per compartment to set tags to every created resource (not covered here).
To use tags you have to define them as mentioned before and apply them to the VCN (see here first line in tags).
Here a sample of a tag applied to a subnet. With Add Tags or the Edit pencil the assigned tags could be modified.
Tagging Polices will end in
for the UI:
allow group developers to inspect virtual-network-family in compartment NetworkCompartment
Here the explanation: https://docs.oracle.com/en-us/iaas/Content/Tagging/Tasks/managingaccesswithtags.htm#Using_Tags_to_Manage_Access
(grabbed from this: Policies that scope access based on the tag applied to the target resource can’t allow the permissions that enable you to return a list of resources. Therefore, permissions to allow listing a resource must be granted through an additional policy statement.)
for entitlements:
Allow group developers to use subnets in compartment NetworkCompartment where target.resource.tag.Operations.Environment = ‘Development’
Allow group developers to use vnics in compartment NetworkCompartmentAllow group developers to manage instance-family in compartment DeveloperCompartment:Computeproject
Summarized:
Allow group developers to inspect virtual-network-family in compartment NetworkCompartment Allow group developers to use subnets in compartment NetworkCompartment where target.resource.tag.Operations.Environment = 'Development' Allow group developers to use vnics in compartment NetworkCompartment Allow group developers to manage instance-family in compartment DeveloperCompartment:Computeproject
Two remarks on using tags in policies:
Create any object does not work if resource policy is with tag where condition
Some resources have additional limitations (e.g. VNIC_UPDATE )
For more information see: https://docs.oracle.com/en-us/iaas/Content/Tagging/Tasks/managingaccesswithtags.htm#Service
Using more than one tag:
the tag statemen can be extended to allow to use several tags, this end up in e.g.
Allow group developers to use subnets in compartment NetworkCompartment where any {target.resource.tag.Operations.Environment = ‘Development’, target.resource.tag.Operations.Environment = ‘POC’}
and together with the restriction on permission, e.g.:
Allow group developers to use subnets in compartment NetworkCompartment where all{ any {request.permission=’SUBNET_READ’, request.permission=’SUBNET_ATTACH’, request.permission=’SUBNET_DETACH’}, target.resource.tag.Operation.Environment = ‘Development’}
Troubleshooting
Typical errors are ‘access denied’ and resource not found. They may have the same reason, authorization within this activity is not granted.
To find out with the assumption your policies are in place and from your point of view complete.
1. Check network access policy:
Use as developer OCI network and try to change into the department where the network(s) are defined. You should be able to get a listing of the VCNs.
If not check for policy allow group developers to inspect virtual-network-family in compartment NetworkCompartment
If you can not use the compartment selector because it is empty add a policy like Allow group developers to inspect compartments in tenancy
if ok
2. Check compute policy:
Use as developer OCI Compute and try to change to your developer compute compartment.
If you get an accessdenied check for Allow group developers to manage instance-family in compartment DeveloperCompartment:Computeproject
the path to the compartment may be incorrect or does not reflect correctly the compartment hierarchy
if ok
3. Check create instance
Use as developer the create instance dialog.
If you can not select an image or shape the to manage instance-family does not work, go back to 2)
If you can not select a VCN and Subnet go back to 1) BTW you should not be able to create a VCN!
If you can not add an additional Vnic or attach Network Security Groups you need additional policies which are not covered in this blog
if ok
4. Create instance throws an error (red error line in buttom of screen)
If you get an error like subnet not found or not authorized (reason is the same) the use subnet and use VNIC policy do not work correctly:
It’s more tricky when using tags, as tags can only be added for the subnet policy
sample error:
Audit Log: You can find the errors in the Audit log as 4xx (mostly 404), but these error logs do not include more information than the UI provides. The 404 errors on subnet not found in the compute compartment are caused by the UI dialog when selecting the VCN and subnet. The real error (LaunchInstance failed with response ‘NotAuthorizedOrNotFound) can be found within the LaunchInstance Audit Log. But this is not correleated to the error shown by the UI.
Polices: If a policy includes an error in the where clause the policy is always evaluated as false (= not denied), even if you have a syntax of semantic error. E.g. a miss-spelling in a tag. This is hard to find, so reduce policy statement and try to add condition by condition.
This is the regular end of the blog.