Kubernetes/Security and RBAC

API Server and Role Base Access Control

The Kubernetes API server provides CRUD actions (Create, Read, Update, Delete) interface for interacting with cluster state over a RESTful API. API calls can come only from 2 sources:

• kubectl
• POD

There is 4 stage process

1. Authentication
2. Authorization
3. Admission
4. Writing configuration CRUD actions to etcd database

RBAC is managed by 4 resources, divided over 2 groups

RBAC resources

Group-1 namespace resources	Group-2 cluster level resources	resources type
roles	cluster roles	defines what can be done
role bindings	cluster role bindings	defines who can do it

When deploying a pod a serviceaccount is created. The serviceaccount represents an identity of an app running in the pod. Token file holds authentication token.

kubectl create ns rbac
kubectl run apitest --image=nginx -n rbac #create test container, to run API call test from

Each pod has serviceaccount, the API authentication token is on a pod. When a pod makes API call uses the token, this allows to assumes the serviceaccount, so it gets identity. You can preview the token on the pod.

kubectl -n rbac1 exec -it apitest-<UID> -- /bin/sh        #connect to the container shell
# cat /var/run/secrets/kubernetes.io/serviceaccount/{token,namespace} #token and namespace that allows to connect to API server

Serviceaccounts can only be used within the same namespace.

kubectl get serviceaccounts --all-namespaces