This page describes the Identity and Access Management (IAM) roles and permissions needed for running Connectivity Tests.
You can grant users or service accounts permissions or predefined roles, or you can create a custom role that uses permissions that you specify.
The IAM permissions use a prefix of
To get or set IAM policies, or to test IAM permissions with the Network Management API, see Manage access policies.
This section describes how to use predefined and custom roles when granting permissions for Connectivity Tests.
For an explanation of each permission, see the permissions table.
For more information about project roles and Google Cloud resources, see the following documentation:
- Resource Manager documentation
- Identity and Access Management documentation
- Compute Engine documentation describing access control
Connectivity Tests has the following predefined roles:
networkmanagement.adminhas permission to perform all operations on a test resource.
networkmanagement.viewerhas permission to list or get a specific test resource.
The following table lists the predefined roles and the permissions that apply to each role.
Network Management Admin
Full access to Network Management resources.
Lowest-level resources where you can grant this role:
Network Management Viewer
Read-only access to Network Management resources.
Lowest-level resources where you can grant this role:
You can create custom roles by selecting a list of permissions from the permissions table for Connectivity Tests.
For example, you can create a role called
to this role. A user with this role can rerun existing
and view updated test results based on the latest network configuration.
You can use project roles to set permissions to Google Cloud resources.
Because Connectivity Tests must have read access to the
Google Cloud resource configurations in your Virtual Private Cloud (VPC)
network to run a test, you must grant at least the
Compute Network Viewer role
roles/compute.networkViewer) to users or service accounts running a test against
those resources. You can also create a custom role or temporarily authorize
permissions associated with the preceding role for a specific user.
Alternatively, you can grant a user or service account one of the following predefined roles for Google Cloud projects:
project.viewerhas all the permissions of a
project.ownerhas all the permissions of the
This section describes permissions for Connectivity Tests and how to use them when testing different types of network configurations.
Connectivity Tests permissions
Connectivity Tests has the following IAM permissions.
||Lists all tests configured in the specified project.|
||Gets the details of a specific test.|
||Creates a new test object in the specified project with the data that you specify for the test. This permission includes permission to update, rerun, or delete tests.|
||Updates one or more fields in an existing test.|
||Deletes the specified test.|
||Reruns a one-time reachability verification for a specified test.|
If you don't have permission to create or update a test, the corresponding buttons are inactive. These include the Create connectivity test button and, on the Connectivity test details page, the Edit button. In each case, when you hover over the inactive button, Connectivity Tests displays a message describing the permission that you need.
Permissions for viewing test results
If you don't have permission to view the Compute Engine resources in the network path that you are testing, you can still see the overall test result, but details about the tested resources are hidden.
In general, if you don't have access to a project resource listed in a trace,
the analysis result shows a message reading in part
No permission to view
Connectivity Tests hides the resource type, the resource name,
and other details. However,
the trace identifies the project that the resource is associated with.
Hierarchical firewall policies
Your trace might include a hierarchical firewall policy that you don't have permission to view. However, even if you don't have permission to view the policy details, you can still see the policy rules that apply to your VPC network. For details, see Effective firewall rules in the hierarchical firewall policies overview.
Permissions across multiple projects
If the network configuration that you test uses VPC Network Peering or Shared VPC, Connectivity Tests must have sufficient permissions to access configurations in the multiple projects that these networks use.
These permissions enable Connectivity Tests to run one or more full traces of the packet path across different networks and projects. Otherwise, Connectivity Tests can access configurations within only that project.
Permissions for Shared VPC networks
To run a test from a service project in a Shared VPC network, you
must have the
Compute Network Viewer role (
or the legacy
Project Viewer role (
the host project. This requirement exists because the network's firewall and
route configurations network are located in the host project. You must have one
of these roles
even if the resources that you are testing exist entirely within a single
To run a test from a Shared VPC host project to virtual machine
(VM) instances in a service project, you must also have one of these roles
roles/viewer) in the
service project. Additionally, when you create the test, you must provide the
service project ID. If you don't provide this ID, the
Connectivity Test shows an overall reachability result of
Unreachable with an
unknown IP address message.
Permissions for VPC Network Peering, Cloud VPN, and Cloud Interconnect
If you have a Connectivity Test that examines reachability between projects that are connected through VPC Network Peering, the results that you see vary depending on your permissions.
If you have one of these roles for the network that contains the source endpoint, but not the network that contains the destination, the analysis shows a partial result. That is, the analysis shows that the packet was sent to a VPC Network Peering network. However, Connectivity Tests can't provide any additional information for that network.