--- name: secure-enterprise-known-issues title: Known issues and limitations description: Known issues and limitations include configuration management, user access to projects, and identity and access management (IAM) limits. last-updated: 2026-05-01 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/secure-enterprise?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Known issues and limitations {: #known-issues} Known issues and limitations include configuration management, user access to projects, and identity and access management (IAM) limits. {: shortdesc} To review the default IAM limits for your enterprise, see [Enterprise limits](https://cloud.ibm.com/docs/enterprise-management?topic=enterprise-management-what-is-enterprise&format=markdown#enterprise-limit). To review the default limits for an account, see [IBM Cloud IAM limits](https://cloud.ibm.com/docs/iam?topic=iam-cloudaccess&format=markdown#iam_limits). {: note} ## Authorization {: #auth-known-issue} 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](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-access-project&format=markdown). 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](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-tp-project&format=markdown), but some services such as IBM Cloud Kubernetes Service and GitLab don't support trusted profiles. [API keys continue to be supported](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-authorize-project&format=markdown), but a trusted profile is the preferred method for authorizing deployment to target accounts. ## Configuration management {: #configuration-known-issue} 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-estimate-known-issue} 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](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-cost-estimate-project&format=markdown). ## Access policy version limitations {: #policy-version-limit} 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 {: #policy-string-comparison} 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](https://cloud.ibm.com/docs/account?topic=account-known-issues&format=markdown#compare-syntax). For example use cases of the operators, see [Resource attribute-based conditions](https://cloud.ibm.com/docs/account?topic=account-iam-condition-properties&interface=ui&format=markdown#resource-based-conditions). You can have up to 10 conditions and nesting up to 2 levels. {: important} | 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. | {: caption="The string comparison operators available for conditions in access policies." caption-side="top"} 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`. ```json "resource": { "attributes": [ { "operator": "stringEquals", "value": "0aeab68aabd14d89bd72e4330150710a0", "key": "accountId" }, { "value": "messagehub", "operator": "stringEquals", "key": "serviceName" }, { "value": "messagehub-topic-dev*", "operator": "stringMatch", "key": "resource" } ] } ``` {: codeblock} [Authorization policies](https://cloud.ibm.com/docs/iam?topic=iam-serviceauth&format=markdown) are currently only supported in `/v1/policies`. {: note} ### Checking a policy version in the console {: #check-policy-version} 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](https://cloud.ibm.com/docs/account?topic=account-known-issues&format=markdown#update-policy-version). 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)**. 1. Select **Users**, **Trusted profiles**, **Service IDs**, or **Access groups**, depending on the policy you want to check. 1. Select a specific users, trusted profile, service ID, or access group. 1. Go to **Access** > **Access policies**. 1. Click on a policy. `/v1/policies` are indicated by the following notification: `Conditions unavailable for v1 policies` 1. (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 {: #update-policy-version} 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}](https://cloud.ibm.com/apidocs/iam-policy-management#replace-v2-policy) with the V1 ID and any conditions you want to include. For more information, see [`/v2/policies`](https://cloud.ibm.com/docs/account?topic=account-known-issues&format=markdown#v2-policies). ### Comparing `/v1/policies` and `/v2/policies` syntax {: #compare-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. {: tip} #### `/v1/policies` {: #v1-policies} ```json { "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" } ] } ] } ``` {: codeblock} 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](https://cloud.ibm.com/docs/account?topic=account-known-issues&format=markdown#placeholder-v2) {: note} #### `/v2/policies` {: #v2-policies} ```json { "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" } ] } } ``` {: codeblock} #### `/v1/policies` returns a placeholder for `/v2/` policies {: #placeholder-v2} 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/`. For example, see the following placeholder policy: ```json { "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" } ``` {: codeblock} ## Drift detection limits {: #drift-detection-known-issue} 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](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-manage-drift&format=markdown).