Глава 4. Применение принципа наименьших прав в Kubernetes

Привилегия - это право (authority) выполнять такое действие как доступ к некому ресурсу или обработка каких- то данных. Принцип наименьших полномочий состоит той идее, что всякий субъект, пользователь, программа, процесс и тому подобное должны обладать лишь минимумом необходимых полномочий для выполнения такой функции. Скажем, Алиса, обычные пользователь Linux, имеет возможность создать некий файл в своём домашнем каталоге. Иначе говоря, Алиса, по крайней мере, обладает полномочиями на создание файлов в её домашнем каталоге. Тем не менее, Алиса может быть не способной создавать файл в каталоге иного пользователя, ибо она не обладает привилегией или полномочиями на выполнение этого. Когда никакая повседневная задача Алисы действительно не пользуется привилегией создания файла в таком домашнем каталоге, но она обладает такими полномочиями, это означает что администратор данной машины не соблюдает принцип наименьших полномочий. В данном разделе мы сначала введём понятие модели авторизации (получения прав доступа), на основе которой и появилась концепция наименьших привилегий, а затем поговорим об основных преимуществах реализации такого понятия наименьших прав.

Когда мы говорим о наименьших привилегиях, в большинстве случаев мы ведём разговор в контексте авторизации и в различных средах будут различные модели получения прав доступа (авторизации). Например, в Linux и межсетевых экранах широко применяются ACL (Access Control List , Списки управления доступом), в то время как в системах баз данных используется RBAC. Определение политик авторизации восходит к соответствующему администратору среды чтобы гарантировать наименьшие права на основании доступной в этой системе модели авторизации. Приводимый ниже перечень даёт определения некоторым распространённым моделям авторизации:

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

Хотя и может потребоваться достаточно значительное время чтобы осознать чем являются минимальные привилегии для субъекта при осуществлении своих функций, собственно вознаграждения также важны,когда в вашей среде реализован принцип наименьших полномочий:

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

Учётные записи служб, пользователи и группы Kubernetes для управления объектами взаимодействуют с kube-apiserver. При включённом RBAC различные пользователи или учётные записи служб могут обладать различными полномочиями для работы с объектами Kubernetes. К примеру, пользователи из группы system:master обладают предоставленной им ролью cluster-admin, что означает, что они способны управлять всем кластером Kubernetes целиком, в то время как пользователи из группы system:kube-proxy могут выполнять доступ только к тем ресурсам, которые необходимы компоненту kube-proxy. Прежде всего, давайте вкратце обсудим что представляет собой RBAC.

Как уже обсуждалось ранее, RBAC это модель регулировки доступа к ресурсам на основе ролей предоставления пользователям или группам. Начиная с версии 1.6 и далее RBAC в Kubernetes включён по умолчанию. Вплоть до версии 1.6 RBAC можно было включать запуская сервер API (Application Programming Interface) с флагом --authorization-mode=RBAC. RBAC упрощает динамическую настройку политик полномочий при помощи сервера API.

Центральные элементы RBAC включают в свой состав следующее:

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

Kubernetes поддерживает три типа следующих субъектов:

Администраторы кластера могут создавать новые учётные записи служб, подлежащие ассоциации с подами выполняя такую команду:

$ kubectl create serviceaccount new_account
		

Учётная запись службы new_account будет создана в установленном по умолчанию пространстве имён. Для гарантии наименьших полномочий администраторы кластера должны ассоциировать каждый ресурс Kubernetes с некой учётной записью службы с наименьшими правами для её работы.

Роль является коллекцией полномочий - например, некая роль в пространстве имён A может позволять пользователям создавать поды в пространстве имён A и список секретов в пространстве имён A. В Kubernetes нет запрещающих полномочий. Таким образом, роль выступает дополнительным набором полномочий.

Роль ограничена пространством имён. С другой стороны, ClusterRole работает на уровне кластера. Пользователи могут создавать некую ClasterRole, которая распространяется по всему кластеру целиком. ClusterRole может применяться в качестве посредника доступа к ресурсам, которые разбросаны по кластеру, таким как узлы, проверки жизнеспособности, также объектов пространства имён, например, подов по множеству пространств имён. Вот некий простой пример определения роли:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: role-1
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]
 	   

