Difference between revisions of "Kubernetes/Security and RBAC"
Jump to navigation
Jump to search
(Created page with "= Role Base Access Control = The Kubernetes API server provides CRUD (Create, Read, Update, Delete) interface for interacting with cluster state over a RESTful API. API calls...") |
|||
| Line 1: | Line 1: | ||
= Role Base Access Control = | = API Server and Role Base Access Control = | ||
The Kubernetes API server provides CRUD (Create, Read, Update, Delete) interface for interacting with cluster state over a RESTful API. API calls can come only from 2 sources: | 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 | * kubectl | ||
* POD | * POD | ||
| Line 13: | Line 13: | ||
RBAC is managed by 4 resources, divided over 2 groups | |||
{| class="wikitable" | {| class="wikitable" | ||
|+ RBAC resources | |+ RBAC resources | ||
| Line 29: | Line 29: | ||
! defines who can do it | ! defines who can do it | ||
|} | |} | ||
When deploying a <tt>pod</tt> a <tt>serviceaccount</tt> is created. The <tt>serviceaccount</tt> represents an identity of an app running in the <tt>pod</tt>. Token file holds authentication token. | |||
<source lang=bash> | |||
kubectl create ns rbac | |||
kubectl run apitest --image=nginx -n rbac #create test container, to run API call test from | |||
</source> | |||
Each pod has <tt>serviceaccount</tt>, 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. | |||
<source lang=bash> | |||
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 | |||
</source> | |||
<tt>Serviceaccounts</tt> can only be used within the same namespace. | |||
<source lang=bash> | |||
kubectl get serviceaccounts --all-namespaces | |||
</source> | |||
Revision as of 22:28, 6 July 2019
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
- Authentication
- Authorization
- Admission
- Writing configuration CRUD actions to etcd database
RBAC is managed by 4 resources, divided over 2 groups
| 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