Running workloads with their own unique service identity in GCP allows you to exercise the security principle of least privilege: granting only the granular permissions required by a workload, and limiting the blast radius should it become compromised. With GKE Workload Identity, Kubernetes service accounts can be mapped to GCP service accounts to enable service identity authorization for requests to Google APIs and other services. In this lab, we will create a secret Cloud Run service and then map a service account to allow a GKE workload to access it.
Learning Objectives
Successfully complete this lab by achieving the following learning objectives:
- Deploy the Secret Service to Cloud Run
Inside your GCP console, activate the Cloud Shell. Then enable the required APIs for this lab.
Then clone the GitHub repo.
From the
gke-workload-identity/secret-servicedirectory inside the repo, build the Secret Service container, replacing<YOUR_PROJECT_ID>with your own project ID.Now deploy the container to Cloud Run, again substituting your project ID. When the service is deployed, try accessing the URL. You should receive a Forbidden message as you do not have permission to access the service without the correct identity.
- Create the GKE Cluster with Workload Identity
- Select Kubernetes Engine from the GCP menu, and click Create to create a new cluster.
- Select Standard if you are prompted to choose between Standard and Autopilot.
- Under Node Pools > default-pool, change the number of nodes to 1.
- Under Cluster > Security, tick the box to Enable Workload Identity.
- Click Create to create the cluster.
- When the cluster is ready, click the 3 dots Action menu on the Clusters page and select Connect. Then select Run in Cloud Shell to set up
kubectlin your Cloud Shell Terminal.
- Configure Service Accounts and IAM
In all of the following instructions, substitute
<YOUR_PROJECT_ID>with your own project ID.Create a service account for your Secret Agent workload.
Create an IAM policy to allow the Secret Agent service account to invoke the Secret Service in Cloud Run.
Change into the
gke-workload-identity/secret-agentdirectory and create the Kubernetes service account for the Secret Agent workload.Allow the Kubernetes service account to impersonate the Google service account by creating an IAM policy binding between the two.
Annotate the Kubernetes service account to complete the mapping.
- Deploy the Secret Agent workload to GKE
In all of the following instructions, substitute
<YOUR_PROJECT_ID>with your own project ID.Create some environment variables for the workload. Check the environment variables have been set correctly to your project ID and Cloud Run service URL respectively:
From within the
gke-workload-identity/secret-agentdirectory, create the agent Pod manifest.Build the Secret Agent container.
Deploy the Secret Agent Pod to GKE. Once the Pod is in a Running state, you should be able to observe that it can successfully connect to the Secret Service Cloud Run service by viewing its logs.
The agent contacts the secret service every 5 seconds and logs the results to STDOUT. It uses the GCP metadata server to generate a valid JWT token in order to identify itself as the service account you created earlier. This service account, and only this service account, is permitted to invoke the Cloud Run service.
Note that the JWT token generated by the agent workload will expire after an hour, after which the Pod will log a Forbidden error, which is expected.
