centos7, docker, docker swarm, kubernetes

Kubernetes - Как контролировать пользователей

Thank you for reading this post, don't forget to subscribe!

Созда­ние изо­ли­ро­ван­ной сре­ды поль­зо­ва­те­ля Kubernetes в Docker Enterprise

Как кон­тро­ли­ро­вать пользователей

Управ­лять кла­сте­ром Kubernetes с одним поль­зо­ва­те­лем просто.

Когда вы выхо­ди­те за пре­де­лы одно­го поль­зо­ва­те­ля, вам нуж­но начать исполь­зо­вать управ­ле­ние досту­пом на осно­ве ролей (RBAC).

рас­смот­рим для начала:

Создание изолированной среды пользователя Kubernetes в Docker Enterprise

Когда вы созда­е­те поль­зо­ва­те­ля в Docker Enterprise Edition (EE), этот поль­зо­ва­тель может немед­лен­но создать служ­бу Swarm в кластере.

Все, что ему нуж­но сде­лать, это сге­не­ри­ро­вать, загру­зить, рас­па­ко­вать и «выпол­нить» их кли­ент­ский пакет.

Одна­ко на сто­роне Kubernetes управ­ле­ние досту­пом на осно­ве ролей (RBAC) и поль­зо­ва­тель­ские раз­ре­ше­ния по умол­ча­нию немно­го отличаются.

Я пока­жу вам, как настро­ить подоб­ный опыт с Kubernetes, кото­рый вы полу­ча­е­те с гото­вым Swarm.

Docker EE созда­ет кли­ент­ский пакет, кото­рый содер­жит сер­ти­фи­ка­ты, пере­мен­ные сре­ды и т. д., необ­хо­ди­мые для настрой­ки систе­мы для вза­и­мо­дей­ствия с кла­сте­ром с помо­щью команд docker и kubectl.

В систе­ме Windows 10 вы исполь­зу­е­те при­ве­ден­ную ниже коман­ду в окне PowerShell.

В систе­ме Linux вы долж­ны исполь­зо­вать env.sh в команд­ной стро­ке Bash.

ken> Import-Module .\env.ps1
Cluster "ucp_ken-ucp.lab.capstonec.net:6443_ken.rider" set.
User "ucp_ken-ucp.lab.capstonec.net:6443_ken.rider" set.
Context "ucp_ken-ucp.lab.capstonec.net:6443_ken.rider" modified.

Это уста­нав­ли­ва­ет локаль­ную сре­ду для свя­зи с уда­лен­ным кла­сте­ром Docker EE.
Когда поль­зо­ва­те­ли затем выпол­ня­ют коман­ду docker service create, систе­ма созда­ет служ­бу в кла­сте­ре с помо­щью оркест­ра­то­ра Swarm.
ken> docker service create --name nginx nginx:1.14-alpine
zaslrujj7y0rrp53b1ds9q7as
overall progress: 1 out of 1 tasks
1/1: running [==================================================>] verify: Service converged
В Docker EE 2.0 и, теперь, 2.1, Kubernetes так­же под­дер­жи­ва­ет­ся как оркест­ра­тор для кластера.
Одна­ко, если этот же поль­зо­ва­тель пыта­ет­ся создать ана­ло­гич­ную служ­бу с исполь­зо­ва­ни­ем Kubernetes, он тер­пит неудачу.
ken> kubectl create deployment nginx --image=nginx:1.14-alpine
Error from server (Forbidden):
deployments.extensions is forbidden: User
"8f796584-5683-4c24-baf8-554ad21ad86f" cannot create
deployments.extensions in the namespace "default": access denied
В слу­чае Swarm, когда Docker EE созда­ет поль­зо­ва­те­ля, он уста­нав­ли­ва­ет кол­лек­цию /Shared/Private/ken.rider и два гранта.
Пер­вый грант, ken.rider> Restricted Control> /Shared/Private/ken.rider, дает поль­зо­ва­те­лю огра­ни­чен­ный кон­троль над его част­ной коллекцией.
Вто­рой грант, ken.rider> Scheduler> / Shared, дает поль­зо­ва­те­лю воз­мож­ность пла­ни­ро­вать рабо­ту на рабо­чих узлах в кластере.

