its a really important part of a kub cluster with this you can config the right of a user with the kube api
like
admin -> create delete everything
dev -> create in a specific namespace
bot -> readonly
we already discuss about that in the Authentication section
Node have acces to the Kube API and they need they acces to the API by kubelet
for read Services endpoint node pods
and Write Node status pod status events
this is call the Node Authorization
is for attribute to a user or a set of user a group of permissions
you can create ABAC like that
{"kind": "Policy", "spec": {"user": “dev-user-2", "namespace": "*", "resource": “pods", "apiGroup": "*"}}
{"kind": "Policy", "spec": {“group": “dev-users", "namespace": "*", "resource": “pods", "apiGroup": "*"}}
{"kind": "Policy", "spec": {"user": “security-1", "namespace": "*", "resource": “csr", "apiGroup": "*"}}
you need to restart the kube api server after an update
RBAC is the future of permission you not create some perm for a user or a group you create
a role like dev admin reviwers and you give this role to everyone of the specify teams so you
its like a jobs file for each job that need to acces to the cluster
its became mor easy to update the permission of a jobs
like eveytime you create a YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list“, "get", “create“, “update“, “delete"]
ressourcesNames: ["red","green"] # its for restrict acces by ressource name the name of a pods for
# the ressource name work for all ressources like node challenge etc etc
- apiGroups:
- apps
resources:
- deployments
verbs:
- get
- list
- watch
- create
- update
- delete
- apiGroups: [""]
resources: [“ConfigMap"]
verbs: [“create“]
kubectl apply -f /path/to/yaml
here a table for api groups
| Ressource | apiGroup |
|---|---|
| pods | "" (core) |
| services | "" (core) |
| secrets | "" (core) |
| deployments | apps |
| replicasets | apps |
| statefulsets | apps |
| roles | rbac.authorization.k8s.io |
| ingresses | networking.k8s.io |
next we create a role binding to aply a role to a list of user
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: devuser-developer-binding
subjects:
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io
kubectl apply -f /path/to/yaml
kubectl get roles
kubectl get roles -n namespace # a RBAC can alse be only for a namespace
kubectl get rolebinding
kubectl get rolebinding -n namespace
kubectl describe role rolename
kubectl describe rolebinding rolebinfingName
kubectl auth can-i create deployments
kubectl auth can-i delete nodes
kubectl auth can-i create deployments --as dev-user
kubectl auth can-i create pods --as dev-user
kubectl auth can-i create pods --as dev-user --namespace test
you can see all argument of the api here
webhook use a open policy agent for exeternal request
you config this in the kube-apiserver file
Here you can see that my cluster of 2 mode enable Node and RBAC
cat /etc/kubernetes/manifests/kube-apiserver.yaml
[...]
spec:
containers:
- command:
- kube-apiserver
- --advertise-address=192.168.1.201
- --allow-privileged=true
- --authorization-mode=Node,RBAC
[...]
the request follow the order of the list you give so here first it try with node after RBAC and DENY