Control access with IAM

To use Monitoring, you must have the appropriate Identity and Access Management (IAM) permissions. In general, each REST method in an API has an associated permission. To use the method, or use a console feature that relies on the method, you must have the permission to use the corresponding method. Permissions aren't granted directly to users; permissions are instead granted indirectly through roles, which group multiple permissions to make managing them easier:

• For information about access control, see Concepts related to access management .

• For information about how to grant roles to principals, see Grant access to Cloud Monitoring .

Roles for common combinations of permissions are predefined for you. However, you can also create your own combinations of permissions by creating IAM custom roles .

Best practice

We recommend that you create Google groups to manage access to Google Cloud projects:

• For more information, see Managing groups in the Google Cloud console .
• For information about setting limits on roles, see Set limits on granting roles .
• For a complete list of IAM roles and permissions, see IAM basic and predefined roles reference .

VPC Service Controls

For further control access to monitoring data, use VPC Service Controls in addition to IAM.

VPC Service Controls provides additional security for Cloud Monitoring to help mitigate the risk of data exfiltration. Using VPC Service Controls, you can add a metrics scope to a Service Perimeter that protects Cloud Monitoring resources and services from requests originating outside the perimeter.

To learn more about Service Perimeters, see the VPC Service Controls Service Perimeter configuration documentation .

For information about Monitoring's support for VPC Service Controls, including known limitations, see the Monitoring VPC Service Controls documentation .

Grant access to Cloud Monitoring

To manage IAM roles for principals you can use the Identity and Access Management page in the Google Cloud console or the Google Cloud CLI. However, Cloud Monitoring provides a simplified interface that lets you manage your Monitoring-specific roles, project-level roles, and the common roles for Cloud Logging and Cloud Trace.

To grant principals access to Monitoring, Cloud Logging, or Cloud Trace, or to grant a project-level role, do the following:

  export 
  
 PROJECT_ID 
 = 
 "my-test-project" 
 export 
  
 EMAIL_ADDRESS 
 = 
 "myuser@gmail.com" 
 gcloud 
  
 projects 
  
 add 
 - 
 iam 
 - 
 policy 
 - 
 binding 
  
\  
 $ 
 PROJECT_ID 
  
\  
 -- 
 member 
 = 
 "user:$EMAIL_ADDRESS" 
  
\  
 -- 
 role 
 = 
 "roles/monitoring.editor" 
 

  export 
  
 PROJECT_ID 
 = 
 "my-test-project" 
 gcloud 
  
 projects 
  
 get 
 - 
 iam 
 - 
 policy 
  
 $ 
 PROJECT_ID 
 

Predefined roles

This section lists a subset of IAM roles that are predefined by Cloud Monitoring.

Monitoring roles

The following roles grant general permissions for Monitoring:

The following role is used by service accounts for write-only access:

Alerting policy roles

The following roles grant permissions for alert policies:

Dashboard roles

The following roles grant permissions only for dashboards:

Incident roles

The following roles grant permissions only for incidents:

For information about how to resolve IAM permission errors when viewing incidents, see Unable to view incident details due to a permission error .

Notification channel roles

The following roles grant permissions only for notification channels:

Snooze notification roles

The following roles grant permissions to snooze notifications:

Service monitoring roles

The following roles grant permissions for managing services:

For more information on service monitoring, see SLO monitoring .

Uptime-check configuration roles

The following roles grant permissions only for uptime-check configurations:

Metrics scope configuration roles

The following roles grant general permissions for metrics scopes :

Permissions for predefined roles

This section lists the permissions assigned to predefined roles associated with Monitoring.

For more information about predefined roles, see IAM: Roles and permissions . For help choosing the most appropriate predefined roles, see Choose predefined roles .

Permissions for Monitoring roles

Monitoring permissions included in Google Cloud basic roles

The Google Cloud basic roles include the following permissions:

Custom roles

You might want to create a custom role when you want to grant a principal a more limited set of permissions than those granted with predefined roles. For example, if you set up Assured Workloads because you have data-residency or Impact Level 4 (IL4) requirements, then you shouldn't use uptime checks because there is no guarantee that uptime-check data is kept in a specific geographic location. To prevent usage of uptime checks, create a role that doesn't include any permissions with the prefix monitoring.uptimeCheckConfigs .

To create a custom role with Monitoring permissions, do the following:

• For a role granting permissions only for the Monitoring API, choose from the permissions in the Permissions and predefined roles section.

• For a role granting permissions for Monitoring in the Google Cloud console, choose from permission groups in the Monitoring roles section.

• To grant the ability to write monitoring data, include the permissions from the role roles/monitoring.metricWriter in the Permission and predefined roles section.

For more information on custom roles, go to Understanding IAM custom roles .

Compute Engine access scopes

Access scopesare the legacy method of specifying permissions for your Compute Engine VM instances. The following access scopes apply to Monitoring:

For more details, go to Access scopes .

Best practice.It is a good practice is to give your VM instances the most powerful access scope ( cloud-platform ) and then use IAM roles to restrict access to specific APIs and operations. For details, go to Service account permissions .