Когда поль­зо­ва­тель созда­ет сер­вис, он раз­вер­ты­ва­ет­ся в этой коллекции.

В слу­чае с Kubernetes Docker EE под­дер­жи­ва­ет RBAC Kubernetes, но не настра­и­ва­ет про­стран­ства имен, роли или при­вяз­ки ролей для пользователя.

Про­ще гово­ря, про­стран­ства имен поз­во­ля­ют нам раз­де­лять объ­ек­ты в кла­сте­ре Kubernetes; роли опре­де­ля­ют, что поль­зо­ва­тель или груп­па могут делать с объ­ек­та­ми; а при­вяз­ки ролей свя­зы­ва­ют поль­зо­ва­те­лей и груп­пы с роля­ми в про­стран­стве имен. (Более пол­ное обсуж­де­ние RBAC в Kubernetes см. В раз­де­ле Исполь­зо­ва­ние авто­ри­за­ции RBAC в спра­воч­ной доку­мен­та­ции по Kubernetes.)

Что­бы (в неко­то­рой сте­пе­ни) вос­про­из­ве­сти дей­ствия Docker EE для поль­зо­ва­те­лей Swarm для поль­зо­ва­те­лей Kubernetes, нам необ­хо­ди­мо опре­де­лить соот­вет­ству­ю­щее про­стран­ство имен, роль и свя­зы­ва­ние ролей для них.

Сле­ду­ю­щий мани­фест Kubernetes будет при­ме­нять эти настрой­ки для поль­зо­ва­те­ля ken.rider.
Если вы созда­ди­те файл с выше­ука­зан­ным содер­жи­мым, напри­мер user-ken.rider.yml, и при­ме­ни­те его с помо­щью кли­ент­ско­го паке­та адми­ни­стра­то­ра, вы уви­ди­те следующее.
admin> kubectl apply -f .\user-ken.rider.yml
namespace "user-kenrider" created
role.rbac.authorization.k8s.io "user-kenrider-full-access" created
rolebinding.rbac.authorization.k8s.io "ken.rider:user-kenrider-full-access" created
При­ме­ча­ние: вы заме­ти­те, что имя поль­зо­ва­те­ля – ken.rider, а про­стран­ство имен – user-kenrider (без точки).
Kubernetes очень огра­ни­чен в отно­ше­нии сим­во­лов, раз­ре­шен­ных в име­нах про­стран­ства имен.
Для про­вер­ки исполь­зу­ет­ся регу­ляр­ное выра­же­ние: «[a-z0-9] ([- a-z0-9] * [a-z0-9])?».
Вы уви­ди­те, что в этом выра­же­нии отсут­ству­ет несколь­ко сим­во­лов, кото­рые могут быть про­бле­ма­тич­ны­ми в вашем сценарии.
В част­но­сти, мно­гие орга­ни­за­ции исполь­зу­ют точ­ку «‘ »или под­чер­ки­ва­ние« _ »в име­нах пользователей.
Они так­же могут исполь­зо­вать заглав­ные бук­вы в сво­их име­нах пользователей.
Нако­нец, если вы исполь­зу­е­те встро­ен­ную аутен­ти­фи­ка­цию LDAP, Active Directory или OAuth, весь­ма веро­ят­но, что имя участ­ни­ка-поль­зо­ва­те­ля (UPN) будет исполь­зо­вать­ся в каче­стве име­ни поль­зо­ва­те­ля Docker EE, и в боль­шин­стве слу­ча­ев это будет адрес элек­трон­ной почты поль­зо­ва­те­ля, кото­рый содер­жит знак «@».
Теперь, когда поль­зо­ва­тель опре­де­ля­ет про­стран­ство имен, кото­рое мы созда­ли, он может раз­во­ра­чи­вать свои служ­бы.
ken> kubectl --namespace user-kenrider create deployment nginx --image=nginx:1.14-alpine
deployment.extensions "nginx" created
В этом руко­вод­стве, мы созда­ли песоч­ни­цу Kubernetes для поль­зо­ва­те­ля.
Вы може­те исполь­зо­вать при­ве­ден­ный выше при­мер для созда­ния сво­е­го соб­ствен­но­го шаб­ло­на мани­фе­ста и скрип­та для созда­ния изо­ли­ро­ван­ной про­грамм­ной сре­ды для каж­до­го поль­зо­ва­те­ля, кото­ро­го вы созда­е­те в кла­сте­ре Docker EE.

