How to Securely Grant GKE Pods Cloud Storage Access?

PCSE By islever Editorial Last updated

Short answer

A Grant bucket access to the Pods by using Workload Identity Federation for GKE to eliminate long-lived service account keys.

Question

You are running code in Google Kubernetes Engine (GKE) containers in Google Cloud that require access to objects stored in a Cloud Storage bucket. You need to securely grant the Pods access to the bucket while minimizing management overhead. What should you do?
  1. Create a service account. Grant bucket access to the Pods by using Workload Identity Federation for GKE. Correct Answer
  2. Create a service account with keys. Store the keys in Secret Manager with a 30-day rotation schedule. Reference the keys in the Pods.
  3. Create a service account with keys. Store the keys as a Kubernetes secret. Reference the keys in the Pods.
  4. Create a service account with keys. Store the keys in Secret Manager. Reference the keys in the Pods.

Key Takeaways

Tests secure GKE-to-GCP service authentication, where candidates often mistakenly choose key-based solutions despite their high management overhead and security risks.

This page explains how to securely authenticate Google Kubernetes Engine workloads to Cloud Storage without managing long-lived credentials. It confirms that Workload Identity Federation is the correct approach to minimize operational overhead.

Common mistake: Option C is frequently chosen because storing keys as Kubernetes secrets seems straightforward, but it violates security best practices and creates unnecessary key rotation overhead compared to identity federation.

Expert Analysis

Why the Answer Is Correct

Workload Identity Federation for GKE maps Kubernetes Service Accounts directly to Google Service Accounts, eliminating the need to create, store, or rotate long-lived JSON keys. This approach aligns with Google Cloud’s zero-trust security model and drastically reduces administrative overhead. As noted in the community discussion, this method is explicitly recommended by Google for production GKE workloads accessing cloud resources. By binding a Kubernetes SA to a GCP SA and granting the bucket permissions to that GCP SA, pods automatically inherit the necessary IAM roles without credential injection.

Why the Other Options Are Wrong

Options B, C, and D all rely on generating and distributing service account keys, which introduces severe security vulnerabilities if leaked and requires continuous lifecycle management. Storing keys in Secret Manager or native Kubernetes secrets still demands manual rotation schedules and pod-level secret mounting, contradicting the requirement to minimize management overhead. Google explicitly advises against using service account keys whenever possible, favoring token-based federation instead.

Community Comment Notes

Multiple learners correctly identified option A after reviewing official documentation links shared in the thread. One commenter emphasized that workload identity is the standard recommendation for secure and manageable GKE access patterns. Another simply confirmed the choice based on familiarity with modern GCP authentication flows. The consensus strongly validates the vendor’s best practice guidance over legacy key-based methods.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When questions emphasize security combined with reduced operational burden in GKE, immediately prioritize Workload Identity or OIDC federation over any option involving service account keys. Always look for keywords like 'minimize management overhead' or 'securely grant access' as direct triggers for identity federation answers.

Frequently Asked Questions

Why not store service account keys in Secret Manager?

Secret Manager still requires manual key generation, injection into pods, and periodic rotation. Workload Identity Federation handles authentication natively without credential management overhead.

Does Workload Identity Federation support all GCP services?

Yes, it supports any Google Cloud API that accepts Google IAM tokens, including Cloud Storage, BigQuery, and Pub/Sub, making it universally applicable for GKE workloads.

More PCSE FAQ →

Community Votes

A
100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. jmaquino 👍 1 Answered A
    A: Workload Identity Federation for GKE is the recommended way for your workloads running on Google Kubernetes Engine (GKE) to access Google Cloud services in a secure and manageable way. https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity
  2. yokoyan 👍 1 Answered A
    I think it's A.
  3. 1e22522 👍 1 Answered A
    It's A i thikn

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to Implement TLS Interception for On-Premise Traffic in GCP

S-grade

How to Secure Vertex AI Training Jobs with Regional CMEK?

S-grade

How to Alert on Suspicious Outbound Traffic Using Threat Intelligence?

S-grade

How to Securely Host Databases Without Direct Internet Access?

S-grade

← Back to PCSE Study Guide