Это простое правило допускает операции get переполнять ресурсы подов в установленном по умолчании пространстве имён. Эта роль может быть создана при помощи kubectl выполнением такой команды:

$ kubectl apply -f role.yaml
		

Пользователь способен создавать или изменять некую роль только когда истинно одно из следующего:

Это препятствует выполнению атак эскалации полномочий пользователям через изменение ролей и полномочий.

Объект RoleBinding применяется для ассоциации некой роли с субъектами. Аналогично ClusterRole, ClusterRoleBinding способна предоставлять некий набор полномочий субъектам по пространствам имён. Давайте рассмотрим пару примеров:

RoleBinding связывает объект с субъектами и делает возможным повторное применение, а также упрощает управление.

Пространство имён это общее понятие в информатике, которое предоставляет логическое группирование для относящихся к нему ресурсов. Пространства имён применяются во избежание противоречий с именами; ресурсы внутри одного и того же пространства имён должны обладать уникальными именами, однако между пространствами имён ресурсы могут разделять имена. В экосистеме Linux пространства имён делают возможной изоляцию ресурсов систем.

В Kubernetes пространства имён делают возможным логически совместно применять отдельный кластер между командами и проектами. При помощи пространств имён Kubernetes применимо следующее:

По умолчанию, Kubernetes обладает тремя различными пространствами имён. Для их просмотра выполните такую команду:

$ kubectl get namespace
NAME          STATUS    AGE
default       Active    1d
kube-system   Active    1d
kube-public   Active    1d
		

Эти три пространства имён описываются так:

Давайте посмотрим как создавать пространство имён.

 

Создание пространства имён

Некое новое пространство имён в Kubernetes можно создать с помощью такой команды:

$ kubectl create namespace test
		

После того как пространство имён создано, пространству имён могут назначаться объекты с применением свойства namespace следующим образом:

$ kubectl apply --namespace=test -f pod.yaml
		

К объектам внутри определённого пространства имён можно осуществлять доступ при помощи свойства namespace так:

$ kubectl get pods --namespace=test
		

В Kubernetes не все объекты ограничены в пространствах имён. Объекты нижнего уровня, такие как Nodes и persistentVolumes перекрываются по пространствам имён.

На данный момент вы должны быть знакомыми с понятиями ClusterRole/Role, ClusterRoleBinding/RoleBinding, учётными записями служб и пространствами имён. Для реализации наименьших полномочий субъектам Kubernetes, прежде чем вы создаёте в Kubernetes некий объект Role или RoleBinding, вы можете задать себе приводимые ниже вопросы:

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

Обычно будет иметься некая учётная запись службы (default), ассоциируемая с рабочей нагрузкой Kubernetes. Тем самым, процесс внутри пода имеет возможность взаимодействия с kube-apiserver при помощи токена (маркера) этой учётной записи службы. DevOps должны тщательно предоставлять необходимые права такой учётной записи службы исходя из целей наименьших полномочий. Мы уже обсуждали это в своём предыдущем разделе.

Помимо доступа kube-apiserver к работе с объектами Kubernets, процессы в поде способны также получать также доступ к ресурсам в своих узлах исполнителей и прочим подам/ микрослужбам и прочим подам/ микрослужбам в своих кластерах (как это рассматривалось в Главе 2, Построение сетевой среды Kubernetes). В этом разделе мы поговорим относительно реализации наименьших полномочий доступа к системным ресурсам, сетевым ресурсам и ресурсам приложения.

Напомним, что некая запущенная внутри какого- то контейнера микрослужба ничто иное, как процесс в узле исполнителя, изолированный в своём собственном пространстве имён. Некци под или контейнер может осуществлять доступ к ресурсам различных типов в своём узле исполнителя на основании установленной конфигурации. Это контролируется его контекстом безопасности, который может настраиваться как на уровне своего пода, так и на уровне самого контейнера. Настройка контекста безопасности соответствующего пода/ контейнера должна иметься в перечне задач самих разработчиков (при помощи проектирования безопасности и его пересмотра), в то время как политики безопасности - иной способ ограничения доступа пода/ контейнера к ресурсам системы на уровне самого кластера - должны присутствовать в списке задач для выполнения DevOps. Давайте взглянем на основные понятия контекста безопасности, политики безопасности пода и управления ограничениями ресурсов.

 

Контекст безопасности

