Quick intro to K8s RBAC authorization

Role-based access control is a method to regulate access of individuals and services to compute and network resources.

We distinguish in: i) namespaced (e.g. pods) and ii) non-namespaced resources (e.g. nodes, persistent volumes). You can check them with:

kubectl api-resources --namespaced=true

Namespaced and non-namespaced resources are respectively handled by RBAC via namespaced Roles and non-namespaced clusterRoles. Roles and ClusterRoles define a set of permissions available (applicable) on resources, whereas role- and clusterrole- bindings specify who gets the permissions, i.e. the actual application of permissions, on either one namespace or all namespaces (both current and future created ones). 

For instance, to see default roles in k8s - https://kubernetes.io/docs/reference/access-authn-authz/rbac/.

You can create a role with:

kubectl -n <ns> create role <name> --verb=<verb> --resource=<res> -o yaml

Bindings are additive and specify what is allowed, so everything else is denied by default. Similarly:

kubectl -n <ns> create rolebinding <name> --role=<role-name> --user=<user> -o yaml

You can use the auth command to verify whethere a user can perform specific verb on resource:

• kubectl auth can-i <verb> <resource>
• kubectl auth can-i list pods --all-namespaces
• kubectl auth can-i <verb> <resource> --as <user>

Also, you can check bindings for a user in openshift - https://docs.openshift.com/container-platform/3.7/admin_guide/manage_rbac.html  

In K8s, there are 2 types of accounts: i) regular Users and ii) ServiceAccounts. The latter are a specific k8s resource and are managed by the k8s API, whereas users are not a specific resource, rather somebody with a client certificate that can connect to the cluster:

• the client cert is a certificate signed by the cluster certificate authority (CA) and has a specified username under the common name "/CN=<username>" in the certificate
• to get a signed cert, the client perform a certificate signing request to the kube api, and upon successfull login the k8s kube api uses its CA to sign the cert, update the signing request to include the cert and let the client download it and use it;

Consequently, users are generally managed by external services.

ServiceAccounts are defined per namespace and there is a default serviceAccount in every namespace. Each ServiceAccount is associated to a secret, to be used to access the K8s API.

kubectl get sa, secrets

will show the secret associated to each service account. You can then retrieve the secret as usual, with:

kubectl describe secret <secret-name>

The token is what is being used to authenticate requests to the k8s api.

The service account can be specified in a Pod and related (deployment, etc.) with the spec.serviceAccountName field. This will mount the certificate and the token in the pod under /run/secrets/kubernetes.io/serviceaccount/. Alternatively, the automatic mount can be disabled, since most pods will not need to directly communicate with the k8s api.  This can be done either directly on the ServiceAccount definition by setting the flag automountServiceAccountToken to false, or using the same flag within the spec of a specific Pod definition (see here).