Привет, Хаброжители! Положитесь на опыт профессионалов, успешно применяющих и развивающих проект Kubernetes. Инженеры Microsoft предлагают лучшие приёмы оркестрации контейнеров. Их практики сложились в процессе разработки распределённых систем, на ответственных и нагруженных проектах. Вам останется лишь слегка адаптировать код. Книга идеально подойдет тем, кто уже знаком с Kubernetes, но ещё не умеет использовать его максимально эффективно. Вы узнаете всё, что необходимо для создания классного Kubernetes-приложения, в том числе: — Подготовка окружения и разработка приложений в Kubernetes. — Паттерны мониторинга и защиты ваших систем, управления обновлениями. — Сетевые политики Kubernetes и роли сервисных сетей в экосистеме. — Использование Kubernetes в задачах машинного обучения.

RBAC

При работе в крупных, распределенных средах очень часто требуется некий механизм безопасности, предотвращающий несанкционированный доступ к ключевым системам. Существует множество стратегий по ограничению доступа к ресурсам в вычислительных системах, но большинство из них состоят из одних и тех же этапов. Чтобы объяснить более наглядно процесс, происходящий в таких системах, как Kubernetes, воспользуемся жизненной аналогией: полетом за рубеж. Мы будем применять знакомые любому путешественнику понятия например паспорт, туристическая виза и таможенный или пограничный контроль.

1. Паспорт (аутентификация субъекта). Обычно для подтверждения личности пассажиру нужен паспорт, выданный неким правительственным органом. Это эквивалент учетной записи пользователя в Kubernetes. Для аутентификации пользователей Kubernetes применяет внешние системы сертификации, хотя управление служебными учетными записями происходит напрямую.

2. Виза, или режим пересечения границы (авторизация). Краткосрочное пребывание в стране гражданина с иностранным паспортом регламентируется официальным соглашением между странами (визой). Визы бывают разных типов и определяют, что приезжему гражданину позволено делать и как долго он может находиться в этой стране. Это эквивалент авторизации в Kubernetes. Платформа поддерживает разные методы авто­ризации, но самый распространенный из них — RBAC. Он позволяет гибко управлять доступом к разным возможностям API.

3. Таможенный или пограничный контроль (контроль доступа). При въезде в чужую страну обычно приходится иметь дело с неким органом власти, представители которого проверяют документы, включая паспорт и визу. Кроме того, ввозимый багаж очень часто проверяется на соответствие законам данной страны. Это эквивалент контроллеров доступа в Kubernetes. Они могут принимать, отклонять и изменять запросы к API в зависимости от заданных правил и политик. Kubernetes предоставляет много встроенных контроллеров доступа, включая PodSecurity, ResourceQuota и ServiceAccount, и поддерживает динамический контроль доступа с помощью проверяющих (validating) и изменяющих (mutating) контроллеров (admission controllers).

Этот раздел посвящен наименее понятной и наиболее игнорируемой из перечисленных выше областей: RBAC. Прежде чем переходить к рекомендациям, следует познакомиться с основными понятиями данной системы.

Основные концепции RBAC

Процесс RBAC в Kubernetes состоит из трех главных компонентов, которые необходимо определить: субъекта, правила и привязки ролей.

Субъекты

Первый компонент — субъект — это то, что проверяется на возможность доступа. В качестве субъекта обычно выступает пользователь, служебная учетная запись или группа. Как уже упоминалось ранее, работа с пользователями, равно как и с группами, происходит за пределами Kubernetes, в одном из модулей авторизации. Эти модули поддерживают базовую HTTP-аутентификацию, клиентские сертификаты x.509 и токены (bearer tokens). Чаще всего применяются либо клиентские сертификаты x.509, либо некая разновидность токенов с использованием какой-нибудь системы OpenID Connect наподобие Azure Active Directory (Azure AD), Salesforce или Google.

Служебные учетные записи отличаются от пользовательских тем, что привязываются к пространствам имен, хранятся внутри Kubernetes и управляются стандартными контроллерами; они предназначены для доступа процессам, а не людям.

Правила

Говоря простым языком, это фактический список действий, которые можно выполнять с определенным объектом (ресурсом) или группой объектов в API. Действия соответствуют стандартным операциям CRUD (Create, Read, Update, Delete — «создать, прочитать, обновить, удалить»), но с некоторыми дополнительными возможностями, характерными для Kubernetes: watch, list и exec. Объекты соответствуют разным API-компонентам и группируются по категориям. Pod-объекты, к примеру, являются частью основного API, и на них можно ссылаться с помощью поля apiGroup:""; в то же время объекты Deployment принадлежат к API-группам apps. Это самая сильная сторона процесса RBAC, которая, вероятно, отпугивает и запутывает пользователей, пытающихся налаживать контроль доступа.

Роли

Роли позволяют определить область действия заданных правил. Kubernetes поддерживает два вида ролей: role и clusterRole; разница в том, что role относится к отдельному пространству имен, тогда как clusterRole действует на уровне целого кластера, во всех пространствах сразу. Ниже показан пример определения роли, ограниченной одним пространством имен:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: default
 name: pod-viewer
rules:
- apiGroups: [""] # "" указывает на основную API-группу
 resources: ["pods"]
 verbs: ["get", "watch", "list"]

RoleBinding

RoleBinding позволяет привязывать субъекты, такие как пользователи или группы, к ролям. Привязка имеет два режима: roleBinding, который относится к отдельному пространству имен, и clusterRoleBinding, действующий на уровне всего кластера. Ниже представлен пример RoleBinding для пространства имен:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: noc-helpdesk-view
 namespace: default
