The course is part of these learning pathsSee 3 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
In this course, I am going to be talking about basic cluster security. Any request to view or modify the resources in a cluster needs to come from an account. That account needs to be both authenticated, that is, have the correct credentials, and authorized, that is, have sufficient permission to complete the request.
So let's start by talking about the two types of accounts: Service accounts and user accounts. Now, when a pod wants to view cluster resources or make a change, it uses a service account. When a user wants to list or modify cluster resources, they use a user account. So pods use service accounts and users use user accounts. Pretty simple so far, right? Kubernetes service accounts are not related to Kubernetes services.
Service accounts provide an identity for processes running inside a pod. They are used to manage internal access to your cluster. So pod A might run under a service account that gives it no permissions at all. This pod could not create new pods. It couldn't remove any pods. It can't even see what other pods exist. Pod B might run under a service account that has every permission. So it could list out all the current pods. It could delete any pods. And it can even add new ones.
Service accounts let you control what a pod can do in relation to managing a cluster's resources. Now, service accounts are namespaced. So you can have multiple service accounts with the same name, as long as they each live in a different namespace. Every namespace has a default service account called default. So when you create a pod, if you do not specify a service account, it is automatically assigned the default service account in that namespace. So, that means every Kubernetes cluster has a default namespace and a default service account inside that namespace. The default service account has no permissions. So, if you do not want your pods to be able to manage cluster resources, you can of course, just stick with the default service account. But you can also easily create new service accounts as well. You want to always follow the principle of least privilege, and only assign permissions as needed.
Let me quickly show you how to create a service account. First, I'll create a GKE cluster. Now, I don't need anything special, just a basic cluster I can run some command on. So I am just going to select the My first cluster quickstart option. Now, if you are going to follow along, you can pick the option My first cluster under the cluster setup guides. And I am going to accept all the default options. Now, when I click on Create, it's going to create the cluster. If I wanted to, I could create the same cluster using the command line. And so you can choose the Command Line option to get that command. I am assuming you already know how to create a cluster, so let's keep this simple and I'll just click on the Create button instead. Now, creating the cluster will take a while, so let me skip ahead.
All right, now that the cluster has been created, I am going to switch to using the command line. First, let me check for any gcloud updates. Next, I need to download my credentials to the local machine so that I can access my new cluster. All right, so I've created the cluster. I've connected to it. Now let's create that service account. I have not created any service accounts but there are some default accounts in each namespace. So let me create a new service account that has a few permissions. Service accounts are created by supplying a YAML file, or by passing in information in YAML format, just as I am doing here. You can see that I specified the type as ServiceAccount. And I also set a name and a namespace for this to live in. All right, the service account has been created. That's it. That's all there is to show for right now. You may be wondering what the point is. But don't worry. Later I will show you how to assign permissions to it. For now, you just need to understand how to create a service account.
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.