By Yasirhashmi．Jan 27, 2023
Google Kubernetes Engine (GKE) is a fully-managed, highly-scalable, and secure container orchestration service. However, as with any system, there are certain security best practices that we should follow to ensure that our GKE deployments are as secure as possible.
This would be a series of articles covering below best practices around securing GKE workloads:
- Enable Network Policies in GKE
- Role based access control (RBAC) in GKE
- Workload Identity
- Binary Authorization
- Hardening GKE cluster configurations
In the first part of this series, we covered Network policies and RBAC access controls.
In this article, we will discuss a very beautiful feature from GKE which is Workload Identity.
Workload Identity
Workload Identity is a feature in Google Kubernetes Engine (GKE) that allows authenticating pods running in the cluster to other Google Cloud Platform (GCP) services using the same identity as the identity of the Google Cloud Service account. This allows users to easily access other GCP services, such as Google Cloud Storage, Google Cloud SQL, or Google Cloud Spanner, without having to manage service account keys or configure authentication.
Workload identity binds Google cloud service accounts to GKE service accounts.
Benefits of Workload Identity:
- Increased security: By using Google-managed identities to authenticate workloads, we eliminate the need to use sensitive service account keys. This reduces the risk of keys being compromised and misused.
- Simplified access management: With Workload Identity, we can use IAM roles to control and audit access to Google Cloud Services. This makes it easier to manage access across multiple workloads.
- Increased flexibility: Workload Identity allows for different pods to have different access levels to GCP services and also allows for dynamic binding of service account to pods.
For example, let’s suppose we have a GKE cluster running a web application that needs to read and write data to a Google Cloud Storage bucket. With Workload Identity, we can assign the same identity to the pod running the web application as the identity of the service account that has access to the Cloud Storage bucket. This eliminates the need to manage service account keys for the pod and makes it easy to control access to the bucket.
Steps to configure applications for using workload identity
1. Get the credentials for the cluster
$ gcloud container clusters get-credentials my-gke-cluster — zone us-central1-c — project $PROJECT_ID
2. Create a Kubernetes service account for the application to use
$ kubectl create sa ksa-wi-sa
3. Create a IAM service account
$ gcloud iam service-accounts create iam-wi-sa
4. Create a test GCS bucket
$ gsutil mb -p ${PROJECT_ID} gs://workload-identity-${PROJECT_ID}
5. Grant access to the IAM service account to the bucket
$ gsutil iam ch serviceAccount:iam-wi-sa@${PROJECT_ID}.iam.gserviceaccount.com:roles/storage.admin gs://workload-identity-${PROJECT_ID}
6. Allow the Kubernetes service account to impersonate the IAM service account by adding an IAM policy binding between the two service accounts.
$ gcloud iam service-accounts add-iam-policy-binding iam-wi-sa@$PROJECT_ID.iam.gserviceaccount.com — role roles/iam.workloadIdentityUser — member “serviceAccount:$PROJECT_ID.svc.id.goog[default/ksa-wi-sa]”
This binding allows the Kubernetes service account to act as the IAM service account.
7. Annotate the Kubernetes service account with the email address of the IAM service account.
$ kubectl annotate serviceaccount ksa-wi-sa iam.gke.io/gcp-service-account=iam-wi-sa@${PROJECT_ID}.iam.gserviceaccount.com
8. Create a POD with kubernetes service account to validate Workload identity setup
9. Open an interactive session in the Pod:
$ kubectl exec -it workload-identity-test — /bin/bash
10. Run gcloud auth list. This should show IAM service account
# gcloud auth list
Credentialed Accounts
ACTIVE ACCOUNT
* iam-wi-sa@$PROJECT_ID.iam.gserviceaccount.com
To set the active account, run:
$ gcloud config set account `ACCOUNT`
11. Inside the shell, create a test file and upload it in the GCS bucket
# touch test-wi-file
# gsutil cp test-wi-file gs://workload-identity-${PROJECT_ID}
In this example, the pods running in the GKE cluster are able to access the GCS bucket and upload a test file using the same identity as that of the IAM service account. This simplifies authentication and access control to the GCP services, while also providing an additional layer of security.
Conclusion:
In conclusion, Workload Identity is a powerful feature of Google Kubernetes Engine (GKE) that offers a more secure and efficient way to authenticate pods running on a GKE cluster with Google Cloud Platform (GCP) services. With IAM service account impersonation, Workload Identity eliminates the need for manual management of service account keys and reduces the risk of security vulnerabilities.
Overall, Workload Identity is a valuable feature that can help organizations secure their Kubernetes workloads and access GCP services more securely. It is a must-have feature for organizations that are looking to fully leverage the benefits of GKE and GCP.
The original article published on Medium.
