IBM Cloud Docs
Known issues and limitations

Known issues and limitations

Known issues and limitations include configuration management, user access to projects, and identity and access management (IAM) limits.

Authorization

To work in a project, users must have access to the IBM Cloud Projects service, the resource group for the project, and IBM Cloud® Schematics. For more information about access, see Assigning users access to projects.

Authorizing projects to deploy to a target account is managed by passing an API key into the deployable architecture. Projects can be directly authorized by using a trusted profile, but trusted profiles are not currently supported by all services. API keys will continue to be supported, but a trusted profile is the preferred method for authorizing deployment to target accounts.

Configuration management

Configurations can be added, deleted, and renamed. Moving a configuration between projects must be done manually by editing project.json documents on both projects. If there are multiple configurations in a project, they can be organized only by naming conventions.

Cost estimate

Cost estimation is available for deployable architectures in the IBM Cloud catalog. Depending on the deployable architecture, a starting cost is estimated based on the available data. This estimated amount is subject to change as the architecture is customized within a project, and it does not include all resources, usage, licenses, fees, discounts, or taxes. For more information, see Estimating architecture costs in a project.

API, SDK, and Terraform

The projects API, SDK, and Terraform functionalities are beta for this release. Beta products are made solely available for evaluation and testing purposes. There are no warranties, SLAs, or support provided and beta products are not intended for production use.

undefined

undefined

Enterprise limits

The following table lists the maximum limits for IBM Cloud enterprises. These limits apply to any user who can create an enterprise, add accounts to an enterprise, or create and update account groups.

Enterprise limits
Resource Max
Account groups per enterprise 500
Accounts per enterprise 1000

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

{{site.data.content.string-compare-intro-reuse}}

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

{{site.data.content.string-compare-table-reuse}}

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"
}

Drift detection limits

Schematics and Terraform can detect a drift only between a changed resource and the specific configuration that created that resource during deployment. The service can’t detect drift in reused or referenced resources.

For example, in a specific scenario, configuration config-1 created a Cloud Object Storage instance during deployment. Later, you deployed configurations config-2 and config-3, and they reused the same Cloud Object Storage instance. When you renamed the resource, drift was detected only between config-1 and the renamed Cloud Object Storage instance. config-2 and config-3 failed the drift detection job because drift can be detected only between a configuration and the resource that it created, not reused.

For more information, see Managing drift.