Werte in spitzen Klammern <..> sind zu ersetzen.

Es wird ein User erstellt, der bestimmte Berechtigungen für einen einzelnen Namespace bekommt, um Pods aufzulisten, zu starten, auszuführen und zu beenden. Um Berechtigungen für den gesamten Cluster zu erstellen, müssen alternativ Cluster Roles und Cluster Role Bindings verwendet werden.

openssl genrsa -out <johndoe>.key 2048

Es wir der Common Name ("CN") gesetzt, mit dem der User im Cluster identifiziert werden soll. Weiters wird eine Gruppe "Developers" gesetzt. Diese kann z.B. später verwendet werden, um Role Bindings zu ganzen Gruppen zuzuweisen.

openssl req -new -key <johndoe>.key -out <johndoe>.csr -subj "/CN=<John Doe>/O=<Developers>"

''ca.crt'' und ''ca.key'' von einem Control Plane Cluster Node auslesen (befindet sich in: ''/etc/kubernetes/pki/'')

CSR signen, cert erstellen und Laufzeit angeben

openssl x509 -req -in <johndoe>.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out <johndoe>.crt -days 1

Base64 CSR data: cat <johndoe>.csr | base64 | tr -d "\n"

kubectl apply -f csr.yml csr.yml

kubectl get csr kubectl certificate approve <johndoe>

kubectl get csr <johndoe> -o jsonpath='{.status.certificate}'| base64 -d

Eine Role namens “manage-pods” wird erstellt und diese in den gewünschten Namespace deployed.
kubectl -n <mynamespace> apply -f role.yml role.yaml
Alternativ:
kubectl --namespace=<mynamespace> create role <manage-pods> --verb=get,watch,list,create,delete --resource=pods,pods/exec
Mehr Infos:
https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb & kubectl api-resources --sort-by name -o wide

Das Role Binding definiert, welche Role (“manage-pods”) mit welchem User Zertifikat (Common Name “John Doe” muss übereinstimmen) verknüpft wird. Roles können natürlich auch mit Gruppen verknüpft werden und müssen nicht direkt an einen User gebunden sein.
kubectl -n <mynamespace> apply -f role-binding.yml role-binding.yaml
Alternativ:
kubectl --namespace=<mynamespace> create rolebinding <manage-pods> --role=<manage-pods> --user="<John Doe>"

Es gibt spezielle, vordefinierte Roles die entweder Cluster-weit (mittels Cluster Role Binding) oder in einem Namespace angewandt werden können: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles

Für Applikationen, die selbst auf die Kubernetes API zugreifen müssen.

kubectl -n <mynamespace> apply -f serviceaccount.yaml serviceaccount.yaml
Alternativ:
kubectl --namespace=<mynamespace> create serviceaccount <my-app>

kubectl --namespace=<mynamespace> auth can-i --as=system:serviceaccount:<mynamespace>:<my-app> list pods

export KUBECONFIG=~/.kube/<my-new-config>

kubectl config set-cluster <my-cluster-name> --server=https://<cluster-api-ip>:<cluster-api-port> --certificate-authority=ca.crt --embed-certs=true

kubectl config set-credentials <johndoe> --client-certificate=<johndoe>.crt --client-key=<johndoe>.key --embed-certs=true

kubectl config set-context <my-context> --cluster=<my-cluster-name> --namespace=<mynamespace> --user=<johndoe>

kubextl config use-context <my-context>