When a request is received by the API Server (kubectl) it goes through a list of authentication plugins. The plugins examine the request and determine who is sending the request.
An authentication plugin returns the username and group of the authenticated user. Kubernetes doesn’t store that information anywhere; it uses it to verify whether the user is authorized to perform an action or not.
Users Link to heading
Kind of clients connecting the API Server:
- Humans (users)
- Pods (applications running in them)
Groups Link to heading
Human and ServiceAccounts can belong to multiple groups.
ServiceAccounts Link to heading
Every POD is associated with a ServiceAccount which represents the identity of the application running in the POD.
A POD authenticates with the API Server by sending the file var/run/secrets/kubernetes.io/serviceaccount/token, which is mounted in into each container file system through a secret volume.
ServiceAccount usernames are formatted like this:
system:serviceaccount:<namespace>:<service account name>
ServiceAccount resource Link to heading
ServiceAccount is yet another object in Kubernetes like Pods, ConfigMaps and so on, is also associated with namespaces.
Each pod is associated with a single ServiceAccount in the pod’s namespace.
Create service ServiceAccounts Link to heading
$ kubectl create serviceaccount foo
A custom token Secret has been created and associated with the ServiceAccount. The authentication tokens used in ServiceAccounts are JWT (JSON Web Tokens)
RBAC Authorization plugin Link to heading
RBAC determines if a user may perform an action or not. The API server exposes a REST interface, users perform actions by sending HTTP requests to the server. Users authenticate themselves by including credentials in the request (authentication token, username and password, or a client certificate).
| HTTP Method | Single Resource | Multiple Resources |
|---|---|---|
| GET | get (watch) | list (and watch) |
| POST | create | n/a |
| PUT | update | n/a |
| PATCH | patch | n/a |
| DELETE | delete | n/a |
RBAC Resources Link to heading
- Roles and ClusterRoles
- RoleBindings and ClusterRoleBindings
Roles define what can be done, while bindings define who can do it
The difference between Role and a ClusterRole, or between a RoleBinding and a ClusterRoleBinding, is that the Role and RoleBinding are namespaced resources, whereas the ClusterRole and ClusterRoleBinding are cluster-level resources
| For accessing | Role type to use | Binding type to use |
|---|---|---|
| Cluster-level resources (Nodes, PersistentVolumes) | ClusterRole | ClusterRoleBinding |
| Non-resource URLs (/api, /healthz) | ClusterRole | ClusterRoleBinding |
| Namespaced resources in any namespace (and across all namespaces) | ClusterRole | ClusterRoleBinding |
| Namespaced resources in a specific namespace (reusing the same ClusterRole in multiple namespaces) | ClusterRole | RoleBinding |
| Namespaced resources in a specific namespace (Role must be defined in each namespace) | Role | RoleBinding |
Sources:
https://www.manning.com/books/kubernetes-in-action