Identity and Access Management (IAM) delegation is the process of granting permissions to automated service accounts so they can create network-attached resources inside a Shared VPC. In a Shared VPC setup, the network is owned by a central host project, but resources like virtual machines (VMs) or clusters are created in separate service projects. For this to work, the service accounts that perform these automated tasks need specific permissions in the host project to attach network interfaces to the correct subnets.
The core permission needed to use a Shared VPC subnet is the Compute Network User role (roles/compute.networkUser). A Shared VPC administrator can grant this role in two ways. First, they can bind it at the host project level, which gives the service account access to all subnets in that project. Second, they can bind it at the individual subnet level for more precise control, restricting the account to only specific subnets. Custom service accounts managed by users, which follow the format USER_ID@SERVICE_PROJECT_ID.iam.gserviceaccount.com, must have this role on the target subnets before they can create VM instances.
The Google APIs Service Agent is a Google-managed account that handles backend automation for a project. It is identified by SERVICE_PROJECT_NUMBER@cloudservices.gserviceaccount.com. When a managed instance group (MIG) in a service project needs to create VM instances using a Shared VPC subnet, this agent performs the network attachment. The Shared VPC Admin must grant this agent the roles/compute.networkUser role on the specific host project subnet used in the instance template. Without this permission, instance creation will fail with an authorization error.
The Kubernetes Engine Service Agent, identified as service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com, manages cluster infrastructure like nodes and load balancers in a Shared VPC. It needs multiple permissions in the host project. It must have the roles/compute.networkUser role on the shared subnets. It also needs the Host Service Agent User role (roles/container.hostServiceAgentUser) on the host project's own GKE service agent. To manage firewall rules in the host network, it requires additional permissions, which can be granted via the broad Compute Security Admin role or a custom role with specific firewall permissions like compute.firewalls.create.
The Dataproc Service Agent (service-SERVICE_PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com) needs cross-project permissions to deploy managed clusters into a Shared VPC network. It must be granted the roles/compute.networkUser role on the host project. If the clusters are configured to run using custom VM service accounts from other projects, the Dataproc Service Agent also needs the Service Account User and Service Account Token Creator roles on those custom accounts. This allows it to generate tokens and attach the correct identity to cluster nodes during deployment.
Subnet-level versus project-level network user role provisioning refers to the decision of where to assign the Compute Network User role (roles/compute.networkUser) within a Shared VPC host project. This choice determines whether a service account can access all subnets or only specific ones.
Subnet-level provisioning means granting the Compute Network User role directly on a single subnet resource. This creates a strict, least-privilege boundary. A principal with this binding can only attach resources, like VMs or connectors, to that particular subnet. This granular approach prevents the principal from accessing other, potentially more sensitive subnets within the same Shared VPC, enforcing strong network segmentation between different workloads or environments.
Project-level provisioning grants the Compute Network User role on the entire Shared VPC host project resource. This gives the principal permission to use any subnet within that host project's Shared VPC. This approach offers broad network access and simplifies administration by requiring only one IAM policy binding. It is suitable when all service projects are equally trusted and require uniform access to the entire network.
The choice between subnet-level and project-level provisioning is a trade-off between security and management ease. Subnet-level is the secure default for implementing least-privilege access; it is necessary when service projects host workloads of different sensitivity levels that must be isolated. Project-level provisioning reduces administrative overhead but increases risk, as it allows any authorized principal to attach resources anywhere in the network. The decision depends on the trust model: use project-level for uniform access, and subnet-level for segmented access.
Administrative role separation in Google Cloud involves assigning distinct IAM roles across Shared VPC host and service projects to enforce security boundaries while allowing resource deployment. This governance model separates network administration duties from service project operations using predefined roles at the organization, host project, and service project levels.
The Shared VPC Admin role (roles/compute.xpnAdmin) allows principals to associate service projects with a host project. Typically granted at the organization level, this role enables the network team to manage the Shared VPC relationship but does not grant permissions to manage the network resources themselves. It works alongside the Network Admin role for complete control.
The Network Admin role (roles/compute.networkAdmin) grants the ability to view and manage all networking resources in a project, such as VPCs, subnets, and routes. In a Shared VPC, Network Admins create and modify the shared subnets in the host project. They can view firewall rules but not modify them, maintaining a separation from security policy administration.
The Security Admin role (roles/compute.securityAdmin) is distinct from the Network Admin role and allows principals to manage firewall rules and security policies. This separation lets organizations divide network configuration responsibilities from security enforcement. Security Admins can create and modify firewall rules that control traffic to instances in both host and service projects.
The Network User role (roles/compute.networkUser) enables principals to use shared subnets without administrative control. Developers in service projects need this role granted on the host project to access the subnets, and also on their own service project to deploy resources. This dual-grant approach maintains the separation between network ownership and resource consumption.
The Instance Admin role (roles/compute.instanceAdmin) allows principals in a service project to create, modify, and delete Compute Engine instances. When assigned to developers, this lets them deploy VMs that use the shared subnets. Organizations can use an organization policy to prevent these instances from getting external IP addresses, controlling their exposure to the internet.
Effective Shared VPC IAM configuration uses three separate policies at different hierarchy levels. One policy at the organization level grants the network team the Shared VPC Admin and Network Admin roles, and the security team the Security Admin role. A second policy on the host project grants developers the Network User role. A third policy on each service project (or a folder containing them) grants developers both the Network User and Instance Admin roles. This structure ensures permissions flow down while keeping administrative functions separate.
Organizations can simplify management by placing all service projects in a folder and setting IAM policies at the folder level. All projects within that folder inherit these permissions. For a Shared VPC setup, it's best to have all host and service projects within the same folder hierarchy. This supports scenarios where development teams manage their own networks autonomously while still following organizational standards.
Using Google Groups to manage principals in IAM policies is recommended over using individual user accounts. Administrators add users to groups (like developers or sec-net) and then reference these groups in the IAM policy bindings. When personnel change, only the group membership needs updating, which reduces administrative work and the risk of inconsistent permissions across the organization.
StudyCerts
StudyCertsroles/compute.networkUser) is the core permission required for any identity to attach network interfaces to Shared VPC subnets.Subnet-level provisioning grants the Compute Network User role on a specific subnet, allowing a principal to attach resources only to that subnet. Project-level provisioning grants the role on the entire host project, allowing the principal to attach resources to any subnet within that project's Shared VPC.
Use Google-managed service accounts (like the Google APIs Service Agent) for automated platform operations such as managed instance group scaling or GKE cluster provisioning. Use custom service accounts for user-managed workloads, such as manually created VM instances, where you need direct control over the service account's identity and permissions.
Assign the Network Admin role to the network team for managing VPCs, subnets, and routes. Assign the Security Admin role to the security team for managing firewall rules and security policies. These are distinct predefined roles that prevent either team from performing the other's tasks, maintaining a clear separation of duties.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills