This document describes the encryption policies for data at rest in Cloud Monitoring and steps you can take to ensure that your sensitive customer data is protected.
This document is intended for customers who must comply with data-security requirements.
Encryption of data at rest
All data at rest within Cloud Monitoring is encrypted using Google-managed encryption keys. For more information, see Default encryption at rest .
Cloud Monitoring doesn't support the use of customer-managed encryption keys (CMEK) for protecting your data at rest. By default, Monitoring doesn't store sensitive data and isn't intended to be used for Personally Identifiable Information (PII) or other private customer content. You can use Monitoring to store aggregated, unidentifiable user-activity data or second-order event-based aggregated information like request counts and other similar metrics.
However, there are places in Monitoring at which you can inadvertently insert sensitive customer data. Because Cloud Monitoring stores metadata and resource labels, customer data can make its way into Monitoring when you name configurations or perform metadata actions like labeling a resource, annotating an instance, or storing custom resources by using custom resource definitions (CRDs) in Google Kubernetes Engine.
The rest of this document describes the points at which such data might be inserted and how to look for the capture of such data.
Possible insertion points
The following table describes the points at which sensitive data might be sent to Cloud Monitoring.
like system-defined metrics
and built-in dashboards
like custom or log-based metrics
and custom dashboards
- Keys, for example, showing that a certain dimension of a piece of software exists
- Values containing sensitive data, for example, names of not-yet-released hardware
- Display names
- Descriptions
- Label keys, for example, showing that a certain dimension of a piece of software exists
- Display names of policies and embedded conditions
- Label keys and values used to filter alert to certain time series
- Information provided as documentation
- If you have policies based on service-level objectives, their
configuration might include:
- Display name
- User-specified label keys and values
- Display names
- Text in items on the dashboard
- Filters and other query dimensions used to select time-series data for charts and other items on the dashboard
- Display names
- Descriptions
- Labels and values used to define channels
- Display names
- Filters used to designate group membership
- Display names
- IP addresses, paths
- Any optional content-matcher strings
Protecting sensitive metadata
If you want all data protected by CMEK, then you shouldn't put sensitive information in resource configurations or metadata in Google Cloud. If sensitive data must be used in resource configurations, resource metadata, or label values, we recommend that you protect it by using obscured identifiers in Google Cloud and a mapping table external to Google Cloud.
If you send sensitive time-series data to Monitoring, the only way to ensure the data is deleted is to delete your Google Cloud project . Otherwise, time-series data is deleted only after it reaches the data-retention limit, which is 24 months for user-defined metrics.
Inspecting data to ensure compliance
You can manually inspect your data in Cloud Monitoring to ensure that it complies with your security standards.
Configuration data
To ensure that labels and filters used in configuration artifacts like alerting policies are properly obscured, you can retrieve and inspect the configuration data. Inspect the following:
-
Alerting policies, as described in List and get alerting policies . Alerting policies based on service-level objectives have filters that refer to the SLO, for example:
filter: select_slo_burn_rate("projects/ PROJECT_NUMBER /services/ SERVICE_ID /serviceLevelObjectives/ SLO_ID ")
You can retrieve the configuration of the SLO by providing fully qualified name of the SLO from the filter to the
serviceLevelObjects/get
method. -
Notification channels, as described in List notification channels in a project .
-
Uptime-check configurations, as described in Manage uptime checks .
-
Custom dashboards, as described in List dashboards .
-
Resource groups, by using the
groups.list
method.
Metric data
To inspect metric data, you must consider both the metric descriptors for user-defined metrics and the time-series data written against those descriptors.
Metric descriptors
To ensure that the display names, descriptions, and label keys in any metric descriptors are properly obscured, inspect the descriptors, as described in List metric descriptors .
-
To search for custom metrics, use the filter:
metric.type = starts_with("custom.googleapis.com")
-
To search for log-based metrics, use the filter:
metric.type = starts_with("logging.googleapis.com/user")
Time-series data
To ensure that the time-series data itself is properly obscured, retrieve the time-series data, and inspect the values of metric and resource labels and other stored data. Pay particular attention to time-series data collected by custom metrics or log-based metrics. For information on retrieving time-series data, see Retrieve time-series data .