An enterprise runs a multi-tier analytics application on Google Kubernetes Engine (GKE). A backend workload running in the data-processing namespace requires access to Cloud Storage and Cloud Bigtable. The security team mandates the following requirements: The backend application must authenticate to Google Cloud APIs following the principle of least privilege, without managing or storing long-lived service account keys in the cluster. Pods running on the same node pool from other namespaces must not inherit the backend workload's Google Cloud API permissions. Network traffic must be restricted at Layer 4 so that backend Pods only allow authorized cluster communication and can reach the required Google Cloud endpoints. Which architectural approach should you implement to satisfy these requirements?

Configure Workload Identity to bind the backend Kubernetes Service Account to a dedicated Google Service Account with least-privilege IAM roles, and deploy Kubernetes Network Policies to restrict Layer 4 pod communication while allowing egress to the GKE metadata server and Google APIs: ### What Workload Identity and Network Policies Are **Workload Identity** is the recommended best practice for managing authentication and authorization for GKE workloads accessing Google Cloud services. It links a **Kubernetes Service Account (KSA)** directly to an **IAM Google Service Account (GSA)**. **Kubernetes Network Policies** provide Layer 3 and Layer 4 packet filtering directly at the Pod and namespace boundaries. ### How It Meets the Requirements - **Least-Privilege API Authentication**: Binding the specific KSA in the `data-processing` namespace to a dedicated GSA ensures that only Pods running with that KSA obtain temporary OAuth 2.0 tokens for Cloud Storage and Cloud Bigtable. - **Preventing Privilege Inheritance**: Workload Identity intercepts requests to the GKE metadata server. Pods in other namespaces or using other KSAs cannot impersonate this GSA or access its permissions, even if co-located on the same physical node. - **L4 Network Security Posture**: Applying **Kubernetes Network Policies** restricts inbound and outbound transport connections at the namespace level, isolating the backend Pods while explicitly permitting required DNS, metadata server queries, and Google API egress. ### Key Advantages and Capabilities - **No Key Management**: Completely eliminates the operational burden and security risk of generating, rotating, and storing long-lived service account key JSON files. - **Namespace-Scoped Granularity**: Enforces discrete boundaries between workloads running in multi-tenant cluster configurations. - **Defense-in-Depth**: Combines robust Google Cloud identity controls with Layer 4 network isolation rules within the GKE data plane. ### Why This Is Optimal This architecture avoids node-level privilege escalation, adheres strictly to Google Cloud security best practices for GKE multi-tenancy, and protects the cluster's network perimeter without requiring intrusive application-level code modifications.

StudyCerts

Gke Workload Identity Network Policies Security | Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam! | StudyCerts

Professional Cloud Architect

Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Intermediate

Prepare and test your skills

Track Readiness

Set Exam Goal

Gke Workload Identity Network Policies Security

Section: Container orchestration

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise runs a multi-tier analytics application on Google Kubernetes Engine (GKE). A backend workload running in the data-processing namespace requires access to Cloud Storage and Cloud Bigtable.

The security team mandates the following requirements:

The backend application must authenticate to Google Cloud APIs following the principle of least privilege, without managing or storing long-lived service account keys in the cluster.
Pods running on the same node pool from other namespaces must not inherit the backend workload's Google Cloud API permissions.
Network traffic must be restricted at Layer 4 so that backend Pods only allow authorized cluster communication and can reach the required Google Cloud endpoints.

Which architectural approach should you implement to satisfy these requirements?

Grant the Cloud Storage and Cloud Bigtable IAM roles to the GKE node pool's default Compute Engine service account, and use Kubernetes RBAC RoleBindings to block egress traffic to unwanted IP ranges

Deploy an external GKE Ingress controller with SSL termination for outbound API calls, and configure Cloud Armor security policies to restrict inter-pod communication within the cluster

Configure Workload Identity to bind the backend Kubernetes Service Account to a dedicated Google Service Account with least-privilege IAM roles, and deploy Kubernetes Network Policies to restrict Layer 4 pod communication while allowing egress to the GKE metadata server and Google APIs

Generate a JSON service account key for a Google Service Account with the required IAM roles, store it in a Kubernetes Secret, mount the Secret to the backend Pods, and configure VPC firewall rules to restrict node egress

Professional Cloud Architect

Gke Workload Identity Network Policies Security

Related questions