- What's New
- Service Overview
- Getting Started
-
User Guide
- Permissions Management
- Managing Organizations
- Managing OUs
- Managing Accounts
-
Managing SCPs
- Overview of an SCP
- Enabling or Disabling the SCP Type
- Creating an SCP
- Modifying or Deleting an SCP
- Attaching or Detaching an SCP
- Example SCPs
- System-defined SCPs
- Cloud Services for Using SCPs
- Regions for Using SCPs
-
Actions Supported by SCP-based Authorization
- Compute
- Storage
- Networking
- Containers
- Analytics
- Content Delivery & Edge Computing
- Databases
- Security & Compliance
- Internet of Things
- Middleware
- Developer Services
- Business Applications
-
Management & Governance
- Simple Message Notification (SMN)
- Log Tank Service (LTS)
- Identity and Access Management (IAM)
- Security Token Service (STS)
- Resource Formation Service (RFS)
- IAM Identity Center
- Organizations
- Resource Access Manager (RAM)
- Enterprise Project Management Service (EPS)
- Tag Management Service (TMS)
- Config
- IAM Access Analyzer
- Cloud Trace Service (CTS)
- Resource Governance Center (RGC)
- Application Operations Management (AOM)
- Cloud Eye (CES)
- IAM Identity Broker
- User Support
- Migration
- Managing Tag Policies
- Managing Trusted Services
- Managing Tags
- CTS Auditing
- Adjusting Quotas
-
API Reference
- Before You Start
- API Overview
- Calling APIs
-
APIs
- Managing Organizations
- Managing OUs
-
Managing Accounts
- Creating an Account
- Listing Accounts in an Organization
- Closing an Account
- Getting Account Information
- Updating an Account
- Removing the Specified Account
- Moving an Account
- Inviting an Account to Join an Organization
- Querying Account Creation Requests in Specified State
- Querying Account Creation Status
- Querying CloseAccount Requests in Specified State
- Managing Invitations
- Managing Trusted Services
- Managing Delegated Administrators
- Managing Policies
-
Managing Tags
- Listing Tags for the Specified Resource
- Adding Tags to the Specified Resource
- Removing Tags from the Specified Resource
- Listing Tags for the Specified Resource Type
- Adding Tags to the Specified Resource Type
- Deleting Tags with the Specified Key from the Specified Resource Type
- Querying Resource Instances by Resource Type and Tag
- Querying Number of Resource Instances by Resource Type and Tag
- Querying Resource Tags
- Others
- Permissions and Supported Actions
- Appendixes
- Change History
- FAQs
- General Reference
Show all
Copied.
Tag Policy Syntax
Basic Syntax
The following tag policy shows basic tag policy syntax:
{ "tags": { "costcenter": { <!-- policy key --> "tag_key": { "@@assign": "CostCenter" <!-- tag key --> }, "tag_value": { "@@assign": [ "100", <!-- policy value --> "200" ] }, "enforced_for": { <!-- enforcement --> "@@assign": [ "apig:instance" <!-- service or resource type --> ] } } } }
- Policy key: A policy key uniquely identifies a policy statement. It must match the value for the tag key, except for the case treatment.
- Tag key: The value for the tag key must match the value for the policy key. But since the policy key value is case insensitive, the capitalization can be different. If the tag key is not defined, lowercase is the default case treatment for tag keys. In this example, costcenter is the policy key and CostCenter is the tag key, and CostCenter is the case treatment that is required for compliance with the tag policy. If the policy key is set to CostCenter and the tag key is not defined, the lowercase costcenter will be the case treatment required for tag compliance evaluation.
- Policy value: A list of one or more acceptable tag values for the tag key. If you do not specify tag values for a tag key, any value (including no value at all) is considered compliant.
- Enforcement: An enforced_for field indicates whether to prevent any non-compliant tagging operations on specified services and resources. If you do not specify any services or resource types in a tag policy, the tag policy will not apply to any resources.
- Wildcard: You can use the wildcard (*) in tag values and the enforced_for field provided that you adhere to the following rules:
- You can use only one wildcard for each tag value. For example, *@example.com is allowed, but *@*.com is not.
- For the enforced_for field, you can use <service>:* to enable enforcement for all resources for a service, but you cannot use a wildcard to specify all services or specify a resource of all services.
Inheritance Operators
In the preceding example tag policy, the operator @@assign used in the tag key, tag value, and enforcement is an inheritance operator.
Inheritance operators specify how directly attached tag policies and inherited tag policies are merged into the account's effective tag policy. Such operators include value-setting operators and child control operators.
- Value-setting operators
You can use the following value-setting operators to control how your policy interacts with its parent policies.
Table 1 Value-setting operators Operator
Description
@@assign
Overwrites any inherited policy settings with the specified setting. If the specified setting is not inherited, this operator adds it to the effective tag policy. This operator can apply to any policy setting of any type.
For single-valued settings, this operator replaces the inherited value with the specified value.
For multi-valued settings (JSON arrays), this operator removes all inherited values and replaces them with the values specified for this policy.
@@append
Adds the specified settings to the inherited settings, without deleting any settings. If the specified setting is not inherited, this operator adds it to the effective tag policy. You can only use this operator with multi-valued settings.
This operator adds the specified value to any values in the inherited array.
@@remove
Removes the specified inherited setting (if there is one) from the effective policy. You can only use this operator with multi-valued settings.
This operator removes only the specified values from the array of values inherited from the parent policies. Other values can be retained in the array and inherited by child policies.
- Child control operators
Child control operators specify which value-setting operators child OUs and accounts can use in child policies. By default, all operators (@@all) are allowed.
- "@@operators_allowed_for_child_policies":["@@all"] indicates that child OUs and accounts can use any operator in policies. By default, all operators are allowed in child policies.
- "@@operators_allowed_for_child_policies":["@@assign", "@@append", "@@remove"] indicates that child OUs and accounts can use only the specified operators in child policies. You can specify one or more value-setting operators in this child control operator.
- "@@operators_allowed_for_child_policies":["@@none"] indicates that child OUs and accounts cannot use operators in policies. You can use this operator to effectively lock the values defined in a parent policy so that the child policies cannot add, append, or delete those values.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot