Write-only access to resource metadata. This provides exactly the permissions needed by the Ops Config Monitoring metadata agent and other systems that send metadata.
opsconfigmonitoring.resourceMetadata.write
Stackdriver Accounts Editor
(roles/stackdriver.accounts.editor)
Read/write access to manage Stackdriver account structure.
resourcemanager.projects.get
resourcemanager.projects.list
serviceusage.services.enable
serviceusage.services.get
stackdriver.projects.*
stackdriver.projects.edit
stackdriver.projects.get
Stackdriver Accounts Viewer
(roles/stackdriver.accounts.viewer)
Read-only access to get and list information about Stackdriver account structure.
resourcemanager.projects.get
resourcemanager.projects.list
stackdriver.projects.get
Stackdriver Resource Metadata Writer
Beta
(roles/stackdriver.resourceMetadata.writer)
Write-only access to resource metadata. This provides exactly the permissions needed by the Stackdriver metadata agent and other systems that send metadata.
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-28。"],[],[],null,["# Control access with IAM\n\nTo use Monitoring, you must have the appropriate\n[Identity and Access Management](/iam/docs/overview) (IAM) permissions.\nIn general, each REST method in an API has an associated permission.\nTo use the method, or use a console feature that relies on the method, you must\nhave the permission to use the corresponding method.\nPermissions aren't granted directly to users; permissions are instead granted\nindirectly through roles, which group multiple permissions to make managing them\neasier:\n\n- For information about access control, see [Concepts related to access management](/iam/docs/overview#concepts_related_to_access_management).\n\n\u003c!-- --\u003e\n\n- For information about how to grant roles to principals, see [Grant access to Cloud Monitoring](#grant-monitoring-access).\n\nRoles for common combinations of permissions are predefined for you. However,\nyou can also create your own combinations of permissions by\ncreating [IAM custom roles](/iam/docs/understanding-custom-roles).\n\nBest practice\n-------------\n\nWe recommend that you create Google groups to manage access to\nGoogle Cloud projects:\n\n- For more information, see [Managing groups in the Google Cloud console](/iam/docs/groups-in-cloud-console).\n- For information about setting limits on roles, see [Set limits on granting roles](/iam/docs/setting-limits-on-granting-roles).\n- For a complete list of IAM roles and permissions, see [IAM basic and predefined roles reference](/iam/docs/understanding-roles).\n\nVPC Service Controls\n--------------------\n\nFor further control access to monitoring data, use\n[VPC Service Controls](/vpc-service-controls) in addition to IAM.\n\nVPC Service Controls provides additional security for Cloud Monitoring to help\nmitigate the risk of data exfiltration. Using VPC Service Controls, you can add\na [metrics scope](/monitoring/settings) to a Service Perimeter that protects\nCloud Monitoring resources and services from requests originating outside\nthe perimeter.\n\nTo learn more about Service Perimeters, see the\n[VPC Service Controls Service Perimeter configuration documentation](/vpc-service-controls/docs/service-perimeters).\n\nFor information about Monitoring's support for\nVPC Service Controls, including known limitations, see the\n[Monitoring VPC Service Controls documentation](/vpc-service-controls/docs/supported-products#table_monitoring).\n\nGrant access to Cloud Monitoring\n--------------------------------\n\nTo manage IAM roles for principals you can use the\nIdentity and Access Management page in the Google Cloud console or the Google Cloud CLI.\nHowever, Cloud Monitoring provides a simplified interface that lets you\nmanage your Monitoring-specific roles, project-level roles,\nand the common roles for Cloud Logging and Cloud Trace.\n| **Note:** To grant a principal an IAM role, you must have the [IAM](/iam/docs/overview) role of Owner.\n\nTo grant principals access to Monitoring, Cloud Logging,\nor Cloud Trace, or to grant a project-level role, do the following: \n\n### Console\n\n1. In the Google Cloud console, go to the person **Permissions** page:\n\n [Go to **Permissions**](https://console.cloud.google.com/monitoring/permissions)\n\n \u003cbr /\u003e\n\n If you use the search bar to find this page, then select the result whose subheading is\n **Monitoring**.\n\n The **Permissions** page doesn't display all principals. It only lists\n those principals that have a project-level role, or a role that is\n specific to Monitoring, Logging, or\n Trace.\n\n The options on this page let you view all principals whose roles include\n any Monitoring permission.\n2. Click person_add **Grant access**.\n\n3. Click **New principals** and enter the username for the principal. You can\n add several principals.\n\n4. Expand *arrow_drop_down* **Select a role** , select a value from the\n **By product or service** menu, and then select a role from the **Roles**\n menu:\n\n5. Optional: To grant the same principals another role, click\n **Add another role** and repeat the previous step.\n\n6. Click **Save**.\n\nThe previous steps describe how to grant a principal certain roles by using\nMonitoring pages in the Google Cloud console. For these\nroles, this page also supports edit and delete options:\n\n- To remove roles for a principal,\n select the box next to the principal and then click\n person_remove **Remove access**.\n\n- To edit the roles for a principal,\n click *edit* **Edit** . After you update the settings,\n click **Save**.\n\n### gcloud\n\nUse the\n[`gcloud projects add-iam-policy-binding`](/sdk/gcloud/reference/projects/add-iam-policy-binding)\ncommand to grant the `monitoring.viewer` or\n`monitoring.editor` role.\n\nFor example: \n\n export PROJECT_ID=\"my-test-project\"\n export EMAIL_ADDRESS=\"myuser@gmail.com\"\n gcloud projects add-iam-policy-binding \\\n $PROJECT_ID \\\n --member=\"user:$EMAIL_ADDRESS\" \\\n --role=\"roles/monitoring.editor\"\n\nYou can confirm the granted roles using the\n[`gcloud projects get-iam-policy`](/sdk/gcloud/reference/projects/get-iam-policy)\ncommand: \n\n export PROJECT_ID=\"my-test-project\"\n gcloud projects get-iam-policy $PROJECT_ID\n\n\u003cbr /\u003e\n\nPredefined roles\n----------------\n\nThis section lists a subset of IAM roles that are predefined by\nCloud Monitoring.\n\n#### Monitoring roles\n\nThe following roles grant general permissions for Monitoring:\n\nThe following role is used by service accounts for write-only access:\n\n#### Alerting policy roles\n\nThe following roles grant permissions for alert policies:\n\n#### Dashboard roles\n\nThe following roles grant permissions only for dashboards:\n\n#### Incident roles\n\nThe following roles grant permissions only for incidents:\n\n| **Note:** You can't grant the individual permissions associated with these roles.\n\nFor information about how to resolve IAM permission errors when\nviewing incidents, see\n[Unable to view incident details due to a permission error](/monitoring/alerts/troubleshooting-alerts#no-permission).\n\n#### Notification channel roles\n\nThe following roles grant permissions only for notification channels:\n\n#### Snooze notification roles\n\nThe following roles grant permissions to snooze notifications:\n\n#### Service monitoring roles\n\nThe following roles grant permissions for managing services:\n\nFor more information on service monitoring, see [SLO monitoring](/stackdriver/docs/solutions/slo-monitoring).\n\n#### Uptime-check configuration roles\n\nThe following roles grant permissions only for uptime-check configurations:\n\n#### Metrics scope configuration roles\n\nThe following roles grant general permissions for\n[metrics scopes](/monitoring/settings):\n\nPermissions for predefined roles\n--------------------------------\n\nThis section lists the permissions assigned to predefined roles associated\nwith Monitoring.\n| **Note:** If no permissions are listed for a role, then there aren't public permissions for that role.\n\nFor more information about predefined roles, see\n[IAM: Roles and permissions](/iam/docs/roles-overview).\nFor help choosing the most appropriate predefined roles,\nsee [Choose predefined roles](/iam/docs/choose-predefined-roles).\n\n\n### Permissions for Monitoring roles\n\n### Monitoring permissions included in Google Cloud basic roles\n\nThe [Google Cloud basic roles](#gcp_roles_desc) include the following\npermissions:\n\nCustom roles\n------------\n\nYou might want to create a custom role when you want to grant a principal a\nmore limited set of permissions than those granted with predefined roles.\nFor example, if you set up [Assured Workloads](/assured-workloads)\nbecause you have data-residency or\n[Impact Level 4 (IL4)](/security/compliance/disa) requirements,\nthen you shouldn't use\n[uptime checks](/monitoring/uptime-checks/introduction) because there is\nno guarantee that uptime-check data is kept in a specific geographic location.\nTo prevent usage of uptime checks, create a role that doesn't include any\npermissions with the prefix `monitoring.uptimeCheckConfigs`.\n\nTo create a custom role with Monitoring permissions, do the\nfollowing:\n\n- For a role granting permissions only for the Monitoring API,\n choose from the permissions in the\n [Permissions and predefined roles](#permissions_and_roles) section.\n\n- For a role granting permissions for Monitoring in the\n Google Cloud console, choose from permission groups in the\n [Monitoring roles](#mon_roles_desc) section.\n\n- To grant the ability to write monitoring data,\n include the permissions from the\n role `roles/monitoring.metricWriter` in the\n [Permission and predefined roles](#permissions_and_roles) section.\n\n| **Note:** Some permissions, including the permissions required to view and manage incidents, aren't supported in custom roles. Without these permissions, Monitoring in the Google Cloud console might not function properly.\n|\n| If a Monitoring role is copied to create a\n| custom role, then these permissions are omitted:\n|\n| - `stackdriver.projects.get`\n| - `stackdriver.projects.edit`\n|\n| The role Stackdriver Accounts Viewer (`roles/stackdriver.accounts.viewer`) includes the permission `stackdriver.projects.get`. The role Stackdriver Accounts Editor (`roles/stackdriver.accounts.editor`) includes the permission `stackdriver.projects.edit`.\n\nFor more information on custom roles, go to\n[Understanding IAM custom roles](/iam/docs/understanding-custom-roles).\n\nCompute Engine access scopes\n----------------------------\n\n**Access scopes** are the legacy method of specifying permissions for your\nCompute Engine VM instances. The following access scopes apply to\nMonitoring:\n\nFor more details, go to [Access scopes](/compute/docs/access/service-accounts#accesscopesiam).\n\n**Best practice.** It is a good practice is to give your VM instances the\nmost powerful access scope (`cloud-platform`) and then use IAM\nroles to restrict access to specific APIs and operations. For details, go to\n[Service account permissions](/compute/docs/access/service-accounts#service_account_permissions)."]]
