Shared Virtual Private Cloud (Shared VPC) uses Google Cloud Identity and Access Management (IAM) to separate network administration from workload deployment across distinct projects. A centralized host project contains the shared VPC networks, subnets, and routing infrastructure, while individual service projects house the applications and compute workloads. Access delegation across project boundaries relies on specific IAM roles to maintain security boundaries and uphold the principle of least privilege.
The Compute Security and Cross-Project Network Admin role (roles/compute.xpnAdmin), also called the Shared VPC Admin, manages the cross-project relationships and network sharing configurations across an organization. A principal assigned this role enables host projects, associates service projects with host projects, and delegates subnet access to users and service accounts. Because this role allows project linking and overarching network access control, it is granted at the organization or folder level in the Google Cloud resource hierarchy. Choose this role for centralized network security administrators who manage multi-project architecture rather than day-to-day application deployment.
The Compute Network User role (roles/compute.networkUser) enables principals to view available subnets and attach network interfaces to them without granting permission to alter network topology. Workload owners, deployment automation scripts, and managed service accounts in a service project require this role to deploy compute resources into the host project network. This role authorizes the creation of instances, instance templates, and load balancer configurations that consume IP addresses from designated host subnets. Assigning this role ensures developers can provision workloads independently while the central network team retains exclusive control over firewall rules, routing, and subnet sizing.
Subnet delegation assigns the Compute Network User role either across an entire host project or targeted directly to individual subnets. A Shared VPC Admin follows a distinct order of operations to enforce least privilege across service environments. First, grant the roles/compute.networkUser role on specific subnets to restrict service project teams to authorized IP address ranges. Second, grant the roles/compute.networkUser role at the host project level only when a service project requires access to all current and future subnets. Third, assign the role directly to service project service accounts, including the Compute Engine default service account or Google APIs Service Agent, to allow automated workload provisioning. Granting permissions at the individual subnet level isolates different application tiersâsuch as separating development and production environmentsâwithin the same shared VPC network.
Applying the principle of least privilege to hybrid and multi-project architectures means granting users and service accounts only the specific permissions they need to perform their tasks, and no more. This is achieved by using granular Identity and Access Management (IAM) roles at the most appropriate resource levelâsuch as a specific project, Shared VPC subnet, or individual serviceâinstead of granting broad project-level access. This approach secures network resources and limits the potential impact of compromised credentials.
For hybrid connectivity involving Cloud VPN or Cloud Interconnect, least privilege requires assigning roles that grant only the permissions needed to configure and manage the hybrid link. A network administrator who needs to set up a Cloud Router for dynamic routing over a VPN, for example, should be granted the Compute Network Admin role (roles/compute.networkAdmin) on the specific host project or VPC network. This role allows them to manage routers and VPN tunnels but does not grant permissions to modify firewall rules or instances in unrelated service projects, maintaining a clear trust boundary between the on-premises and cloud networks.
In a Shared VPC architecture, a host project contains the network, and service projects attach their workloads to subnets within it. Least privilege is applied by granting different roles at different scopes. Central network administrators might get the Compute Network Admin role on the host project to manage the entire Shared VPC. Meanwhile, a development team deploying an application needs permissions only within their service project and on a specific Shared VPC subnet. They can be granted the Compute Network User role (roles/compute.networkUser) on that particular subnet, which allows them to use the networkâsuch as create instances that use the subnetâwithout modifying the network's configuration, preserving centralized control.
When VPC networks are peered or connected across cloud providers, least privilege dictates tightly controlling which principals can modify the peering connection itself or route traffic across it. The Compute Network Admin role on the specific VPC network is typically required to manage peering. To control data flow, administrators use IAM with firewall rules; a principal might only need the Compute Security Admin role (roles/compute.securityAdmin) on a project to manage firewall rules that govern traffic to peered networks, without gaining any other administrative powers over the network infrastructure.
Provisioning services like load balancers often requires permissions across multiple resources. To apply least privilege, you assign a combination of specific roles. For instance, provisioning a load balancer might require the Compute Instance Admin role (roles/compute.instanceAdmin) in a service project to manage backend instances, and the Compute Network User role on the specific Shared VPC subnet to attach the load balancer's forwarding rule. By decomposing the task into required permissions, you avoid granting a single, overly permissive role like Project Editor, which would also allow unwanted modifications to other resources.
Selecting the appropriate IAM role for load balancer provisioning requires understanding the specific permissions each role grants and matching them to the operational scope of the load balancer type being deployed. Google Cloud provides predefined roles that bundle permissions for common tasks, allowing administrators to implement the principle of least privilege by granting only the permissions necessary for a given function.
The Compute Network Admin role (roles/compute.networkAdmin) provides comprehensive control over networking resources in Google Cloud, including the ability to create and manage networks, subnets, firewall rules, and load balancers. This role is recommended for network administrators who need to manage the full lifecycle of load balancing resources, from creating forwarding rules to configuring backend services and health checks. The grp-gcp-network-admins group typically receives this role along with Compute Shared VPC Admin and Compute Security Admin to handle all network-related operations including cloud load balancers. Choose this role when the principal needs to manage both the network infrastructure and load balancing components without requiring separate security-related permissions.
The Compute Load Balancer Admin role (roles/compute.loadBalancerAdmin) provides more focused permissions specifically for creating and managing load balancing resources. This role is ideal when the principal's primary responsibility is load balancer provisioning rather than broader network administration. This role is required alongside Compute Network Admin for tasks such as creating and managing HTTPS target proxies in load balancer configurations. The Load Balancer Admin role provides a more restrictive permission set than Network Admin, making it suitable for teams that need to manage load balancers without full network infrastructure control.
The Compute Security Admin role (roles/compute.securityAdmin) grants permissions to manage security-related resources including firewall rules, SSL certificates, and security policies. For load balancer provisioning, this role is specifically required when creating or modifying SSL certificates that terminate TLS traffic at the load balancer. Service project administrators need the Security Admin role in the service project to create and modify SSL certificates for load balancers. This role should be granted separately from Network Admin when the security and certificate management functions are performed by different team members, supporting separation of duties within the organization.
When provisioning load balancers in a Shared VPC environment, the permission model becomes more complex because the network resources reside in the host project while the load balancer resources may be created in a service project. Service project administrators need the Network Admin role in the service project to create load balancer components, while the host project must grant appropriate access to the subnets being used. For cross-project backend service referencing, the Load Balancer Services User role (roles/compute.loadBalancerServiceUser) is required in the project where the backend service is located, either at the project level or for individual backend services. This granular permission model ensures that service projects can reference backend services from other projects without granting unnecessary access to the entire network infrastructure.
The choice between these roles also depends on the type of load balancer being provisioned. Global External Application Load Balancers require permissions for global resources and CDN configuration, while Regional External and Internal Load Balancers require regional-specific permissions. Network Load Balancers require permissions for target pools and forwarding rules. For all load balancer types, the Network Admin role provides sufficient permissions to complete the provisioning task, while the Load Balancer Admin role offers a more focused alternative when the principal does not need broader network management capabilities. The Security Admin role is consistently required across all TLS-terminating load balancer types for certificate management, regardless of whether Network Admin or Load Balancer Admin is used for the primary provisioning tasks.
StudyCerts
StudyCertsroles/compute.xpnAdmin and roles/compute.networkUser.roles/compute.xpnAdmin role manages cross-project relationships and is granted at the organization or folder level, while roles/compute.networkUser allows workload provisioning without modifying network topology.roles/compute.loadBalancerServiceUser role is required when referencing backend services across different projects.The XPN Admin role (roles/compute.xpnAdmin) manages cross-project network relationships, enabling host projects and associating service projects with them. The Compute Network User role (roles/compute.networkUser) allows principals to deploy compute resources into existing subnets without modifying network configuration. XPN Admin is for network administrators managing the shared infrastructure; Network User is for developers deploying workloads.
Use Compute Load Balancer Admin when the principal's job focuses specifically on load balancer provisioning without needing broader network management capabilities. Use Compute Network Admin when the principal needs to manage both the load balancers and the underlying network infrastructure, including subnets, firewalls, and routing.
The Security Admin role (roles/compute.securityAdmin) is needed because load balancers that terminate TLS traffic require SSL certificate management. This role grants permissions to create and modify SSL certificates, and it should be granted separately from Network Admin to maintain separation of duties between network operations and security management.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills