IBM Cloud Docs
Known issues and limitations

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.

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

IBM Cloud IAM limits

The following table lists the maximum limits for IAM resources. These limits apply to any user who can create IAM resources. If a limit is exceeded, you receive an exception and are not allowed to create any new resources beyond that limit.

If you have a specific use case that requires an extended limit, you can request an increase. For more information, see Increasing account limits.

Table 1. IAM account limits
Resource Max
Access groups per account 500
Access groups per user 50
Access group templates per enterprise account 100
Access management tags per account 250
Account settings templates per enterprise account 10
API Keys per identity 20
Custom roles per account 40
Dynamic rules per access group 5
Dynamic rules per trusted profile 20
Dynamic rules per Identity provider (IdP) 2000
IdPs per account 5
Policies per account [1] 4020
Policies per subject within an account 1000
Policies with access management tags within an account 500
Policy templates per enterprise account 500
Service IDs per account 2000
Trusted profiles per account 2000
Trusted profile templates per enterprise account 100
Users per trial account 100
Users per billable account 7500
Versions per enterprise-managed tempalte 100

A maximum of 1,000 policies and service to service authorizations within one account is recommended to ensure optimal performance within your account. For more information about limiting the number of policies in your account, see the Best practices for organizing resources and assigning access.

If you want to check the number of policies in your account, see Viewing the total number of policies per account. To request an increase in the account limit, see Requesting a policy and rule shared limit increase.

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.

Trusted profile limitations

Users can't use the Support Center when they log in to IBM Cloud by applying a trusted profile.

Enterprise-managed IAM limitations

See the following sections for details about limitations for enterprise-managed IAM templates. For more information about enterprise-managed IAM, see How enterprise-managed IAM works.

You can't assign an IAM template to the enteprise account, only child accounts.

Settings templates

Only one settings template can be assigned in an enteprise. You can assign multiple versions of the template, but not different templates.

Policy templates

You can create access policy templates without an explicit subject by using the CLI or API, but using the IBM Cloud console to complete this task is not supported.

When you assign access to an access group template or a trusted profile template in the console, a policy template is automatically created based on the policy that you assign. Go to Manage > Access (IAM) > Templates > Policies to view the policy templates.

Context-based restrictions limits

The following table lists the maximum limits for context-based restrictions. These limits apply to any user who can create context-based restrictions rules or network zones. For more information, see What are context-based restrictions?.

If you have a specific use case that requires an extended limit, you can request an increase. For more information, see Increasing account limits.

Table 2. Context-based restrictions limits
Resource Max
Context-based restriction rules per account [2] 4020
Network zones per account 500
IP addresses per network zone 1000
IP addresses per rule 1000

A context-based restriction rule that includes multiple network zones can have a maximum of 1000 IP addresses indirectly associated with it. For example, in a rule that includes two network zones, one of the zones might have 800 IP addresses and the other might have a maximum of 200 IP addresses.

If you want to check the number of rules in your account, see Viewing the total number of rules per account. To request an increase in the account limit, see Requesting a policy and rule shared limit increase.

Eventual consistency

Context-based restrictions follow an eventually consistent pattern that is common to many cloud-native services. As a result, Context-based restrictions remain highly available and performant across multiple global regions. Changes that are made to Context-based restrictions rules and network zones are recorded and propagated worldwide. Access changes might not take effect until the propagation process is complete, usually within a few minutes.

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.

You can have up to 10 conditions and nesting up to 2 levels.

Table 3. 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 (?), or both. 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 String must be true.
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 values can include a multi-character wildcard (*), which matches any sequence of zero or more characters, a single-character wildcard (?), matching any single character, or both. 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.

  1. Go to Manage > Access (IAM).

  2. Select Users, Trusted profiles, Service IDs, or Access groups, depending on the policy you want to check.

  3. Select a specific users, trusted profile, service ID, or access group.

  4. Go to Access > Access policies.

  5. Click on a policy. /v1/policies are indicated by the following notification:

    Conditions unavailable for v1 policies

  6. (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"
}

  1. IAM policies and context-based restrictions rules share a combined limit of 4020. ↩︎

  2. IAM policies and context-based restrictions rules share a combined limit of 4020. ↩︎