Tags and labels

This page describes the tags and labels you can set on Filestore resources.

Overview

Google Cloud tags and labels are two ways to organize your Filestore resources.

Tags and labels work independently of each other, and you can use both on the same resource.

Tags

Tags are key-value pairs you can apply to your resources for fine-grained access control and granular cost data at the bucket level.

Tags are created at the organization or project level and managed through the Resource Manager, which is used across Google Cloud. Once you attach a tag to a Filestore resource, you can use the tag with IAM Conditions to grant access to resources or with organization policies to enforce constraints on resources. You can also use the tag to analyze detailed usage cost data exported to Cloud Billing.

You can apply tags to Filestore instances and backups.

When using tags, note the following restrictions:

  • Tags can only be attached to a resource after the resource has been created.

  • Tags cannot be applied directly to snapshots, but snapshots inherit any tags set on their associated instance.

  • You can have a maximum of 50 tag bindings per resource.

Notice: Tags are immutable and cannot be edited.

If you are managing your resources with Terraform, note that Terraform destroys a resource and recreates it when trying to update an immutable parameter—the re-creation consists of deleting the resource and then creating the resource with the immutable parameter—which can result in data loss.

You are advised to enable Deletion protection when managing Filestore through Terraform

Required permissions

Although tags are managed through the Resource Manager, you need the following IAM permissions to set and manage tags on Filestore resources:

  • file.RESOURCE_TYPE.listTagBindings
  • file.RESOURCE_TYPE.listEffectiveTags
  • file.RESOURCE_TYPE.createTagBinding
  • file.RESOURCE_TYPE.deleteTagBinding

RESOURCE_TYPE is instances for managing tags on instances and backups for managing tags on backups.

These permissions can be inherited through custom roles or predefined roles, such as the Tag User (roles/resourcemanager.tagUser) role or the Cloud Filestore Editor (roles/file.editor) role.

Examples for attaching tags to Filestore resources

Once you've created and defined a tag, you can attach the tag to your Filestore resources.

Consider the following scenario:

  • The tag value has a namespaced name of 815471563813/color/blue.
  • You have an instance named my-instance.
  • Your instance is located in us-central1, in a project named my-project.

The following gcloud command attaches the tag to my-instance:

gcloud resource-manager tags bindings create \
--tag-value=815471563813/color/blue \
--parent=//file.googleapis.com/projects/my-project/locations/us-central1/instances/my-instance \
--location=us-central1

The following gcloud command detaches the tag from my-instance:

gcloud resource-manager tags bindings delete \
--tag-value=815471563813/color/blue \
--parent=//file.googleapis.com/projects/my-project/locations/us-central1/instances/my-instance \
--location=us-central1

The following gcloud command lists all tags directly attached to my-instance, except tags that my-instance has inherited:

gcloud resource-manager tags bindings list \
--parent=//file.googleapis.com/projects/my-project/locations/us-central1/instances/my-instance \
    --location=us-central1

For more detailed instructions, see Attaching tags to resources

Labels

What are labels?

A label is a key-value pair that you can assign to Google Cloud Filestore instances. They help you organize these resources and manage your costs at scale, with the granularity you need. You can attach a label to each resource, then filter the resources based on their labels. Information about labels is forwarded to the billing system that lets you break down your billed charges by label. With built-in billing reports, you can filter and group costs by resource labels. You can also use labels to query billing data exports.

Requirements for labels

The labels applied to a resource must meet the following requirements:

  • Each resource can have up to 64 labels.
  • Each label must be a key-value pair.
  • Keys have a minimum length of 1 character and a maximum length of 63 characters, and cannot be empty. Values can be empty, and have a maximum length of 63 characters.
  • Keys and values can contain only lowercase letters, numeric characters, underscores, and dashes. All characters must use UTF-8 encoding, and international characters are allowed. Keys must start with a lowercase letter or international character.
  • The key portion of a label must be unique within a single resource. However, you can use the same key with multiple resources.

These limits apply to the key and value for each label, and to the individual Google Cloud resources that have labels. There is no limit on how many labels you can apply across all resources within a project.

Common uses of labels

Here are some common use cases for labels:

  • Team or cost center labels: Add labels based on team or cost center to distinguish Filestore instances owned by different teams (for example, team:research and team:analytics). You can use this type of label for cost accounting or budgeting.

  • Component labels: For example, component:redis, component:frontend, component:ingest, and component:dashboard.

  • Environment or stage labels: For example, environment:production and environment:test.

  • State labels: For example, state:active, state:readytodelete, and state:archive.

  • Ownership labels: Used to identify the teams that are responsible for operations, for example: team:shopping-cart.

We don't recommend creating large numbers of unique labels, such as for timestamps or individual values for every API call. The problem with this approach is that when the values change frequently or with keys that clutter the catalog, this makes it difficult to effectively filter and report on resources.

Labels and tags

Labels can be used as queryable annotations for resources, but can't be used to set conditions on policies. Tags provide a way to conditionally allow or deny policies based on whether a resource has a specific tag, by providing fine-grained control over policies. For more information, see the Tags overview.

What's next