Object Storage Service (OSS) allows you to configure object tags to classify objects. You can configure lifecycle rules and control access to objects based on tags.

Note You are charged when you use object tagging. For more information, see Object Storage Service Pricing.
Object tagging uses a key-value pair to identify objects. You can add tags to objects when and after you upload the objects.
  • A maximum of 10 tags can be configured for each object. Tags associated with an object must have unique tag keys.
  • A tag key can be up to 128 characters in length. A tag value can be up to 256 characters in length.
  • Tag keys and tag values are case-sensitive.
  • The key and value of a tag can contain letters, digits, spaces, and the following special characters:

    + - = ._:/

  • Only the bucket owner and authorized users have read and write permissions on object tags. These permissions are independent of object access control lists (ACLs).
  • During cross-region replication (CRR), object tags are also replicated to the destination bucket.

Scenarios

Object tags are not limited to directories. You can perform the following operations on multiple objects that have a specific tag:
  • Configure lifecycle rules based on specific tags. For example, when you upload objects, you can configure tagging for temporary objects that are periodically generated. After you configure lifecycle rules for these temporary objects, you can delete these objects based on specific tags.
  • Use Resource Access Management (RAM) to grant permissions to access objects that have specific tags.

Implementation methods

Implementation method Description
Console A user-friendly and intuitive web application
ossutil A high-performance command-line tool
Java SDK SDK demos for various programming languages
Python SDK
Go SDK
C++ SDK

Instructions

  • API operations related to object tagging
    • PutObjectTagging: configures tagging for an object. If the object already has tags, the existing tags are overwritten.
    • GetObjectTagging: reads tags of an object.
    • DeleteObjectTagging: deletes tags of an object.
    • PutObject: You can use the x-oss-tagging request header to specify tags when you upload an object.
    • InitiateMultipartUpload: You can use the x-oss-tagging request header to specify tags when you initiate a multipart upload task.
    • CopyObject: You can use the x-oss-tagging-directive request header to specify whether to replicate tags of source objects. You can use the x-oss-tagging request header to specify tags of destination objects.
    • GetObject: If you have permissions to read the object tags, the tag count is included in the x-oss-tagging-count response header.
    • HeadObject: If you have permissions to read the object tags, the tag count is included in the x-oss-tagging-count response header.
  • Required permissions
    Users, roles, or services that perform operations on tags must have the following permissions:
    • GetObjectTagging: the permission to query object tags. If you have this permission, you can view existing tags of an object.
    • PutObjectTagging: the permission to configure tagging for objects. If you have this permission, you can configure tagging for objects.
    • DeleteObjectTagging: the permission to delete object tags. If you have this permission, you can delete object tags.

Object tagging and lifecycle management

When you configure lifecycle rules, you can configure conditions for lifecycle rules to select subsets of objects to which to apply rules. You can specify a filter based on the object name prefixes, object tags, or both.
  • If you configure tag conditions in one lifecycle rule, the rule applies only to objects that meet both the tag key and value conditions.
  • If you configure object name prefixes and multiple object tags in one lifecycle rule, the rule applies only to objects that match the object name prefixes and object tags.
Example:
<LifecycleConfiguration>
<Rule>
<ID>r1</ID>
<Prefix>rule1</Prefix>
<Tag><Key>xx</Key><Value>1</Value></Tag>
<Tag><Key>yy</Key><Value>2</Value></Tag>
<Status>Enabled</Status>
<Expiration>
<Days>30</Days>
</Expiration>
</Rule>
<Rule>
<ID>r2</ID>
<Prefix>rule2</Prefix>
<Tag><Key>xx</Key><Value>1</Value></Tag>
<Status>Enabled</Status>
<Transition>
<Days>60</Days>
<StorageClass>Archive</StorageClass>
</Transition>
</Rule>
</LifecycleConfiguration>
In the preceding rules,
  • Objects whose names are prefixed with rule1 and whose tagging configurations are xx=1 and yy=2 are deleted after the objects are stored for 30 days.
  • The storage class of objects whose names are prefixed with rule2 and whose tagging configurations are xx=1 is converted to Archive after the objects are stored for 60 days.
Note For more information, see Lifecycle rules based on the last modified time.

Object tagging and RAM policy

You can authorize RAM users to manage object tags. You can also authorize RAM users to manage objects that have specific tags.

  • Authorize RAM users to manage object tags
    You can authorize RAM users to manage tags of all or specific objects. If User A is authorized to set object tagging to allow=yes, this user can add the tagging configuration of allow=yes to objects. The following code provides an example on how to configure the corresponding RAM policy:
    {
      "Version": "1",
      "Statement": [
        {
          "Action": "oss:PutObjectTagging",
          "Effect": "Allow",
          "Resource": "*",
          "Condition": {
            "StringEquals": {
              "oss:RequestObjectTag/allow": [
                "yes"
              ]
            }
          }
        }
      ]
    }
    Notice After the RAM user is authorized to configure tagging for specified objects, this user can configure tagging only for existing objects.
  • Authorize RAM users to manage objects that have specific tags
    You can authorize RAM users to manage all objects that have specific tags. For example, you can authorize User A to access all objects that have the tagging configuration of allow=yes. The following code provides an example on how to configure the corresponding RAM policy:
    {
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "oss:GetObject",
          "Resource": "*",
          "Condition": {
            "StringEquals": {
              "oss:ExistingObjectTag/allow": [
                "yes"
              ]
            }
          }
        }
      ]
    }