IBM Cloud Docs
Assigning access by using wildcard policies

Assigning access by using wildcard policies

When you're assigning access to certain IAM-enabled services, you can use advanced operators in a policyA method for granting users, service IDs, and access groups access to account resources. An access policy includes a subject, target, and role. to grant access to resources that satisfy specific naming conventions. By using wildcard policies, you can reduce the number of policies that are required for managing access to some resources.

To assign access, you need the administrator role on the resource. For more information, see IAM access.

JSON policy document

Most access policies are stored in IBM Cloud® as JSON documents. When you use the stringEquals operator in a policy, an exact string match is performed between the query and the target string. When you use the stringMatch operator, a case-sensitive string match is performed between the pattern and the target string using either an asterisk (*), question mark (?), both, or literal values. An asterisk (*) represents any sequence of zero or more characters in the string, and a question mark (?) represents any single character. See the following examples:

  • *dev* matches any string that contains dev
  • dev* matches any string that begins with dev
  • *dev matches any string that ends with dev

Refer to the documentation for the specific service that you are assigning access to for details about the supported operators for specific attributes for that service.

Using an asterisk (*) as a wildcard

The following example shows how you might create a policy that gives a user access to manage all Event Streams topics that start with dev in a particular account.

{
    "type": "access",
    "subjects": [
        {
            "attributes": [
                {
                    "name": "iam_id",
                    "value": "IBMid-12345"
                }
            ]
        }
    ],
    "roles": [
        {
            "role_id": "crn:v1:bluemix:public:iam::::serviceRole:Manager"
        }
    ],
    "resources": [
        {
            "attributes": [
                {
                    "name": "accountId",
                    "value": "d727f71e99b14534b3267fab8cc9b09a"
                },
                {
                    "name": "serviceName",
                    "value": "messagehub"
                },
                {
                    "name": "resourceType",
                    "value": "topic"
                },
                {
                    "name": "resource",
                    "operator": "stringMatch",
                    "value": "dev*"
                }
            ]
        }
    ]
}

Using a question mark (?) as a wildcard

The following example shows how you can create a policy that gives a user access to edit any Event Streams topic that ends in a particular pattern.

On the line "value": "*??81", the * indicates zero or more characters and matches any string that ends with ??81. The ? represents a single character. Since there are two ??, the resulting pattern matches a string of four or more characters that end in 81.

{
    "type": "access",
    "subjects": [
        {
            "attributes": [
                {
                    "name": "iam_id",
                    "value": "IBMid-12345"
                }
            ]
        }
    ],
    "roles": [
        {
            "role_id": "crn:v1:bluemix:public:iam::::serviceRole:Writer"
        }
    ],
    "resources": [
        {
            "attributes": [
                {
                    "name": "accountId",
                    "value": "d727f71e99b14534b3267fab8cc9b09a"
                },
                {
                    "name": "serviceName",
                    "value": "messagehub"
                },
                {
                    "name": "resourceType",
                    "operator": "stringEquals"
                    "value": "topic",
                },
                {
                    "name": "resource",
                    "operator": "stringMatch",
                    "value": "*??81"
                }
            ]
        }
    ]
}

Using an asterisk (*) and question mark (?) as a literal character

You can express an asterisk (*) and question mark (?) as a literal character, ensuring that they aren't interpreted as a wildcard by enclosing each within two sets of curly brackets {{}}.

The following example shows how you can create a policy that gives a user access to edit an Event Streams topic that contains the literal characters * and ?. The topic must end with the pattern .?.log, implying any single character between the periods . followed by the log string.

{
    "type": "access",
    "subjects": [
        {
            "attributes": [
                {
                    "name": "iam_id",
                    "value": "IBMid-12345"
                }
            ]
        }
    ],
    "roles": [
        {
            "role_id": "crn:v1:bluemix:public:iam::::serviceRole:Writer"
        }
    ],
    "resources": [
        {
            "attributes": [
                {
                    "name": "accountId",
                    "value": "d727f71e99b14534b3267fab8cc9b09a"
                },
                {
                    "name": "serviceName",
                    "value": "messagehub"
                },
                {
                    "name": "resourceType",
                    "operator": "stringEquals"
                    "value": "topic",
                },
                {
                    "name": "resource",
                    "operator": "stringMatch",
                    "value": "dev-topic-{{*}}-{{?}}.?.log"
                }
            ]
        }
    ]
}

On the line "value": "dev-topic-{{*}}-{{?}}.?.log", the {{*}} indicates the character * and the {{?}} indicates the character ?. Therefore, a topic such as dev-topic-*-?.1.log matches this pattern.

The following two examples represent the same evaluation where a case-sensitive string comparison of dev* is performed.

{
    "name": "resource",
    "operator": "stringMatch",
    "value": "dev{{*}}"
}

{
    "name": "resource",
    "operator": "stringEquals",
    "value": "dev*"
}

String comparisons

The following table lists the string comparison operators that you can use to build access policies with /v2/policies syntax. For more information about each version, see Comparing /v1/policies and /v2/policies syntax. For example use cases of the operators, see Resource attribute-based conditions.

The string comparison operators available for conditions in access policies.
Operator Description
stringEquals Case-sensitive string comparison. Boolean or number values are converted into a string before comparison.
stringMatch Case-sensitive string match is performed between the pattern and the target string by using either an asterisk (*), question mark (?), both, or none (same as literal value). An asterisk (*) represents any sequence of zero or more characters in the string, and a question mark (?) represents any single character. You can also express an asterisk * and question mark ? as a literal value by enclosing each within two sets of curly brackets {{}}.
stringExists Boolean where true indicates that the string must be present and can be empty. false indicates that the string must not be present.
stringEqualsAnyOf Case-sensitive exact string matching any of the strings in an array of strings. Limit of 10 values.
stringMatchAnyOf Case-sensitive string matching any of the strings in an array of strings. The string values can include either an asterisk (*), question mark (?), both, or none (same as literal value). An asterisk (*) represents any sequence of zero or more characters in the string, and a question mark (?) represents any single character. You can also express an asterisk * and question mark ? as a literal value by enclosing each within two sets of curly brackets {{}}. Limit of 10 values.