The course is part of these learning pathsSee 2 more
In order to manage the resources inside a Kubernetes cluster, you will need to have the right permissions. This course will demonstrate how to use Kubernetes role-based access control (RBAC) to create roles and bind them to both user and service accounts.
If you have any comments or feedback, feel free to reach out to us at: email@example.com.
- Create Kubernetes service and user accounts
- Grant permissions to accounts to modify Kubernetes resources
- Access GCP resources from your GKE cluster
- Engineers who want to deploy applications on a Kubernetes cluster
- People who want to get GCP certified (eg: Professional Cloud Developer)
- Basic understanding of Kubernetes
- Experience building and deploying containers
- Complete the “GKE Services and Network Policies Course” course
Sometimes you need a pod to be able to access or modify something outside of the cluster. For example, maybe it needs to access an image in cloud storage or pull some data from big table. Now, one way of accomplishing this is to create a Google service account, export the keys and store them as a Kubernetes secret. Your container can then use the keys to access resources in Google cloud. However, manually managing and rotating access keys can be a lot of work. And if one of your keys is compromised, you could have a serious security breach. Luckily, Google has provided a safer and easier way.
Workload identity allows you to configure a Kubernetes service account to act just like a Google service account. Your pods running under a Kubernetes service account can automatically authenticate as the Google service accounts when accessing Google cloud APIs. In this way, you can grant permissions for certain pods to access certain Google resources.
Let's do one last demonstration. I'm going to show you how to set up a workload identity. Workload identity first needs to be enabled on your cluster. Now you can do this during cluster creation. If you look under the Security section, there's an option called Enable Workload Identity. However, I already have my existing cluster, so let's go through the steps to enable it for that. Now here's the command for enabling workload identity on our current cluster. I need to pass in the name of my cluster, which is my-first-cluster-1. And I need to specify the name of my project, which is daniel-sandbox-305920.
Now, if you wanna run the same command, just make sure to replace those two values with the appropriate ones. You might've chosen the same cluster name as I did, but at a minimum, you're going to need to change the string daniel-sandbox-305920 to match your project id. Now this command is going to take a while to complete, so I'm going to skip ahead. Next, I need to grant the Kubernetes service account permission to use the IAM service account with this command. So again, I'm passing in my project id, which is daniel-sandbox-305920. I also need to specify the Kubernetes namespace and the Kubernetes service account. And these are demo-namespace-1 for the namespace and demo-service-account for the Kubernetes service account.
Finally, I also need to specify the Google service account to associate it with which I created as kubernetes-demo-service-account. Now we need to add an annotation to the Kubernetes service account. So once again, I'm gonna have to pass in the required values for namespace, Kubernetes service account, Google service account and the project id. And at this point, workload identity has been set up. My Kubernetes service account now has been linked to the Google service account.
So at this point, any permissions the Google service account has, will also be shared with any pod assigned to the Kubernetes service account. So if I had a container with some code that wanted to change some files in a Google cloud storage bucket, I could accomplish that by simply modifying a few permissions. Once again, I'm not going to actually demonstrate this because it would take too long and it would be too complicated. You are certainly welcome to try it yourself. Well, that's it for this lesson. We'll do a quick wrap up and then you'll be done with this course.
Daniel began his career as a Software Engineer, focusing mostly on web and mobile development. After twenty years of dealing with insufficient training and fragmented documentation, he decided to use his extensive experience to help the next generation of engineers.
Daniel has spent his most recent years designing and running technical classes for both Amazon and Microsoft. Today at Cloud Academy, he is working on building out an extensive Google Cloud training library.
When he isn’t working or tinkering in his home lab, Daniel enjoys BBQing, target shooting, and watching classic movies.