Authorization via RBAC


Course Introduction
Cluster Security
Service Accounts
Course Conclusion
1m 35s
Start course

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:

Learning Objectives

  • Create Kubernetes service and user accounts
  • Grant permissions to accounts to modify Kubernetes resources
  • Access GCP resources from your GKE cluster

Intended Audience

  • 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

All right, so I've covered how to create Kubernetes service and user accounts. Now let me cover how to use them. Accounts can be granted or denied permissions for certain actions. Authorization in Kubernetes is accomplished with something called role-based access control or RBAC. In RBAC, you create roles and bind those roles to accounts. So you basically create sets of permissions and then assign them to either service or user accounts. These permissions include things like get, list, create, delete and update.

Now, roles work like a white list. There are no deny rules. And by default, all permissions are denied and you have to explicitly grant access where needed. For example, when you first create a Kubernetes service account, it will not have any permissions. Now, permissions are defined in either a role object or a cluster role object. The difference is, role objects require you to specify a namespace. Cluster role objects do not. So if you want to define a set of permissions, but limit it to a namespace, use a role. If you wanna define a cluster wide set of permissions, use a cluster role.

Once you have your permissions defined, then you need to assign them to one or more accounts. Roles are assigned by creating a RoleBinding and cluster roles are assigned by creating a ClusterRoleBinding. Actually, it's slightly more complicated than that. You can also use a RoleBinding to assign a cluster role as well. This is useful if you want to assign some defined set of non-namespace permissions, but limit it to a namespace. So that way, if I have 20 namespaces, I don't need to create 20 admin roles. I can create one admin cluster role, which is global, and then I can create 20 RoleBindings to end up with 20 accounts that each have admin permissions limited to a different namespace.

RBAC gives you complete control over any changes to your cluster. You can set up accounts to have as many or as few permissions as you need. And remember, accounts can either be user accounts or service accounts. So you control both internal and external access. It's important to note that for a GKE cluster, you can use either RBAC or IAM to control access for user accounts. A user can be granted permissions from either tool. Time for another demo. This time I'm going to show you how to add permissions to the service account we created in a previous lesson.

So first I need to create a role. This is what defines the permissions that I want to grant to the account. Now, the format of this command should seem familiar to you at this point. So I'm going to create a role named demo-role-viewer inside demo-namespace-1. Now under rules, you can see that I'm granting list and get. That means it will be able to list out the existing resources, as well as get the details for each resource. Now, it's not going to actually be able to change anything. It can't delete, create or update.

So now the role has been successfully created. Now I have to bind it to our account. So I'm going to use a RoleBinding to bind this role to the account named demo-serviceaccount. So you can see I've named the RoleBinding and I've set it to exist in demo-namespace-1. I told it to grant the permissions to demo-serviceaccounts and I passed in the name of the role to be bound, which is demo-role-viewer and it was successful.

So at this point, I've authorized demo-serviceaccount to be able to get information about a specific pod or to list out the current running pods. Now I'm not going to bother to actually demonstrate how to use the service account since that would involve a significant amount of work. If you wanna test this out yourself, I will leave that as an exercise for the viewer. Just make sure you remember two main things. Number one, roles and cluster roles define sets of permissions and number two, RoleBindings and ClusterRoleBindings assign sets of permissions to accounts.

That's all I have for this lesson. We've got one last topic to cover.

About the Author
Learning Paths

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.