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>
Command | Erklärung | kubectl get rolebinding,clusterrolebinding -A | Alle Role Bindings und Cluster Role Bindings aus allen Namespaces auflisten. | kubectl describe clusterrolebinding <cluster-admin> | Listet auf, welche User, Gruppen oder Serviceaccounts (Subjects) mit dem Cluster Role Binding “cluster-admin” verknüpft sind. |
---|