Как контролировать пользователей Kubernetes

Но как толь­ко вы вый­де­те за пре­де­лы пары поль­зо­ва­те­лей и / или команд и несколь­ких про­странств имен для них, вам быст­ро ста­нет труд­но отсле­дить, кто может что делать и где.

И со вре­ме­нем, и все боль­ше и боль­ше людей при­ни­ма­ют уча­стие в настрой­ке ваше­го RBAC, это может стать еще более запутанным.

Вы долж­ны иметь свои опре­де­ле­ния ресур­сов RBAC в управ­ле­нии исход­ным кодом, но их нелег­ко про­чи­тать и слож­но визуализировать.

Поро­буй­те пла­гин с откры­тым исход­ным кодом who-can kubectl от Aqua Security.

Он дает вам воз­мож­ность пока­зать, кто (субъ­ек­ты) может делать, что (дей­ствия), c чем (ресур­сы) и где (про­стран­ства имен).

Установите менеджер плагинов Krew

Для пла­ги­на who-can для kubectl тре­бу­ет­ся мене­джер пла­ги­нов krew.

Если у вас еще не уста­нов­лен krew, инструк­ции по его уста­нов­ке мож­но най­ти в его репо­зи­то­рии GitHub, https://github.com/kubernetes-sigs/krew/.

Что­бы убе­дить­ся, что он уста­нов­лен пра­виль­но, вы може­те полу­чить спи­сок доступ­ных пла­ги­нов от kubectl.

$ kubectl plugin list
The following kubectl-compatible plugins are available:

/home/ken.rider/.krew/bin/kubectl-krew

Установите плагин Who-Can

Если у вас есть мене­джер пла­ги­нов krew для kubectl, уста­но­вить пла­гин who-can доволь­но легко.

Настройка RBAC для нашего кластера

У меня есть кла­стер Kubernetes, кото­рый я собрал в Azure с помо­щью Docker Enterprise.

Суще­ству­ет 3 (не по умол­ча­нию) про­стран­ства имен для раз­ра­бот­ки, тести­ро­ва­ния и производства.

У меня так­же есть коман­ды для раз­ра­бот­ки, тести­ро­ва­ния, экс­плу­а­та­ции и без­опас­но­сти, кото­рые я создал как адми­ни­стра­тор кластера.

Я опре­де­лил набор RoleBindings для каж­до­го из них.

Использование who-can

После того, как вы уста­но­ви­ли who-can, вы уви­ди­те, что его исполь­зо­ва­ние будет очень простым.

Типич­ный набор дей­ствий, кото­рые могут вас заин­те­ре­со­вать, это getlistwatchcreateupdatepatchdelete.

Есть еще несколь­ко дру­гих дей­ствий для опре­де­лен­ных типов ресур­сов, но, как пра­ви­ло, вы буде­те наи­бо­лее заин­те­ре­со­ва­ны в getcreatedelete.

Типич­ный набор типов ресур­сов, кото­рые могут вас заин­те­ре­со­вать, вклю­ча­ют podsdeploymentsservicespersistentvolumeclaimsconfigmapssecrets

Кро­ме того, с посто­ян­но рас­ши­ря­ю­щим­ся исполь­зо­ва­ни­ем CustomResourceDefinitions, спи­сок типов ресур­сов не явля­ет­ся бесконечным.

Пример использование Who-Can

Давай­те сна­ча­ла спро­сим: «Кто может уви­деть поды в про­стран­стве имен development?»

Теперь давай­те спро­сим: «Кто может созда­вать поды в про­стран­стве имен development?».

Здесь мы уви­дим, что толь­ко наши груп­пы development и operations могут созда­вать там поды.

И спи­сок учет­ных запи­сей систем­ных служб короче:

Затем мы спро­сим «кто может обно­вить что-либо в про­стран­стве имен development?»

Нако­нец, «кто может уда­лять сер­ви­сы в про­стран­стве имен productions?».
И мы видим, что толь­ко груп­па operations может это.