Conditions
The optional conditions element of a policy statement limits access based on the provided attributes in IAM.
A condition returns resources based on specified parameters. For example, use a condition to return resources that have certain characters in their names.
Syntax for a single condition: variable =|!= value
Syntax for multiple conditions: any|all {<condition>,<condition>,...}
To create a logical OR for a set of conditions, use any
. To create a logical AND for a set of conditions, use all
.
Condition matching ignores case-sensitive names. For example, a condition for a bucket named "BucketA" also matches a bucket named "bucketA."
- String:
'johnsmith@example.com'
'ocid1.compartment.oc1.exampleuniqueID'
(single quotation marks are required around the value)
- Pattern:
-
/hr*/
(matches strings that start with "hr") -
/*hr/
(matches strings that end with "hr") -
/*hr*/
(matches strings that contain "hr")
-
In the following examples, the statements that specify the condition don't let GroupAdmins list all the users and groups. Statements including the
inspect
verb are added for completeness. See Variables Not Applicable to a Request Result in a Declined Request.Examples:
- Single condition:
Single condition for one resource type (groups)
Allow group GroupAdmins to manage groups in tenancy where target.group.name = /A-Users-*/ Allow group GroupAdmins to inspect groups in tenancy
Single condition for many resource types (users and groups)
Allow group GroupAdmins to inspect users in tenancy
Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to inspect groups in tenancy
Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'
Many conditions for one resource (groups)
Allow group NetworkAdmins to manage virtual-network-family in tenancy where target.compartment.id != 'ocid1.compartment.oc1.exampleuniqueID'
- Several conditions
The following policy lets GroupAdmins create, update, or delete any groups whose names start with "
A-
", except for theA-Admins
group itself:Allow group GroupAdmins to manage groups in tenancy where all {target.group.name=/A-*/,target.group.name!='A-Admins'} Allow group GroupAdmins to inspect groups in tenancy
Variables Not Applicable to a Request Result in a Declined Request
If the variable is not applicable to the incoming request, the condition evaluates the request as false and the request is declined. For example, here are some basic policy statements that together let someone add or remove users from any group except Administrators:
Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group GroupAdmins to use groups in tenancy where target.group.name != 'Administrators'
If a user in GroupAdmins tried to call a general API operation for users, such as ListUsers
or UpdateUser
(which lets you change the user's description), the request is declined, even though those API operations are covered by use users
. The example policy statement for use users
includes a target.group.name
variable, but the ListUsers
or UpdateUser
request doesn't specify a group. The request is declined because a target.group.name
wasn't provided.
To grant access to a general user when an API operation doesn't involve a particular group, you need to add another statement that gives the level of access that you want to grant but doesn't include the condition. For example, to grant access to ListUsers
, you need a statement similar to this statement:
Allow group GroupAdmins to inspect users in tenancy
To grant access to UpdateUser
, you need this statement (which also covers ListUsers
because the use
verb includes the capabilities of the inspect
verb):
Allow group GroupAdmins to use users in tenancy
This general concept also applies any other resource type with target variables, for example, ListGroups.
Tag-Based Access Control
Use conditions and a set of tag variables to write policies that define access based on the tags applied to a resource. You can control access based on a tag that exists on the requesting resource (the group or dynamic group in the policy), or on the target of the request (resource or compartment). Tag-based access control provides flexibility to policies, letting you define access that spans compartments, groups, and resources. For details about how to write policies to scope access by tags, see Using Tags to Manage Access.