Tag-Based Access Control
Using conditions and a set of tag variables, you can write policy to scope access based on the tags that have been applied to a resource. Access can be controlled based on a tag that exists on the requesting resource or on the target resource or compartment of the request. Tag-based access control provides additional flexibility to your policies by allowing you to define access policies with tags that span compartments, groups, and resources.
Caution:
If your organization chooses to create policies that use tags to manage access, then ensure that you have appropriate controls in place to govern who can apply tags. Also, after policies are in place, keep in mind that applying tags to a group, user, or resource has the potential to confer access to resources.
Before you create such a policy, ensure that you are aware of all the potential requestors and target resources that carry the tag.
Before you apply a tag to a resource, ensure that you are aware of any policies in place that include the tag and could impact who has access to the resource.
You can control access based on the value of a tag applied to a requesting resource. More specifically, you can write policy statements to grant a user access based on the value of a tag that is assigned to the group to which the requesting user belongs.
You can also control access based on the value of a tag applied to a target resource, or a compartment that the target resource resides in.
By using tags in your policy statements to scope access, you can define access for multiple groups through a single policy statement. You can also confer access and revoke access for groups by applying or removing tags, without changing the original policies.
The Oracle Private Cloud Appliance User Guide provides a detailed description and examples of how to use tag variables and operators in your policy syntax. Refer to the section "Writing Policy Statements" in the chapter Identity and Access Management.
Important Notes and Limitations
This section describes a number of items to take into account when you start writing policies to control permissions based on resource tags.
| Item | Description |
|---|---|
|
Permissions to list resources must be granted separately |
Policies that scope access based on the tag applied to the target resource cannot 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. This approach improves the tag-based policy because it allows users to see the resource they want to manage, but still limits the permissions to only inspect. Another approach you can use to avoid this limitation is to tag the compartments that contains the resources you want to grant access to. |
|
Policies requiring a tag on the target resource cannot grant create permissions |
When you write a policy to scope access based on the value of a tag on the resource, keep in mind that the policy cannot grant create permissions. For example, a request to create an instance would fail because the target resource has not been created yet and therefore does not have the appropriate tag to be evaluated. Using and deleting instances with that tag would be allowed, but not creating instances. |
|
Limitations on characters in tag namespaces and tag key definitions used in policy variables |
Tag namespaces and tag key definitions support a broader set of characters than are allowed in policy variables. Therefore, to you use tag namespaces and tag key definitions in variables, ensure that they only include the characters also supported by policy variables. Supported characters are: If your tag namespaces or tag keys have characters other than these, you cannot use them in policy variables. Tag namespaces and tag keys cannot be renamed, so you will have to create new tag namespaces and tag key definitions. |
|
Considerations for case |
When working with tags in policies, be aware that tag values are case insensitive. |
|
Compartment hierarchies |
When you write a condition to allow access based on the tag applied to a target compartment, remember that this policy also allows access to all compartments nested inside the tagged compartment. All subcompartments in the tagged compartment are resources in the tagged compartment, and therefore the policy grants access. |
|
Supported services |
All services support the
Not all services support the
|
Example Using Tags Applied to a Group
Following is an example that demonstrates how you can use tags applied to user groups to manage access to resources in a compartment.
Assume you have three compartments: ProjectA, ProjectB, and ProjectC. For each compartment, there is an admin group set up: A-Admins, B-Admins, and C-Admins. Each admin group has full access over their compartment through the following policies:
allow group A-Admins to manage all-resources in compartment ProjectA allow group B-Admins to manage all-resources in compartment ProjectB allow group C-Admins to manage all-resources in compartment ProjectC
Your organization has set up the following tag namespace and key to tag each group
by its role: EmployeeGroup.Role. Some values for this tag are
'Admin', 'Developer', 'Test-Engineer'. All your admin groups are tagged with
EmployeeGroup.Role='Admin'.
Now you want to set up a Test compartment for members of the three projects to share. You want to give Admin access to all three of your existing admin groups. To accomplish this, you can write a policy like:
allow any-group to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
With this policy, all of your existing admin groups with the tag will have access
to the Test compartment. Also, any new or existing groups that you tag with
EmployeeGroup.Role='Admin' in the future will have access to
the Test compartment without having to update the policy statements.
Example Using Tags Applied to a Target Resource's Compartment
In this example, each of your organization's project compartments contains two
child compartments: Test and Prod. You want to give your test engineers access to
the test compartments across all three projects. To accomplish this, you create a
tag, ResourceGroup.Role='Test', and apply this to the Test
compartments in each of your project compartments.
To allow your group Testers to access the resources across all three test compartments, you can then use a policy like:
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'