Некий контекст безопасности предлагает пути задания полномочий и настроек управления доступа для подов и контейнеров с учётом доступа к системным ресурсам. В Kubernetes определённый контекст безопасности на уровне своего пода отличается от контекста на уровне самого контейнера, хотя имеется и ряд перекрывающихся атрибутов, которые могут настраиваться на обоих уровнях. В целом, конкретный контекст безопасности предоставляет такие функциональные возможности, которые вы можете применять для основополагающего принципа наименьших полномочий контейнеров и подов:

Мы дополнительно обсудим контекст безопасности в Главе 8, Безопасность Подов Kubernetes.

 

Политика безопасности пода

Соответствующая PodSecurityPolicy это некий ресурс кластера Kubernetes, который управляет атрибутами спецификации пода, относящимися к безопасности. Она определяет некий набор правил. Когда следует создавать поды в соответствующем кластере Kubernetes, эти поды должны выполнять те правила, которые задаются PodSecurityPolicy или же им будет отказано в старте. PodSecurityPolicy контролирует или применяет следующие атрибуты:

Мы дополнительно обсудим PodSecurityPolicy в Главе 8, Безопасность Подов Kubernetes. В целом контроль PodSecurityPolicy реализуется в виде некого контроллера доступа. Вы также можете создавать свой собственный контроллер доступа для применения своей собственной политики предоставления прав (authorization) собственным рабочим потокам. Другим хорошим претендентом для реализации вашей собственной политики наименьших полномочий является OPA (Open Policy Agent, Агент открытой политики). Мы дополнительно рассмотрим OPA в Главе 7, Аутентификация, авторизация и контроль доступа.

Теперь же давайте взглянем на механизм управления пределами ресурсов в Kubernetes, поскольку вы можете не захотеть чтобы ваши микрослужбы поглощали в системе все имеющиеся ресурсы, такие как Central Processing Unit (CPU) и оперативная память.

 

Контроль ограничения ресурса

По умолчанию некий отдельный контейнер может использовать так много памяти и ресурсов ЦПУ, солько имеется в узле. Некий контейнер с запущенным исполняемым файлов криптомайнинга запросто способен потребить все ресурсы ЦПУ в том узле, который он совместно использует с прочими подами. Всегда достойным практическим примером является установка запросов и пределов ресурсов для рабочих нагрузок. Запрос ресурса оказывает влияние на то какому узлу установленный планировщик будет назначать такие поды. Во избежание отселения или прекращения для вашей рабочей нагрузки всегда безопасно назначать большие запросы и ограничения. Однако имейте в виду, что если вы установите слишком высокий запрос или предел для ресурса, это приведёт к утрате в вашем кластере ресурсов, а выделенные вашей рабочей нагрузке ресурсы могут использоваться не полностью. Мы дополнительно обсудим эту тему в Главе 10, Мониторинг и управление в реальном времени ресурсами кластера Kubernetes.

Когда поды или контейнеры запускаются в привилегированном режиме, в отличии от подов или контейнеров в не привилегированном режиме, они обладают теми же самыми полномочиями, которые имеются у пользователей с правами администратора в неком узле. Когда ваша рабочая нагрузка запускается в привилегированном режиме, в чём именно смысл этого? Когда некий под способен выполнять доступ к пространству имён хоста, этот пост сможет получать доступ к таким ресурсам, как сетевой стек, процесс и IPC (Interprocess Communication) на уровне своего хоста. Но нужно ли вам в самом деле предоставлять доступ к пространству имён уровня хоста или устанавливать привилегированный режим для ваших подов или контейнеров? Кроме того, когда вам известно какие возможности требуются для ваших процессов в их контейнерах, было бы лучше отбросить такие ненужные права. И сколько памяти и ЦПУ достаточно для того чтобы ваша рабочая нагрузка была полностью функциональной? Задумайтесь, пожалуйста, об этих вопросах для целей реализации основного принципа наименьших полномочий под свои рабочии нагрузки Kubernetes. Надлежащим образом устанавливайте запросы и пределы ресурсов, применяйте контекст безопансоти для своих рабочих нагрузок и применяйте для своего кластера PodSecurityPolicy. Всё это поспособствует гарантии наименьших полномочий для ваших рабочих нагрузок при доступе к ресурсам системы.

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

