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.