Known issues and limitations
Known issues and limitations include not being able to restrict access to some products in the IBM Cloud® catalog, and the maximum limits for creating IBM Cloud Identity and Access Management (IAM) resources.
Google login doesn't support federated IDs
Google ID login isn't available for users with federated IDs due to additional access that might be required by their corporate external identity provider (IdP).
Catalog management settings don't apply to some IBM products
Some products are not affected by the following catalog visibility settings:
- Turning off the visibility of the IBM Cloud catalog
- Excluding all IBM Cloud products from the catalog
- Excluding all IBM Cloud products from your private catalogs
You can view and manage catalog visibility settings by going to Manage > Catalogs > Settings in the IBM Cloud console.
Users can still create instances of the following products by using an API or the CLI, regardless of the catalog visibility setting in the account or private catalog:
- Block Storage for VPC
- Citrix Netscaler VPX
- Fortigate Security Appliance
- Hardware Firewall
- Hardware Firewall Dedicated
- IBM Cloud Backup for Classic
- IBM Cloud Bare Metal Servers
- IBM Cloud Block Storage for Classic
- IBM Cloud Container Registry
- IBM Cloud Content Delivery Network
- IBM Cloud Direct Link
- IBM Cloud Direct Link on Classic
- IBM Cloud Functions
- IBM Cloud Gateway Appliance
- IBM Cloud Hardware Security Modules
- IBM Cloud Kubernetes Service
- IBM Cloud Object Storage
- IBM Cloud Schematics
- IBM Cloud Load Balancer
- IBM Cloud Virtual Servers
- Subnets and IPs
- Virtual Private Cloud
- Virtual Server for VPC
- VLANs
- VPN
- VPN for VPC
Policy limitations based on attributes
Access management tags are available only when you create an access policy that is scoped for all IAM-enabled services. In this case, when you enable the access based on tags, no other attributes can be added. And, when you base your policy on a specific location or resource group, no tag can be added to the access policy.
Access policy version limitations
As of 25 January 2023, IAM supports two versions of the IAM Policy Management API: /v2/policies
and /v1/policies
. v1/polices
allows for string comparisons against attributes in the subject and resources
of a policy. v2/polices
introduces a new schema that provides backwards functional compatibility while allowing for more complex comparisons and operators and time based conditions.
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.
You can have up to 10 conditions and nesting up to 2 levels.
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. |
For example, the following statement contains an operator
element that uses stringEquals
to specify that the account ID and service name must exactly match the value
element. The statement also contains
an operator
element that uses stringMatch
to specify a naming pattern for Event Streams topics that you might use to organize access to those specific resources. This way, you can assign one policy to all topics
in your account that begin with messagehub-topic-dev
.
"resource": {
"attributes": [
{
"operator": "stringEquals",
"value": "0aeab68aabd14d89bd72e4330150710a0",
"key": "accountId"
},
{
"value": "messagehub",
"operator": "stringEquals",
"key": "serviceName"
},
{
"value": "messagehub-topic-dev*",
"operator": "stringMatch",
"key": "resource"
}
]
},
Authorization policies are currently only supported in /v1/policies
.
Checking a policy version in the console
Time-based and resource attribute-based conditions for IAM access policies use /v2/policies
syntax. Policies that use /v1/policies
syntax aren't eligible to add time-based and resource attribute-based conditions.
To update /v1/policies
to /v2/policies
by using the API, see Updating /v1/policies
to /v2/policies
with conditions by using the API.
To check whether you can add these conditions to an existing policy in the console, complete the following steps.
-
Go to Manage > Access (IAM).
-
Select Users, Trusted profiles, Service IDs, or Access groups, depending on the policy you want to check.
-
Select a specific users, trusted profile, service ID, or access group.
-
Go to Access > Access policies.
-
Click on a policy.
/v1/policies
are indicated by the following notification:Conditions unavailable for v1 policies
-
(Optional) To add conditions to a policy that uses
/v1/policies
syntax, delete the original policy and create a new one. In the console, new policies use/v2/policies
syntax.
Updating /v1/policies
to /v2/policies
with conditions by using the API
Policies that use /v1/policies
syntax aren't eligible to add time-based and resource attribute-based conditions. To update the version, you can use the PUT /v2/policies/{id} with the V1 ID and any conditions you want to include. For more information, see /v2/policies
.
Comparing /v1/policies
and /v2/policies
syntax
The policy in each example grants a user access to the Billing service with the Editor role. The /v2/policies
example includes temporary time-based conditions, indicated by the "conditions"
parameter.
When editing, creating, and deleting policies, use the corresponding API version.
/v1/policies
{
"type": "access",
"roles": [
{
"role_id": "crn:v1:bluemix:public:iam::::role:Editor"
}
],
"resources": [
{
"attributes": [
{
"name": "accountId",
"value": "000c49bc2724a07000010b1da94c4d0"
},
{
"name": "serviceName",
"value": "billing"
}
]
}
],
"subjects": [
{
"attributes": [
{
"name": "iam_id",
"value": "IBMid-00000AV0S0"
}
]
}
]
}
When you list policies with /v1/policies
the API returns /v1/
and a placeholder policy for each /v2/
policy that's in the account. For more information, see /v1/policies
returns a placeholder for /v2/
policies the account
/v2/policies
{
"type": "access",
"control": {
"grant": {
"roles": [
{
"role_id": "crn:v1:bluemix:public:iam::::role:Editor"
}
]
}
},
"resource": {
"attributes": [
{
"operator": "stringEquals",
"value": "000c49bc2724a07000010b1da94c4d0",
"key": "accountId"
},
{
"value": "billing",
"operator": "stringEquals",
"key": "serviceName"
}
]
},
"rule": {
"operator": "and",
"conditions": [
{
"key": "{{environment.attributes.current_date_time}}",
"operator": "dateTimeGreaterThanOrEquals",
"value": "2023-01-01T09:00:00+00:00"
},
{
"key": "{{environment.attributes.current_date_time}}",
"operator": "dateTimeLessThanOrEquals",
"value": "2023-01-06T17:59:59+00:00"
}
]
},
"pattern": "time-based-conditions:once",
"subject": {
"attributes": [
{
"key": "iam_id",
"operator": "stringEquals",
"value": "IBMid-00000AV0S0"
}
]
}
}
/v1/policies
returns a placeholder for /v2/
policies
When you list policies with /v1/policies
the API returns /v1/
and a placeholder policy for each /v2/
policy that's in the account. The placeholders indicate the existence of additional policies in the
account while abiding by the /v1/
schema. To see the full content of a /v2/
policy, list policies by using /v2/policies
or retrieve the individual policy by using GET: v2/policies/<ID>
.
For example, see the following placeholder policy:
{
"id": "33b901fa-8ec5-4432-a2e6-24b6a212c20a",
"type": "access",
"description": "**This is a unsupported policy version placeholder, to view the full content, please call GET with provided href**",
"subjects": [{
"attributes": [{
"name": "iam_id",
"value": "unsupported version"
}]
}],
"roles": [{
"role_id": "crn:v1:bluemix:public:iam::::role:UnsupportedVersion",
"display_name": "Unsupported Version",
"description": "**This is a unsupported policy version placeholder, to view the full content, please call GET with provided href**"
}],
"resources": [{
"attributes": [{
"name": "accountId",
"value": "000c49bc2724a07000010b1da94c4d0"
}]
}],
"href": "https://iam.cloud.ibm.com/v2/policies/88b901fa-6ec5-888-a2e6-24b6a212c20a"
}