Допустим, одна из ваших рабочих нагрузок (Под X) в пространстве имён X требуется обладать доступом только к другой Микрослужбе A в пространстве имён NS1; между тем, в пространстве имён NS2 имеется Микрослужба B . Обе микрослужбы, и A, и B выставляют свои терминалы (endpoints) RESTful (Representational State Transfer, Передачи состояния представления).По умолчанию ваша рабочая нагрузка способна получать доступ и к Микрослужбе A, и к Микрослужбе B в предположении что нет никакой аутентификации и авторизации на уровне своих микрослужб, а также не применяются никакие политики в пространствах имён NS1 и NS2, давайте взглянем на следующую схему, иллюстрирующую это:

На предыдущей схеме Под X способен получать доступ к обеим микрослужбам, хотя они располагаются в различных пространствах имён. Заметьте, что Поду X требуется доступ только к Микрослужбе A в пространстве имён NS1. Итак, есть ли нечто, что мы можем сделать для ограничения доступа Пода X Микрослужбе A для достижения наименьших полномочий? Да: может помочь сетевая политика Kubernetes. Мы рассмотрим сетевые политики в Главе 5, Настройка границ безопасности Kubernetes. В общем, сетевая политика Kubernetes определяет правила того, как некой группе подов допускается взаимодействовать друг с другом и прочими сетевыми терминалами. Вы можете определять для ваших рабочих нагрузок как входящие (ingress) правила, так и исходящие (egress) правила.

В нашем следующем примере, для реализации нашего принципа наименьших полномочий в Поде X, вам потребуется определить сетевую политику в Пространстве имён X с неким исходящим правилом, предписывающим что разрешён только доступ к Микрослужбе A:

В нашей предыдущей схеме, установленная сетевая политика в Пространстве имён X блокирует все запросы от Пода X к Микрослужбе B, а Под X всё ещё способен выполнять доступ к Микрослужбе A, как и ожидалось. Задание исходящего правила в вашей сетевой политике способствует обеспечению наименьших прав для доступа вашей рабочей нагрузке к сетевым ресурсам. И последнее, но не в отношении важности, нам всё ещё требуется требовать вашего внимания к соответствующему уровню ресурса приложения с точки зрения наименьших полномочий.

Хотя эта тема и относится к категории безопасности приложений, её стоит затронуть. Если имеются приложения к которым обращается ваша рабочая нагрузка и которые поддерживают несколько пользователей с различными уровнями полномочий, лучше проверить, требуются ли права, предоставляемые пользователю от имени вашей рабочей нагрузки. К примеру, пользователю, который отвечает за аудит, не требуются права на запись. Разработчикам следует помнить об этом при разработке своего приложения. Это помогает обеспечению наименьших привилегий для вашей рабочей нагрузки при доступе к ресурсам приложения.

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

Kubernetes предлагает встроенный контроль безопасности для реализации рассмотренного принципа наименьших полномочий. Обратите внимание, что это некий процесс от разработки вплоть до развёртывания: разработчики приложения должны сотрудничать с архитекторами безопасности для проектирования наименьших полномочий учётным записям служб, ассоциированных с этим приложением, а также минимальных возможностей и надлежащего выделения ресурсов. На протяжении развёртывания, DevOps должны рассмотреть применение PodSecurityPolicy и сетевой политики для использования преимуществ наименьших полномочий по всему кластеру целиком.

В своей следующей главе мы рассмотрим безопасность Kubernetes с другого угла зрения: с понимания ограничений безопасности различных типов ресурсов и того как они укрепляют их.

Вы могли отметить, что некоторые из механизмов контроля безопасности, о которых мы говорили в этой главе, существуют уже давно: MCS/MLS (Multi-Category Security/ Multi-Level Security) SELinux, AppArmor, seccomp, возможности Linux и тому подобное. Уже имеется большое число книг и статей, представляющих введение в эти технологии. Я бы посоветовал вам взглянуть на следующие материалы, чтобы лучше разобраться с тем как их применять для достижения нашей цели наименьших полномочий в Kubernetes:

SELinux MCS: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/sec-mcs-getstarted

AppArmor: https://ubuntu.com/server/docs/security-apparmor

Возможности Linux: http://man7.org/linux/man-pages/man7/capabilities.7.html

Помощь в определении предоставления прав RBAC: https://github.com/liggitt/audit2rbac