Tags and Tag Namespace Concepts

If you're in the Administrators group, then you have the required access for managing tag namespaces and tags.

For more policy samples specific to working with tags and tag namespaces, see Required Permissions for Working with Defined Tags.

If you're new to policies, see Getting Started with Policies and Common Policies. If you want to dig deeper into writing policies for groups or other IAM components, see Details for IAM without Identity Domains.

Defined tags provide more features and control than free-form tags. Before you create a defined tag key, you first set up a tag namespace for it. You can think of the tag namespace as a container for a set of tag keys.

When you create the tag key definition, you must choose the type of value (which also determines how the user applying the tag adds the value): 

• You can leave it empty so that a user can fill in the value.
• You can create a list of values so that the user must choose from those values.

To apply a defined tag to a resource, a user first selects the tag namespace, then the tag key within the namespace, and then they can assign the value. If the tag key contains a blank value, the user can type in a value or leave it blank. If the tag key contains a list, the user must select a value from the list.

Defined tags support policy to allow you to control who can apply your defined tags. The tag namespace is the entity to which you can apply policy. Administrators can control which groups of users are allowed to use each namespace.

The following diagrams illustrate defined tags. Two tag namespaces are set up: Operations and HumanResources. The tag keys are defined in the namespaces. Within each namespace, the tag keys must be unique, but a tag key name can be repeated across namespaces. In the example, both namespaces include a key named "Environment."

The first instance is tagged with two tags from the Operations tag namespace, indicating that it belongs to the Operations production environment and the Operations project "Alpha". The second instance is tagged with tags from both the HumanResources tag namespace and the Operations tag namespace, indicating that it belongs to the HumanResources "Production" environment, the HumanResources cost center "42", and also the Operations project "Beta".

To reduce the complexities of creating and managing tags, Oracle Cloud Infrastructure Tagging provides you with templates of standard tag namespaces and tag definitions.

You can use this template to create a tag namespace and bring consistency across your tenancy.

For more information, see Understanding Standard Tags. To know how to import standard tags using the console, see Import Standard Tags .

You must set up the tag namespace and tag keys in your tenancy before users can apply a defined tag to a resource. As part of the set up process, you must also grant permissions to the user groups that needs to use the namespace.

Features of defined tags include:

• Consist of a tag namespace, a key, and a value.
• The tag namespace and tag key definition must be set up in your tenancy before users can apply a defined tag to a resource.
• You can create the tag key with either a tag value type of string (for the user to add a value or leave blank) or a list of values (from which the user must choose).
• When applying a defined tag, users select from the list of tag keys.
• Users can apply a defined tag during resource creation or to an existing resource.
• Defined tag keys are case insensitive.
• Defined tag values are case sensitive. For example, "alpha" and "Alpha" are distinct values.
• You can use tag variables.
• You can create a list of predefined variables to associate with a tag key. Users that apply the tag to a resource must select a value from the list you create.

Tag administrators create and manage defined tags, and users apply these tags to resources. Use IAM policy to select tag administrators who can create tags. Grant all other users in the tenancy only the ability to apply tags.

The child compartments and their resources in metering services such as Cost Analysis, Usage Reports, and Budget, inherit the defined tags applied to a compartment. However, if there is a conflict between the inherited tags and the tags applied directly to the resources or the child compartments, the tags applied to the resources take precedence over the inherited tags. You can dynamically apply defined tags to resources in a compartment.

For example, consider a tenancy called TenancyA with TagKey1=TagValueP and a compartment called Compartment P with TagKey3=TagValueQ and TagKey4=TagValueS. You have a compute instance in Compartment P with TagKey2=TagValueR, TagKey3=TagValueT. When the tag inheritance logic is applied, the following tags are applied to the compute instance: TagKey2=TagValueR, TagKey3=TagValueT, TagKey4=TagValueS. The resource has inherited TagKey4=TagValueS from the parent compartment. However, the TagKey3 applied to the compute instance overrides the TagKey3 value applied to the parent compartment.

You can filter using inherited tags in Cost Analysis, create budgets with inherited tags, and view these tags in the Usage Reports.

You can retire a tag key definition or a tag namespace definition.

When you retire a tag key definition, you can no longer apply it to resources. However, the tag is not removed from the resources that it was applied to. The tag still exists as metadata on those resources and you can still call the retired tag in operations (such as listing, sorting, or reporting).

You can reactivate retired tag key definitions and tag namespace definitions.

• When you reactivate a tag key, it is again available for you to apply to resources.
• When you reactivate a tag namespace, you can create new tag key definitions in that namespace. However, if you want to use any of the tag key definitions that were retired with the namespace, you must explicitly reactivate each tag key definition.

You can move a tag namespace to a different compartment. The tag namespace can be active or retired when you move it. When you move the tag namespace, all its tag key definitions are moved along with it.

This functionality is useful if you need to reorganize your compartment hierarchy, or if you need to delete a compartment that contains a retired tag namespace. Remember that you can't delete a compartment that contains resources. A retired tag namespace, even though it is retired, is still an existing resource. Moving the retired tag namespace to a different compartment can enable you to delete its original containing compartment.

To move a tag namespace, you must be allowed to manage tag-namespaces in both compartments.

See the procedure Moving a Tag Namespace to a Different Compartment.

You can delete tag key definitions and tag namespaces.

When you delete a tag key definition, you begin a process that removes the tag from all resources in your tenancy. These things happen immediately: 

• If the tag was a cost-tracking tag, it no longer counts against your 10 cost-tracking tags limit, whether you first disabled it or not.
• If the tag was used with dynamic groups, none of the rules that contain the tag will be evaluated against the tag.

The delete action is asynchronous and initiates a work request. Once you start the delete operation, the state of the tag changes to deleting, and tag removal from resources begins. This process can take up to 48 hours depending on the number of resources that were tagged as well as the regions in which those resources reside. When all tags are removed, the state changes to deleted. You cannot restore a deleted tag. After the tag state changes to Deleted, you can use the same tag name again.

To delete a tag key definition, you must first retire it. To delete a tag namespace, you must first retire the tag namespace. When you retire a tag namespace that contains tag key definitions, all the tag keys in the namespace are retired, allowing you to delete the tag namespace.