Using Service Accounts with GKE Applications
Why It Is Important
Service accounts are essential for GKE applications because they provide a secure way for workloads running in Kubernetes to authenticate and access Google Cloud services. Rather than embedding user credentials or API keys in your application code, service accounts offer a managed identity that follows the principle of least privilege. This approach enhances security, simplifies credential management, and enables fine-grained access control for your containerized applications.
What It Is
A service account in the context of GKE is a special type of Google Cloud account that represents an application or workload rather than an individual user. When running applications in GKE, there are two types of service accounts to consider:
1. Google Service Accounts (GSA): These are Google Cloud IAM service accounts that have permissions to access Google Cloud resources like Cloud Storage, BigQuery, or Pub/Sub.
2. Kubernetes Service Accounts (KSA): These are native Kubernetes resources that provide an identity for pods running in your cluster.
Workload Identity is the recommended way to connect these two, allowing Kubernetes service accounts to act as Google service accounts.
How It Works
Workload Identity (Recommended Approach):
1. Enable Workload Identity on your GKE cluster
2. Create a Kubernetes service account in your namespace
3. Create a Google service account with the required IAM permissions
4. Bind the Kubernetes service account to the Google service account using an IAM policy binding
5. Annotate the Kubernetes service account with the Google service account email
6. Configure your pods to use the Kubernetes service account
When a pod uses the annotated Kubernetes service account, it can authenticate as the linked Google service account and access permitted Google Cloud resources.
Node Service Account (Legacy Approach):
By default, pods can use the GCE default service account attached to the node. This is less secure because all pods on the node share the same permissions.
Key Commands and Configurations
Enable Workload Identity on a new cluster:
gcloud container clusters create CLUSTER_NAME --workload-pool=PROJECT_ID.svc.id.goog
Annotate a Kubernetes service account:
kubectl annotate serviceaccount KSA_NAME --namespace NAMESPACE iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
Add IAM binding:
gcloud iam service-accounts add-iam-policy-binding GSA_NAME@PROJECT_ID.iam.gserviceaccount.com --role roles/iam.workloadIdentityUser --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
Exam Tips: Answering Questions on Using Service Accounts with GKE Applications
1. Workload Identity is the preferred solution: When questions ask about the most secure or recommended way for GKE applications to access Google Cloud services, Workload Identity is typically the correct answer.
2. Understand the binding relationship: Remember that you bind KSA to GSA, not the other way around. The Kubernetes service account is annotated with the Google service account email.
3. Know the security implications: Questions about security best practices will favor Workload Identity over using the node service account or mounting service account keys as secrets.
4. Recognize the components: Be familiar with the workload pool format: PROJECT_ID.svc.id.goog and the member format for IAM bindings.
5. Namespace awareness: Kubernetes service accounts are namespace-scoped. The IAM binding includes both namespace and service account name.
6. Default behavior: Know that if Workload Identity is not configured, pods may fall back to using the node's service account, which violates least privilege principles.
7. Look for keywords: When you see terms like 'granular permissions,' 'pod-level identity,' or 'least privilege for GKE workloads,' think Workload Identity.
8. Avoid key-based solutions: If an answer suggests creating service account keys and mounting them as Kubernetes secrets, this is generally not the recommended approach due to key management overhead and security risks.