Как уже упо­ми­на­лось ранее, в Kubernetes нет объ­ек­тов API для управ­ле­ния учет­ны­ми запи­ся­ми поль­зо­ва­те­лей. Из доступ­ных спо­со­бов управ­ле­ния аутен­ти­фи­ка­ци­ей (см. офи­ци­аль­ную доку­мен­та­цию Kubernetes) для про­сто­ты мы будем исполь­зо­вать сер­ти­фи­ка­ты OpenSSL. Необ­хо­ди­мые шаги:

• Создай­те закры­тый ключ для сво­е­го поль­зо­ва­те­ля. В этом при­ме­ре мы назо­вем файл user1.key[root@kub-master-1 ~]# openssl genrsa -out user1.key 2048
• Создай­те запрос сер­ти­фи­ка­та user1.csr, исполь­зуя толь­ко что создан­ный вами закры­тый ключ (user1.key). Убе­ди­тесь, что вы ука­за­ли свое имя поль­зо­ва­те­ля и груп­пу в раз­де­ле -subj(CN для име­ни поль­зо­ва­те­ля и O для груп­пы). Как упо­ми­на­лось ранее, мы будем исполь­зо­вать имя user1 и deparment1 в каче­стве группы:

[root@kub-master-1 ~]# openssl req -new -key user1.key -out user1.csr -subj "/CN=user1/O=deparment1"

• Най­ди­те свой центр сер­ти­фи­ка­ции кла­сте­ра Kubernetes (CA). Он будет отве­чать за утвер­жде­ние запро­са и полу­че­ние необ­хо­ди­мо­го сер­ти­фи­ка­та для досту­па к API кла­сте­ра. Обыч­но он рас­по­ла­га­ет­ся в дирек­то­рии /etc/kubernetes/pki/. В слу­чае Minikube это будет ~/.minikube/. Убе­ди­тесь, что фай­лы ca.crt и ca.key суще­ству­ют в соот­вет­ству­ю­щей директории.

• Создай­те сер­ти­фи­кат user1.crt, одоб­рив запрос на под­пись сер­ти­фи­ка­та, user1.csr, сде­лан­ный ранее. Убе­ди­тесь, что вы заме­ни­ли CA_LOCATION в при­ме­ре коман­ды ниже на место­по­ло­же­ние ваше­го акту­аль­но­го CA кла­сте­ра. Сер­ти­фи­кат будет дей­стви­те­лен в тече­ние 500 дней:

$ openssl x509 -req -in user1.csr -CA CA_LOCATION/ca.crt -CAkey CA_LOCATION/ca.key -CAcreateserial -out user1.crt -days 500

в моём слу­чае это команда:

[root@kub-master-1 ~]# openssl x509 -req -in user1.csr -CA /etc/kubernetes/pki/ca.pem -CAkey /etc/kubernetes/pki/ca-key.pem -CAcreateserial -out user1.crt -days 500
и её вывод:

• Сохра­ни­те как user1.crt, так и user1.key где-нибудь в без­опас­ном месте (напри­мер, в дирек­то­рии ~/.kube/certs/):
  $ mkdir ~/.kube/certs
$ cp user1.crt ~/.kube/certs
$ cp user1.key ~/.kube/certs

• добавь­те новый кон­текст с новы­ми учет­ны­ми дан­ны­ми для ваше­го кла­сте­ра Kubernetes.
  [root@kub-master-1 ~]# kubectl config set-credentials user1 --client-certificate=$HOME/.kube/certs/user1.crt --client-key=$HOME/.kube/certs/user1.keyСмотрим имя кластера:
  [root@kub-master-1 ~]# kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
  
  YAML

  Cluster name Server cluster.local https://192.168.1.201:6443

  1 2	Cluster name    Server cluster.local   https://192.168.1.201:6443

  
  [root@kub-master-1 ~]# kubectl config set-context user1-context --cluster=cluster.local --namespace=office --user=user1

доба­вим теперь поль­зо­ва­те­ля  под кото­рым будем работать:

[root@kub-master-1 ~]# adduser test
[root@kub-master-1 ~]# mkdir -p /home/test/.kube/certs
[root@kub-master-1 ~]# cp /root/.kube/certs/user1.* /home/test/.kube/certs/

смот­рим файл:
[root@kub-master-1 ~]# cat /root/.kube/config

нас инте­ре­су­ет:

certificate-authority-data
и
server

и созда­ём файл сле­ду­ю­ще­го вида:

[root@kub-master-1 ~]# cat /home/test/.kube/config

не забы­ва­ем ука­зать certificate-authority-data и server

Теперь при попыт­ке исполь­зо­вать kubectl с этим кон­фи­гу­ра­ци­он­ным фай­лом мы будем полу­чать отказ в досту­пе. Это ожи­да­е­мое пове­де­ние, посколь­ку мы не опре­де­ли­ли ника­ких раз­ре­шен­ных опе­ра­ций для толь­ко что создан­но­го поль­зо­ва­те­ля. Убе­ди­тесь в этом сами:

[test@kub-master-1 ~]$ kubectl get pod -n my-site
The connection to the server localhost:8080 was refused - did you specify the right host or port?
дан­ная ошиб­ка логич­на пото­му что мы не ука­за­ли context

[test@kub-master-1 ~]$ kubectl --context=user1-context get pods -n my-site
Error from server (Forbidden): pods is forbidden: User "user1" cannot list resource "pods" in API group "" in the namespace "my-site"

Теперь вы може­те выпол­нять сле­ду­ю­щие коман­ды без каких-либо проблем:

[test@kub-master-1 ~]$ kubectl --context=user1-context get pods -n office
No resources found in office namespace.

запу­стим тесто­вое при­ло­же­ние и про­ве­рим что нам доступ­но из под наше­го пользователя:

[test@kub-master-1 ~]$ kubectl --context=user1-context get all -n office

как видим нам доступ­ны толь­ко сле­ду­ю­щие сущности:
deployments  replicasets   pods

как рас их мы и пере­чис­ли­ли в кон­фи­ге  role-deployment-manager.yaml  для наше­го namespace office

про­ве­рим удаление:

как видим всё ок.