subjects:
- kind: User
 name: helpdeskuser@example.com
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role # здесь может быть только Role или ClusterRole
 name: pod-viewer # должно совпадать с именем роли (Role или ClusterRole), 
 # к которой мы привязываемся
 apiGroup: rbac.authorization.k8s.io

Рекомендации по работе с RBAC

RBAC — ключевой компонент в обеспечении безопасности, надежности и стабильности среды Kubernetes. Концепции, на которых основана эта система, могут показаться сложными, но часть основных трудностей можно преодолеть с помощью нескольких рекомендуемых методик.

— Приложения, разрабатываемые для работы в Kubernetes, редко нуждаются в ролях и привязках RBAC. Исключение составляют случаи, когда код приложения взаимодействует непосредственно с API Kubernetes.

— Если приложению в самом деле необходим прямой доступ к API Kuberne­tes (например, чтобы изменять конфигурацию в зависимости от того, какие конечные точки (endpoints) добавляются в сервис (Service)) или список всех pod в заданном пространстве имен, то лучше всего создать еще одну служебную учетную запись и указать ее в спецификации pod. Затем следует создать роль с минимальным набором привилегий, достаточным для выполнения поставленных перед ней задач.

— Используйте сервис OpenID Connect, поддерживающий идентификацию и при необходимости двухфакторную аутентификацию. Привязывайте группы пользователей к ролям с минимальным набором привилегий, достаточным для выполнения работы.

— Помимо упомянутых выше методик, следует также использовать системы доступа JIT (just in time — «со строгим ограничением по времени»), чтобы в систему могли войти инженеры по мониторингу (site reliability engineers, SRE), операторы и те, кому может понадобиться краткосрочное повышение привилегий в целях выполнения определенных задач. В качестве альтернативы для них можно выделять отдельные учетные записи с более строгим контролем и повышенными привилегиями, которые выдаются в виде роли, назначаемой пользователям или группе пользователей.

— Определенные служебные учетные записи должны использоваться для инструментов CI/CD, которые развертывают ваши кластеры Kubernetes. Это обеспечивает аудитоспособность в рамках кластера и позволяет понять, кто ответственен за развертывание или удаление каких-либо объектов.

— Если вы развертываете приложения с помощью Helm, то стандартная служебная учетная запись, Tiller, развертывается в kube-system. Вместо этого Tiller лучше развернуть в каждом пространстве имен, используя специально созданную служебную учетную запись, ограниченную этим конкретным пространством. В инструменте CI/CD, который на подготовительном этапе вызывает команду Helm install/upgrade, инициализируйте клиент Helm с помощью служебной учетной записи и пространства имен, предназначенного для развертывания. Имя данной записи может быть одним и тем же для каждого пространства, но пространство для развертывания следует указать отдельно. Необходимо упомянуть, что на момент выхода этой книги Helm версии 3 находится в состоянии alpha и одной из его ключевых особенностей является то, что присутствие Tiller в кластере больше не требуется. Ниже показан пример процедуры инициа­лизации Helm с помощью служебной учетной записи (ServiceAccount) и пространства имен:

kubectl create namespace myapp-prod
 
kubectl create serviceaccount tiller --namespace myapp-prod
 
cat <<EOF | kubectl apply -f -
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: tiller
 namespace: myapp-prod
rules:
- apiGroups: ["", "batch", "extensions", "apps"]
 resources: ["*"]
 verbs: ["*"]
EOF
 
cat <<EOF | kubectl apply -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: tiller-binding
 namespace: myapp-prod
subjects:
- kind: ServiceAccount
 name: tiller
 namespace: myapp-prod
roleRef:
 kind: Role
 name: tiller
 apiGroup: rbac.authorization.k8s.io
 EOF
 
helm init --service-account=tiller --tiller-namespace=myapp-prod
 
helm install ./myChart --name myApp --namespace myapp-prod 
--set global.namespace=myapp-prod

Отдельные публичные Helm-чарты не содержат поля для выбора пространства имен, в котором следует развертывать компонент приложения. Вследствие этого может потребоваться ручное редактирование чарта или использование учетной записи Tiller с повышенными привилегиями, чтобы получить права на развертывание в любом пространстве имен, а также на создание новых пространств.

— Ограничивайте доступ для любых приложений, которым нужно выполнять действия watch и list с API Secrets. Эти действия, в сущности, позволяют приложению или человеку, развернувшему pod, просматривать секретные данные в соответствующем пространстве имен. Если приложение использует этот API для доступа к конкретным объектам Secret, то позвольте ему выполнять действие get только для этих объектов (в дополнение к секретным данным, которые назначены ему напрямую).

Об авторах

Брендан Бернс — известный инженер Microsoft Azure и соучредитель открытого проекта Kubernetes. Занимается созданием облачных приложений уже больше десяти лет.

Эдди Вильяльба работает программистом в отделе разработки коммерческого ПО компании Microsoft, занимаясь развитием открытых облачных технологий и Kubernetes. Многие пользователи могут быть благодарны за его помощь с внедрением Kubernetes в их приложения.

Дейв Штребель работает архитектором глобальных облачных систем в Microsoft Azure и занимается открытыми облачными технологиями и Kubernetes. Он принимает активное участие в открытом проекте Kubernetes, помогая с релизами новых версий и возглавляя группу SIG-Azure.

Лахлан Эвенсон — руководитель команды контейнерных вычислений в Microsoft Azure. Его практические уроки и выступления на конференциях помогли огромному количеству людей перейти на Kubernetes.

Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Kubernetes

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.