☸️ Создание изолированной среды пользователя Kubernetes в Docker Enterprise — Information Security Squad
☸️ Создание изолированной среды пользователя 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.
kind: Namespace
apiVersion: v1
metadata:
  name: user-kenrider
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user-kenrider-full-access
  namespace: user-kenrider
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  labels:
    subjectName: ken.rider
  name: ken.rider:user-kenrider-full-access
  namespace: user-kenrider
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: user-kenrider-full-access
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: 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.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *