Lab
A Cloud Guru

Using Workload Identity on GKE

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.

Try for free Contact sales

Path Info

Level

Intermediate

Duration

1h 0m

Published

Apr 09, 2021

Challenge

Deploy the Secret Service to Cloud Run
1. Inside your GCP console, activate the Cloud Shell. Then enable the required APIs for this lab:
2. Clone the GitHub repo https://github.com/linuxacademy/content-google-certified-pro-cloud-developer.
3. From the gke-workload-identity/secret-service directory inside the repo, build the Secret service container, replacing <YOUR_PROJECT_ID> with your own project ID.
4. 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.
Challenge

Create the GKE Cluster with Workload Identity
1. Select Kubernetes Engine from the GCP menu, and click Create to create a new cluster.
2. At the top, choose SWITCH TO STANDARD CLUSTER.
3. Under Node Pools > default-pool, change the number of nodes to 1.
4. Under Cluster > Security, tick the box to Enable Workload Identity and Enable Shielded GKE Nodes.
5. Click Create to create the cluster.
6. When the cluster is ready, click the three-dot Action menu to connect. Copy the Command-line access command. Paste the command in your Cloud Shell terminal to set up kubectl.
Challenge

Configure Service Accounts and IAM
Note: In all of the following instructions, substitute <YOUR_PROJECT_ID> with your own project ID.
1. Create a service account for your Secret Agent workload.
2. Create an IAM policy to allow the Secret Agent service account to invoke the Secret Service in Cloud Run.
3. Change into the gke-workload-identity/secret-agent directory and create the Kubernetes service account for the Secret Agent workload.
4. Allow the Kubernetes service account to impersonate the Google service account by creating an IAM policy binding between them.
5. Annotate the Kubernetes service account to complete the mapping.
Challenge

Deploy the Secret Agent Workload to GKE
Note: In all of the following instructions, substitute <YOUR_PROJECT_ID> with your own project ID.
1. Create some environment variables for the workload.
2. Check the environment variables have been set correctly to your project ID and Cloud Run service URL, respectively.
3. From within the gke-workload-identity/secret-agent directory, create the agent Pod manifest.
4. Build the Secret Agent container.
5. 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.

Author

A Cloud Guru

The Cloud Content team comprises subject matter experts hyper focused on services offered by the leading cloud vendors (AWS, GCP, and Azure), as well as cloud-related technologies such as Linux and DevOps. The team is thrilled to share their knowledge to help you build modern tech solutions from the ground up, secure and optimize your environments, and so much more!

What's a lab?

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.