Professional Cloud Network Engineer
Cross-project Identity and Access Management (IAM) configuration in Google Kubernetes Engine (GKE) establishes the access permissions that service agents in a cluster project need to consume network and security resources in another project. A Shared VPC design separates the centralized network host project from individual service projects where clusters run. Connecting these environments requires granting specific IAM roles to Google-managed service agents across project boundaries.
The Service Account Token Creator and Service Account User roles allow cluster management systems to authenticate node workloads using identity accounts from outside the cluster project. When a GKE node uses a custom service account located in a separate project, the Compute Engine service agent requires the Service Account Token Creator role on that custom service account to generate operational tokens. The GKE service agent requires the Service Account User role on that same custom account to impersonate it for workload authentication. Both role bindings use the service agent identity formats service-CLUSTER_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com and service-CLUSTER_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.
Organization policy constraints govern whether service accounts in one project can attach to compute resources running in another project. Administrators must explicitly configure the organization policy to permit cross-project service account attachment before attempting cross-project role assignments. Once the organization policy permits cross-project attachment, administrators use the Google Cloud console or the gcloud iam service-accounts add-iam-policy-binding command to bind the required roles to the external service agent.
Shared VPC networking permissions authorize service project accounts to provision compute instances that connect directly to host project subnets. Service project service accounts require the Kubernetes Engine Host Service Agent User (roles/container.hostServiceAgentUser) role at the host project level and the Compute Network User (roles/compute.networkUser) role at the host project or subnet level. The Host Service Agent User role gives the service project GKE service agent permission to coordinate networking with the host project GKE service agent. The Compute Network User role allows GKE nodes in the service project to bind to the shared subnet and consume its IP address space.
Workload Identity Federation for GKE links Kubernetes service accounts inside a cluster to IAM service accounts that can exist in external projects. This relationship lets containerized workloads authenticate to Google Cloud services without storing long-lived service account keys in the cluster. Administrators bind the Kubernetes service account to the IAM service account by granting it the Workload Identity User role on that IAM account. The IAM service account retains only the specific permissions needed for the target resources, maintaining strict security boundaries across projects.
Google-managed service agents represent internal Google APIs and execute lifecycle operations on behalf of the cluster. The Kubernetes Engine Service Agent (service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com) manages cluster resources, including network attachments and disk encryption. When a cluster uses customer-managed encryption keys (CMEK), the Cloud KMS CryptoKey Encrypter/Decrypter role must be granted to the Compute Engine service agent so Persistent Disks can access the keys. Other services such as Cloud Composer, Artifact Registry, and Cloud Pub/Sub also rely on service agents that require cross-project IAM grants when dependencies span multiple projects.
Subnet topologies in GKE define how IPv4 address space is divided among cluster nodes, Pods, and Services inside a Virtual Private Cloud (VPC). VPC-native clusters use alias IP address ranges to allocate routable IP addresses directly from primary and secondary subnet CIDR blocks defined in the Shared VPC host project. This configuration separates central network management from cluster operations and ensures predictable routing across the enterprise.
A primary IPv4 address range supplies internal IP addresses for cluster nodes, internal load balancers, and control plane endpoints. Google Cloud reserves the first two and last two IP addresses of every subnet primary range, supporting subnet sizes between a /29 minimum and a /8 maximum. Clusters using Private Service Connect (PSC) consume an IP address from the primary subnet range for the control plane endpoint unless configured with a dedicated endpoint subnetwork. Primary subnet ranges can be expanded dynamically without downtime, but shrinking or reassigning an existing primary range is not supported.
Secondary IP ranges provide dedicated CIDR blocks within a subnet for Kubernetes Pods and ClusterIP Services. In a Shared VPC deployment, network administrators must create both secondary ranges in the host project before a cluster can be created in the service project. Subnets support up to 30 secondary IP ranges, and GKE defaults to allocating a /14 block for Pods and a /20 block for Services if custom ranges are omitted. These ranges must never overlap with node primary ranges, on-premises network routes, or the 172.17.0.0/16 range reserved by Cloud SQL.
Pod density settings determine the size of the CIDR slice assigned to each individual node from the Pod secondary range. Standard clusters assign a /24 CIDR slice per node by default to accommodate up to 110 Pods, but administrators can configure a /23 slice for up to 256 Pods or smaller slices for reduced workloads. Autopilot clusters use a fixed allocation of 32 Pods per node, which assigns a /26 CIDR slice per node. Cluster autoscaling calculations must account for these slice sizes to prevent node creation failures caused by Pod CIDR exhaustion, and administrators can attach discontiguous multi-Pod CIDR ranges if initial capacity runs out.
Alternative IP addressing schemes preserve scarce RFC 1918 address space by using non-RFC 1918 blocks or privately used public IP (PUPI) ranges for Pods. Google Cloud supports the RFC 6598 100.64.0.0/10 block for cluster allocations, which avoids hardware routing issues common to Class E space. PUPI ranges can only be used as secondary IP ranges for Pods and cannot be applied to node or Service primary ranges. When using non-RFC 1918 ranges, administrators must configure the IP masquerade agent (ip-masq-agent) or adjust default Source Network Address Translation (SNAT) so Pod-to-Pod and Pod-to-Service traffic is not masqueraded as public internet traffic.
Cross-project IP allocation requires specific IAM permissions on the host project's network resources. The service project GKE service agent must hold the Kubernetes Engine Host Service Agent User role on the host project to coordinate IP allocations. The Compute Network User role must also be granted on the specific subnet to the service project Google APIs account and GKE service account. When reserving static internal IP addresses in a service project from a shared subnet, the request must reference the full resource URL of the host project subnet.
A private GKE cluster isolates compute workloads from the public internet by assigning private internal IP addresses to worker nodes and providing a private control plane endpoint. Deploying private clusters in a Shared VPC architecture centralizes network security policy in the host project while allowing workloads in service projects to communicate across the internal network.
A Shared VPC architecture consists of a centralized host project that shares network infrastructure with one or more attached service projects. The host project owns the VPC network, subnets, secondary IP ranges, and firewall rules used by clusters in the service projects. Standard clusters using Shared VPC must be VPC-native, whereas Autopilot clusters are VPC-native by default. Shared VPC configuration must be established during cluster creation, as existing clusters cannot be converted to use Shared VPC.
Provisioning a private GKE cluster in a Shared VPC requires attaching the cluster to the host project's pre-configured shared subnet. Enabling the private nodes setting prevents the assignment of public IP addresses to worker nodes, ensuring they only receive internal addresses from the primary subnet range. The administrator must also define a /28 control plane IP range that does not overlap with any other CIDR block in the VPC network. The service project GKE service account must hold the compute.networkUser role on the target subnet before provisioning begins.
Control plane access security restricts administrative cluster endpoints to authorized internal or external networks. Administrators define master authorized networks using specific CIDR blocks to limit which networks can communicate with the cluster control plane. For private endpoints accessed across peered on-premises networks, administrators may need to deploy network proxies because VPC Network Peering does not support transitive routing. Clusters using Private Service Connect endpoints require compute.networks.get and compute.networks.updatePeering permissions on the host project to establish control plane connectivity.
Host project firewall rules define the security boundary for GKE traffic across nodes, Pods, and Services in all attached service projects. Central network administrators manage these rules to govern inbound and outbound traffic flows based on IP ranges, protocols, and ports. When Kubernetes creates external resources like load balancers, the host project must have matching firewall rules to permit traffic. If Kubernetes lacks host project permissions to create firewall rules automatically, it records events alerting administrators to create the rules manually.
Outbound internet traffic and access to Google APIs from private cluster nodes require specialized gateway configurations in the Shared VPC. Cloud NAT provides outbound internet connectivity for private nodes and Pods by translating internal IP addresses to external gateway addresses without exposing nodes to inbound connections. Private Google Access allows private nodes and Pods to reach Google APIs and services using internal Google-owned addresses instead of traversing the public internet. While Private Google Access is enabled automatically for standard private clusters, it must be enabled manually on the host subnet when using Shared VPC.
Static internal IP addresses can be reserved within a service project while drawing addresses from the host project's shared subnets. These reservations are commonly used for internal load balancers supporting service project applications. To create a static reservation, the user or service account must possess the compute.subnetworks.use permission, typically granted via the Compute Network User role on that subnet. The reservation command must explicitly reference the full resource URL of the host project subnet.
The service project's GKE service agent must be granted the Kubernetes Engine Host Service Agent User role (roles/container.hostServiceAgentUser) at the host project level. Additionally, the Compute Network User role (roles/compute.networkUser) must be granted to the service project GKE service agent and Google APIs service account on the specific shared subnet.
No, secondary IP ranges cannot be created dynamically by GKE in a Shared VPC. A host project network administrator must explicitly create the primary subnet range and all secondary ranges in the host project before cluster provisioning begins in the service project.
Private GKE clusters assign only internal IP addresses to worker nodes and Pods, preventing direct access to the public internet. Cloud NAT provides outbound connectivity by translating private IP addresses to public NAT IP addresses, allowing nodes and Pods to download external dependencies without exposing them to inbound internet connections.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts