Chapter 12. Securing the Kubernetes API server

In chapter 8 you learned how applications running in pods can talk to the API server to retrieve or change the state of resources deployed in the cluster. To authenticate with the API server, you used the ServiceAccount token mounted into the pod. In this chapter, you’ll learn what ServiceAccounts are and how to configure their permissions, as well as permissions for other subjects using the cluster.

12.1. Understanding authentication

In the previous chapter, we said the API server can be configured with one or more authentication plugins (and the same is true for authorization plugins). When a request is received by the API server, it goes through the list of authentication plugins, so they can each examine the request and try to determine who’s sending the request. The first plugin that can extract that information from the request returns the username, user ID, and the groups the client belongs to back to the API server core. The API server stops invoking the remaining authentication plugins and continues onto the authorization phase.

Several authentication plugins are available. They obtain the identity of the client using the following methods:

12.1.1. Users and groups

12.1.2. Introducing ServiceAccounts

12.1.3. Creating ServiceAccounts

12.1.4. Assigning a ServiceAccount to a pod

12.2. Securing the cluster with role-based access control

12.2.1. Introducing the RBAC authorization plugin

12.2.2. Introducing RBAC resources

12.2.3. Using Roles and RoleBindings

12.2.4. Using ClusterRoles and ClusterRoleBindings

12.2.5. Understanding default ClusterRoles and ClusterRoleBindings

12.2.6. Granting authorization permissions wisely

12.3. Summary