Labeling in GCP – Marks, Tags and Labels

Labels — for automation (e.g. shutting down compute instances at scheduled times) as well as for billing

Marks — Show up in security center and are used more to identify and ‘block’ ‘non compliant’ resources. For E.g. All Public IPs on compute instances show up in security center. If you wanted to tell security center to NOT alert on certain public IPs, you would add a mark to those instances. And then filter Security Center based on that mark.

Tags — are for network firewall rules

Labels are a way to group together resources that are related or associated with each other. For example, a common practice is to label resources that are intended for production, staging, or development separately, so you can easily search for resources that belong to each development stage when necessary. Labels are created as key/value pairs:

{
 "labels": {
    "vmrole": "webserver",
    "environment": "production",
    "location": "west",...
    }
 }

Label Format, Casing and Restrictions

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

• Each resource can have multiple labels, up to a maximum of 64.
• 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.
• The key portion of a label must be unique. However, you can use the same key with multiple resources.
• Keys must start with a lowercase letter or international character.

Which labels qualify as Required Labels on GCP Resources?

Project Level Labels — Ideally, either for each project, or for each resource in a project, include the following labels:

• app_id — “01234”
• environment — “production”
• cost_center — “012345”
• visibility  — “private”

Labeling Other Resources — TBD

What are some additional recommended labels?

• line_of_business (banking, insurance..)
• date_time — Used to identify the date or time a resource should be started, stopped, deleted, or rotated. E.g Values: mon;0700;fri;1800;
• optin — should this resource be included in an automated activity such as startup shutdown?
• risk_level — (1 small — through 5 highest risk)risk_owner ( csi, cse…teamID)
• project_name (hadoop, elasticsearch…)

What are tags? How do they differ from labels?

These are used to make your VPC perform “rewiring” of GCP’s Software-Defined Network. Network Tags can be set on on instances and network rules– making certain ‘custom’ communication possible, and making some other communication impossible.

For e.g. — Tags enable you to make firewall rules and routes applicable to specific VM instances.

Network tags can be assigned to new VMs either at creation time or any time later. Network tags can be edited without stopping a VM.

$ gcloud compute instances add-tags test-instance --tags=tag-1,tag-2

What about labels on sensitive data (sensitive data classification)?

This falls under Data Loss Protection. The classification labels that are added to sensitive data are stored in DLP’s data sink — for e.g. BigQuery. These classification labels can only be applied by streaming data through DLP.

What about Labels on KMS Keys?

Two important attributes of KMS keys are already captured during key creation. These are keyring name and key purpose. The key purpose should capture the primary purpose of the key. Additional labels can be added to provide cost center or team info (see example below).

gcloud kms keys create key-name \
    --location location \
    --keyring keyring-name \
    --purpose purpose \
    --labels 'team=alpha,cost_center=cc1234'

Automating Labeling of Resources

A custom python script would be needed to automate the labeling of GCP resources. A sample of what this looks like is available on github.

Sample Script for Labeling Compute Engine Resources

A sample bash script for labeling gcp compute engine resources can be found on github here

Security Marks and Command Center

Security Marks are a new way to manually label GCP assets and security findings. A mark can be either a LABEL, a TAG or a MARK. Security marks enable you to add your business context for assets and findings. Labels and tags are similar kinds of metadata that are available through Security Command Center, but they have a slightly different use and permissions model. Because Cloud IAM roles apply to security marks, they can be used to group and enforce policies on both assets and findings.

MARK: Security marks are unique to Security Command Center and only exist in the Security Command Center database. Cloud IAM permissions apply to security marks, and they are restricted to only users who have the appropriate Security Command Center roles. Reading and editing marks require the Security Center Asset Security Marks Writer and Security Center Finding Security Marks Writer roles. These roles don’t include permissions to access the underlying resource.

LABELS are user-level annotations that are applied to specific resources and are supported across multiple Google Cloud products. Labels are primarily used for billing accounting and attribution.

TAGS are also a user-level annotation, specific to Compute Engine resources. Tags are primarily used to define security groups, network segmentation, and firewall rules.

The projects you selected are now associated with a mark. By default, marks display as a column in the assets display. To include or exclude specific marks in the assets display, select the mark name in the Columns drop-down list at the top of the displayed assets.