A developer needs to configure a Pod to access a cloud provider's API for object storage. Instead of hardcoding API keys or using Kubernetes Secrets directly, the organization prefers to leverage the cloud provider's Identity and Access Management (IAM) roles linked to Kubernetes Service Accounts. What is the primary benefit of using this approach for credential management compared to storing static credentials in Secrets?
- AIt provides a centralized audit log for all API calls made by the Pod.
- BIt eliminates the need for network-level access controls for the Pod.
- CIt simplifies the process of rotating credentials automatically.
- DIt decouples credential management from the application, reducing the risk of static credential exposure and simplifying credential rotation.
Show answer & explanationAnswer & explanation
Correct answer: D. It decouples credential management from the application, reducing the risk of static credential exposure and simplifying credential rotation.
Using cloud provider IAM roles with Kubernetes Service Accounts (e.g., AWS IAM Roles for Service Accounts, Azure Workload Identity, GCP Workload Identity) is a best practice. It decouples the application from static credentials, allowing for short-lived, automatically rotated tokens and fine-grained permissions, significantly reducing the risk of static credential exposure and simplifying management.
Why the other options are wrong
- A. Cloud provider audit logs track API calls, but this benefit is inherent to using the cloud provider's IAM, not *primarily* the reason for choosing this over Secrets. Secrets can also be audited if access is logged.
- B. Network access controls (e.g., NetworkPolicies) are still necessary to restrict network communication, regardless of how credentials are managed.
- C. While it can facilitate rotation, the primary benefit is decoupling and reduced exposure, and rotation is often handled by the cloud provider's IAM, not Kubernetes directly simplifying it for the user.
Workload Identity
A mechanism that allows Kubernetes Service Accounts to assume cloud provider IAM roles, enabling pods to access cloud resources without storing long-lived, static credentials.
- Uses short-lived tokens for authentication.
- Integrates Kubernetes RBAC with cloud IAM.
- Reduces the risk of credential compromise.
- Simplifies credential management and rotation.
Memory trick: IAM roles for service accounts: cloud and K8s together make access right.