This topic describes how you can use tags in policy to scope access based on tags applied to either the requestor or the target of an authorization call.
About 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 (group, dynamic group, or compartment) or on the target of the request (resource or compartment). 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 a policy that specifies a tag on either a target or a requestor, ensure that you are aware of:
all the potential requestors (users, groups, dynamic groups) that carry the tag
all the 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.
Managing Access Using Tags Applied to the Requesting Resource 🔗
You can control access based on the value of a tag applied to:
a group (of users) requesting access
a dynamic group (of instances) requesting access
a compartment that a resource in a dynamic group 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 basic syntax for each variable is shown in the following table. Note that the syntax is the same for group and dynamic group, but each is presented in a different row. See Supported Operators more usage examples.
allow dynamic-group InstancesA to manage instances in compartment HR where request.principal.group.tag.Operations.Project= 'Prod'
Instances that are members of the dynamic group InstancesA and that are also members of a dynamic group tagged with Operations.Project='Prod' can manage instances in the compartment HR.
The tags applied to the dynamic groups that the instance belongs to are evaluated for a match.
allow dynamic-group InstancesA to manage instances in tenancy where request.principal.compartment.tag.Operations.Project= 'Prod'
Instances that are members of the dynamic group InstancesA and that also reside in a compartment tagged with Operations.Project='Prod' can manage instances in the tenancy.
The tags applied to the compartment that the requesting resource belongs to are evaluated.
Note
Users reside in the root compartment of your tenancy, so tags must be applied to the root compartment for those policy statements to work.
Managing Access Using Tags Applied to the Target Resource 🔗
You can control access based on the value of a tag applied to:
a resource
a compartment that the target resource resides in
The basic syntax for these variables is shown in the following table. See Supported Operators for more usage examples.
Permissions to List a Resource Must Be Granted Separately 🔗
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. This means that if you have defined a policy like:
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA will not be able to list any of the resources that they are otherwise allowed to manage. Members of GroupA would not be able to use the Console to interact with these resources and users would need to know the OCID of the resource they are attempting to manage, which makes using the SDK and CLI cumbersome, also.
To allow GroupA to list those resources, you need to add another policy statement like:
allow group GroupA to inspect all-resources in compartment Operations
This approach improves the tag-based policy because it allows users to use the Console more easily (by allowing them to see the resource they want to manage), but still limits the permissions to only inspect. The members of GroupA cannot take any action on those resources unless they are tagged appropriately. Keep in mind when using tag-based access control that the added flexibility requires this additional potential expansion of access.
Another approach you can use to avoid this limitation is to tag the compartments that contain the resources you want to grant access to. An example policy looks like this:
Copy
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'
This policy allows the members of GroupA to manage all resources in the tenancy that are in compartments that are tagged with the Operations.Project='Prod' tag.
Policies that Require a Tag on the Target Resource Can't 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. 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. So a policy like:
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
allows the members of GroupA to use and delete instances that are tagged with Operations.Project='Prod', but they cannot create instances.
Supported Operators 🔗
Your policy using these tag variables can include these operators and match types:
Evaluates to true if any of the groups that the requestor belongs to is tagged with the matching value "sample" for MyTagNamespace.MyTag. (The value is case insensitive.)
Evaluates to true if neither side is a subset of the other.
In / Not In 🔗
Operator
Type
Example
Description
in
String
request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
The clause evaluates to true if any of the values of MyTagNamespace.MyTag for any group of the current requesting principal either equals to "sample" or "sample1".
Pattern
request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
The clause evaluates to true if any of the values of MyTagNamespace.MyTag for any group of the current requesting principal either ends with "sample" or starts with "sample1".
The clause evaluates to true if any of the following conditions are met:
1. Either request.principal.group.tag.MyTagNamespace.MyTag or target.resource.tag.mytagnamespace.mytag is a subset of the other.
2. Any string values of request.principal.group.tag.MyTagNamespace.MyTag equals "sample".
not in
String
request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
The clause evaluates to true if none of the values of MyTagNamespace.MyTag for any group of the current requesting principal equals to "sample" or "sample1".
Pattern
request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
The clause evaluates to true if none of the values of MyTagNamespace.MyTag for any group of the current requesting principal ends with "sample" or starts with "sample1".
Policy variable
request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
The clause evaluates to true if all of the following conditions are met:
1. Neither request.principal.group.tag.MyTagNamespace.MyTag nor target.resource.tag.mytagnamespace.my tag is a subset of the other.
2. None of the string values of request.principal.group.tag.MyTagNamespace.MyTag equals "sample".
Support for Wildcards 🔗
You can use the * character to match all occurrences of {tagNamespace}.{tagKeyDefinition} regardless of the value. In the policy, you can place * in single quotes '*' or between backslashes /*/ . For example,
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
In this example, GroupA can use all resources in the compartment HR that are tagged with the tag namespace and tag key: HR.Project with any value.
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:
a-z, A-Z, 0-9, _, @, -, :
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. For example:
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.
For example, in this scenario:
The policy:
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'
allows GroupA to use all the resources in CompartmentA, CompartmentA1, and
CompartmentA1.1, even though the tag is applied to CompartmentA only.
Supported Services 🔗
All Oracle Cloud Infrastructure services support the
request.principal.compartment, request.principal.group
, and target.resource.compartment.tag policy variables.
Not all services support the target.resource.tag policy variable. The following table lists the supported services. If the service is not listed in the table, it is not supported at this time.
Some services have limitations. See the appropriate link in the table.
Limitations and Additional Policies Needed for Specific Target.Resource.Tag Scenarios 🔗
For some services, not all permissions or resource types are supported. When a permission is not supported, that means that even if the resource is tagged and the permission is included in the verb granting access, that permission is not allowed and authorization fails for the operation governed by the permission. For example, the Block Volume service resource volume-backups, does not support tag-based access control for the VOLUME_BACKUP_COPY permission. Therefore, this policy:
Copy
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
does not allow members of the group TestGroup to perform the CopyVolumeBackup operation. To grant that permission to TestGroup, you would need to add another policy statement to cover it.
In addition, some operational scenarios require authorization to access multiple resources. When scoping access to tags that are applied to the target resource, you must include a separate policy for each resource involved in the operation. Also, because of the limitations for listing resources and other service-specific permissions, additional policies (not scoped by tag) are required.
API Gateway Service Limitations 🔗
In addition to the expected tag-based access control policy for API Gateway resources, you'll need policy allowing manage permissions for api-workrequests.
Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage api-workrequests in compartment Compartment1
Big Data Service Limitations 🔗
In addition to the expected tag-based access control policy for Big Data Service resources, you'll need policy allowing manage permissions for cluster-work-requests.
Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage cluster-work-requests in compartment Compartment1
Block Volume Service Limitations 🔗
Service
Resource Type with Limitations
Permissions Not Supported with the target.resource.tag Policy Variable
Block Volume
backup-policy-assignments
BACKUP_POLICY_ASSIGNMENT_DELETE
volume-backups
VOLUME_BACKUP_COPY
Scenarios requiring additional policy:
Attach a block volume to a compute instance:
To attach a block volume to a compute instance, in addition to the tag-based access control policy to allow the use verb on volumes and instances, you'll need some additional permissions.
For example:
Copy
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
These two policies allow members of TestGroup to use volumes and instances in Compartment1, when the resources have the appropriate tag. To allow members to attach a block volume to an instance, you'll also need policies that allow the permissions shown in the following statements:
Copy
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}
Compute Service Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
Compute
instance-console-connection
INSTANCE_CONSOLE_CONNECTION_DELETE
instances
INSTANCE_POWER_ACTIONS
Scenarios requiring additional policy:
Attach compute instance to subnet:
To manage a compute instance's subnet attachment, in addition to the expected tag-based access control policy for instances and subnets, shown here:
Copy
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
You'll need additional permissions on vnics:
Copy
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}
Delete a VNIC from a compute instance:
To delete a VNIC from a compute instance, in addition to the expected tag-based access control policy for instances and subnets shown here:
Copy
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
You'll need policy allowing you permissions on vnics:
Copy
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
Compute Management Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
Notes
Compute Management
instance-pools
All permissions
The instance-pools resource type is not supported.
auto-scaling-configurations
AUTO_SCALING_CONFIGURATION_UPDATE
.
Content Management Limitations 🔗
In addition to the expected tag-based access control policy for Content Management resources, you'll need policy allowing manage permissions for oce-work-requests.
Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage oce-requests in compartment Compartment1
Database Service Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
Database
all
DATABASE_DELETE
Update Tags for ExaData Infrastructure:
Not supported at this time using tag-based access control policies.
Scenarios requiring additional policy:
Delete a DB-System:
To delete or update a DB-System, in addition to the expected tag-based access control policy for db-systems, shown here:
Copy
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll need policy allowing you permissions for db-backups, db-homes, vnics, subnets and databases. Here is an example policy showing the additional permissions:
Copy
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1
Move a DB-system to another compartment:
To move a DB-System to another compartment, in addition to the expected tag-based access control policy for db-systems shown here:
Copy
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll need policy allowing you permissions for databases, db-homes, and db-backups. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'
Database delete for Exadata DB-System:
To delete a database resource for an Exadata DB-System, you'll need the expected tag-based access control policy for db-systems and databases shown here:
Copy
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll also need permissions for db-homes and db-backups. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
Delete Database:
Deleting a database for a baremetal or virtual machine DB system is not supported using tag-based policies on the target resource.
Database backup create:
To create a database backup, you'll need the expected tag-based access control policy for databases:
Copy
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll also need permissions for db-backups. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'
Database restore:
To restore a database backup, you'll need the expected tag-based access control policy for databases:
Copy
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll also need permissions for backups, like the one shown here:
Copy
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}
Create Data Guard association:
Creating a Data Guard association is not supported using tag-based policies on the target resource.
Data Catalog Service Limitations 🔗
In addition to the expected tag-based access control policy for Data Catalog resources, you'll need the following additional policies for data-catalog-family:
Copy
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'
Data Science Service Limitations 🔗
In addition to the expected tag-based access control policy for Data Science resources, you'll need policy allowing manage permissions for data-science-work-requests.
Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage data-science-work-requests in compartment Compartment1
Digital Assistant Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
Digital Assistant
oda-design
All permissions
oda-insights
All permissions
In addition to the expected tag-based access control policy for the Oracle Digital Assistant resources, you'll need the following additional policies for oda-instances:
Copy
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'
Load Balancing Service Limitations 🔗
Scenarios requiring additional policy:
Update Load Balancer:
To perform any update to load balancers, in addition to the expected tag-based access control policy for load-balancers:
Copy
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll need policy that allows the GetWorkRequest API operation. Here is an example policy with the additional permission:
Copy
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-group
Delete Load Balancer:
To delete a load balancer, in addition to the expected tag-based access control policy for load-balancers, subnets, and network-security-group:
Copy
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
You'll need these additional permissions for vnics :
Copy
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}
Networking Service Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
Notes
Networking
private-ips
PRIVATE_IP_UPDATE
PRIVATE_IP_DELETE
VNIC_UNASSIGN
SUBNET_DETACH
route-tables
UPDATE (INTERNET_GATEWAY_DETACH)
Removing a route rule is not supported.
vnics
VNIC_UPDATE
VNIC_DELETE
Attach service gateway or NAT gateway to a route table:
Attaching a service gateway or a NAT gateway to a route table is not supported using tag-based policies on the target resource.
Scenarios requiring additional policy:
Attach DRG to VCN:
To attach DRG to VCN, in addition to the following expected tag-based access control policy for virtual-network-family and vcns:
Copy
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
You'll need policy allowing you manage permissions for drgs. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage drgs in compartment Compartment1
NoSQL Database Cloud Service Limitations 🔗
Supported resources are: nosql-tables, nosql-rows, and nosql-indexes.
In addition to the expected tag-based access control policy for the NoSQL Database Cloud resources, you'll need these additional policies:
Copy
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'
Copy
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'
Copy
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'
Note that the preceding policies are required to navigate the NoSQL Database Cloud resources in the Console.
Object Storage Service Limitations 🔗
Service
Resource Type
Permissions Not Supported with the target.resource.tag Policy Variable
In addition to the expected tag-based access control policy for dns resources, you'll need policy allowing you manage permissions for dns-records. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage dns-records in compartment Compartment1
Tagging Namespace Limitations 🔗
Policy that grants a user access to a tag namespace based on a tag on the namespace does not allow the user to create or delete tag key definitions in that tag namespace.
For example, the policy:
Copy
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'
does not allow the users in TestGroup to create or delete tag key definitions in the tag namespaces tagged with TagNS.TagKey='test'.
WAF Limitations 🔗
In addition to the expected tag-based access control policy for the WAF resources, you'll need policy allowing you manage permissions for waas-work-request. Here is an example policy with the additional permissions:
Copy
allow group TestGroup to manage waas-work-request in compartment Compartment1
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-user 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 🔗
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.
You can then use a policy like:
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
to allow your group Testers to access the resources across all three test compartments.