Service account kubernetes что это
Reference Documentation
Design docs, concept definitions, and references for APIs and CLIs.
Service Accounts
A service account provides an identity for processes that run in a Pod.
This is a user introduction to Service Accounts. See also the Cluster Admin Guide to Service Accounts.
Note: This document describes how service accounts behave in a cluster set up as recommended by the Kubernetes project. Your cluster administrator may have customized the behavior in your cluster, in which case this documentation may not apply.
Using the Default Service Account to access the API server.
You can access the API using a proxy or with a client library, as described in Accessing the Cluster.
Using Multiple Service Accounts.
You can create additional serviceAccounts like this:
If you get a complete dump of the service account object, like this:
then you will see that a token has automatically been created and is referenced by the service account.
You may use the ABAC authorization plugin to set permissions on service accounts.
To use a non-default service account, simply set the spec.serviceAccount field of a pod to the name of the service account you wish to use.
The service account has to exist at the time the pod is created, or it will be rejected.
You cannot update the service account of an already created pod.
You can clean up the service account from this example like this:
Manually create a service account API token.
Suppose we have an existing service account named “build-robot” as mentioned above, and we create a new secret manually.
Now you can confirm that the newly built secret is populated with an API token for the “build-robot” service account.
Note that the content of token is elided here.
Adding ImagePullSecrets to a service account
First, create an imagePullSecret, as described here Next, verify it has been created. For example:
Next, read/modify/write the service account for the namespace to use this secret as an imagePullSecret
Now, any new pods created in the current namespace will have this added to their spec:
Adding Secrets to a service account.
TODO: Test and explain how to use additional non-K8s secrets with an existing service account.
Азбука безопасности в Kubernetes: аутентификация, авторизация, аудит
Рано или поздно в эксплуатации любой системы встаёт вопрос безопасности: обеспечения аутентификации, разделения прав, аудита и других задач. Для Kubernetes уже создано множество решений, которые позволяют добиться соответствия стандартам даже в весьма требовательных окружениях… Этот же материал посвящён базовым аспектам безопасности, реализованным в рамках встроенных механизмов K8s. В первую очередь он будет полезен тем, кто начинает знакомиться с Kubernetes, — как отправная точка для изучения вопросов, связанных с безопасностью.
Аутентификация
В Kubernetes есть два типа пользователей:
Обычные же Users не имеют записей в Kubernetes API: управление ими должно осуществляться внешними механизмами. Они предназначены для людей или процессов, живущих вне кластера.
Каждый запрос к API привязан либо к Service Account, либо к User, либо считается анонимным.
Аутентификационные данные пользователя включают в себя:
Более того, допускается использование нескольких схем авторизации одновременно. По умолчанию в кластере используются:
Сертификаты для пользователей (X.509)
Классический способ работы с сертификатами предполагает:
Для облегчения переноса конфига между учетными записями и серверами полезно отредактировать значения следующих ключей:
Сертификаты с kubeadm
С релизом Kubernetes 1.15 работа с сертификатами стала значительно проще благодаря альфа-версии её поддержки в утилите kubeadm. Например, вот как теперь может выглядеть генерация конфигурационного файла с ключами пользователя:
Результирующий конфиг будет выведен в stdout. Его нужно сохранить в
Копнуть глубже
Для желающих тщательнее разобраться в описанных вопросах:
Авторизация
Аутентифицированная учетная запись по умолчанию не имеет прав на действия в кластере. Для предоставления разрешений в Kubernetes реализован механизм авторизации.
До версии 1.6 в Kubernetes применялся тип авторизации, называемый ABAC (Attribute-based access control). Подробности о нём можно найти в официальной документации. В настоящее время этот подход считается устаревшим (legacy), однако вы всё ещё можете использовать его одновременно с другими типами авторизации.
К слову, мы уже публиковали статью с достаточно подробным рассказом о принципах и особенностях работы с RBAC, поэтому далее ограничусь кратким перечислением основ и примеров.
Для управления доступом в Kubernetes через RBAC используются следующие сущности API:
Роли описывают права при помощи наборов правил, содержащих:
Примеры сущностей RBAC
Аудит событий
Схематично архитектуру Kubernetes можно представить следующим образом:
Ключевой компонент Kubernetes, отвечающий за обработку запросов, — api-server. Все операции над кластером проходят через него. Подробнее об этих внутренних механизмах можно почитать в статье «Что происходит в Kubernetes при запуске kubectl run?».
Аудит системы — интересная фича в Kubernetes, которая по умолчанию выключена. Она позволяет логировать все обращения к Kubernetes API. Как легко догадаться, через этот API производятся все действия, связанные с контролем и изменением состояния кластера. Хорошее описание её возможностей можно (как обычно) найти в официальной документации K8s. Далее я постараюсь изложить тему более простым языком.
Итак, чтобы включить аудит, нам нужно передать контейнеру в api-server три обязательных параметра, подробнее о которых рассказано ниже:
Политика аудита
Также все запросы проходят через несколько стадий:
В файле политики мы можем описать несколько секций с разными уровнями логирования. Применяться будет первое подходящее правило, найденное в описании policy.
Демон kubelet отслеживает изменение манифеста с конфигурацией api-server и при обнаружении таковых перезапускает контейнер с api-server. Но есть важная деталь: изменения в файле policy будут им игнорироваться. После внесения изменений в файл policy потребуется перезапустить api-server вручную. Поскольку api-server запущен как static pod, команда kubectl delete не приведёт к его перезапуску. Придется вручную сделать docker stop на kube-master’ах, где изменена политика аудита:
При включении аудита важно помнить, что на kube-apiserver повышается нагрузка. В частности, увеличивается потребление памяти для хранения контекста запросов. Запись в лог начинается только после отправки заголовка ответа. Также нагрузка зависит от конфигурации политики аудита.
Примеры политик
Разберём структуру файлов policy на примерах.
В policy можно указывать перечень пользователей ( Users и ServiceAccounts ) и групп пользователей. Например, вот так мы будем проигнорировать системных пользователей, но логировать всё остальное на уровне Request :
Также есть возможность описывать целевые:
Следующий audit policy приведён в качестве демонстрации лучших практик в документации Alibaba Cloud:
Другой хороший пример audit policy — профиль, используемый в GCE.
Для оперативного реагирования на события аудита есть возможность описать webhook. Этот вопрос раскрыт в официальной документации, оставлю его за рамками данной статьи.
Понимаем RBAC в Kubernetes
Прим. перев.: Статья написана Javier Salmeron — инженером из хорошо известной в Kubernetes-сообществе компании Bitnami — и была опубликована в блоге CNCF в начале августа. Автор рассказывает о самых основах механизма RBAC (управление доступом на основе ролей), появившегося в Kubernetes полтора года назад. Материал будет особенно полезным для тех, кто знакомится с устройством ключевых компонентов K8s (ссылки на другие подобные статьи см. в конце).
Слайд из презентации, сделанной сотрудником Google по случаю релиза Kubernetes 1.6
Многие опытные пользователи Kubernetes могут вспомнить релиз Kubernetes 1.6, когда авторизация на основе Role-Based Access Control (RBAC) получила статус бета-версии. Так появился альтернативный механизм аутентификации, который дополнил уже существующий, но трудный в управлении и понимании, — Attribute-Based Access Control (ABAC). Все с восторгом приветствовали новую фичу, однако в то же время бесчисленное число пользователей были разочарованы. StackOverflow и GitHub изобиловали сообщениями об ограничениях RBAC, потому что большая часть документации и примеров не учитывали RBAC (но сейчас уже всё в порядке). Эталонным примером стал Helm: простой запуск helm init + helm install больше не работал. Внезапно нам потребовалось добавлять «странные» элементы вроде ServiceAccounts или RoleBindings ещё до того, как разворачивать чарт с WordPress или Redis (подробнее об этом см. в инструкции).
Оставив же эти неудачные первые попытки в стороне, нельзя отрицать тот огромный вклад, что внёс RBAC в превращение Kubernetes в готовую к production платформу. Многие из нас успели поиграть с Kubernetes с полными привилегиями администратора, и мы прекрасно понимаем, что в реальном окружении необходимо:
Ключ к пониманию RBAC в Kubernetes
Чтобы полностью осознать идею RBAC, нужно понимать, что к ней причастны три элемента:
Если помнить об этих трёх элементах, ключевая идея RBAC звучит так:
— Мы хотим соединить субъекты, ресурсы API и операции. Другими словами, мы хотим указать для заданного пользователя, какие операции могут быть исполнены на множестве ресурсов.
Разбираемся с объектами RBAC в API
В соединении этих трёх типов сущностей становятся понятными и доступные в Kubernetes API объекты RBAC:
Субъекты: пользователи и… ServiceAccounts?
… но вот такой уже нет:
У этой ситуации серьёзное последствие: если кластер не будет хранить информацию о пользователях, администратору придётся управлять учётными записями вне кластера. Здесь есть разные способы решения проблемы: TLS-сертификаты, токены, OAuth2 и т.п.
RBAC в Deployments: пример
Мы видели пример, в котором указанному пользователю выдаются права на операции в кластере. Но что насчёт Deployments, требующих доступа к Kubernetes API? Рассмотрим конкретный сценарий, чтобы разобраться получше.
Возьмём для примера популярное инфраструктурное приложение — RabbitMQ. Будем использовать Helm-чарт для RabbitMQ от Bitnami (из официального репозитория helm/charts), который использует контейнер bitnami/rabbitmq. В контейнер встроен плагин для Kubernetes, отвечающий за обнаружение других членов кластера RabbitMQ. Из-за этого процесс внутри контейнера требует доступа к Kubernetes API, и нам потребуется настроить ServiceAccount с правильными RBAC-привилегиями.
— Настраивайте ServiceAccounts для каждого Deployment с минимальным набором привилегий.
В случае приложений, требующих доступа к Kubernetes API, у вас может возникнуть соблазн создать некий «привилегированный ServiceAccount », который сможет делать в кластере практически всё. Хотя это кажется более простым решением, в конечном счёте оно может привести к уязвимости в безопасности, позволяющей выполнять нежелательные операции. (В видео рассматривается пример Tiller [компонента Helm] и последствий наличия ServiceAccounts с большими привилегиями.)
Не забывая об этом, посмотрим, какая конфигурация RBAC будет правильной для случая Deployment‘а с RabbitMQ.
В документации плагина и его исходном коде можно увидеть, что он запрашивает у Kubernetes API список Endpoints. Так и происходит обнаружение остальных членов кластера RabbitMQ. Поэтому чарт RabbitMQ от Bitnami создаёт:
Схема показывает, что мы разрешили процессам, запущенным в подах RabbitMQ, исполнять операции get над объектами Endpoint. Это минимальный набор операций, который требуется для того, чтобы всё работало. В то же время мы знаем, что развёрнутый чарт безопасен и не выполнит нежелательных действий внутри кластера Kubernetes.
Заключительные мысли
Чтобы работать с Kubernetes в production, политики RBAC не являются опциональными. Их нельзя рассматривать как набор объектов API, который должны знать только администраторы. Они на самом деле нужны разработчикам для развёртывания безопасных приложений и полного использования потенциала, предлагаемого Kubernetes API для облачных (cloud native) приложений. Больше информации по RBAC можно получить по этим ссылкам:
Kubernetes: ServiceAccounts, JWT-токены, аутентификация и RBAC-авторизация
Для аутентицикации и авторизации в Kubernetes имеются такие понятия как User Accounts и Service Accounts.
User Accounts – профили обычных пользователей, используемые для доступа к клатеру снаружи кластера, тогда как Service Accounts используются для аутентификации сервисов внутри кластера.
ServiceAccounts предназначены для предоставления идентификатора, используя который Kubernetes Pod, а точнее контейнер(ы) в нём, могут быть аутенифицированы и авторизованы для выполнения API-запросов к API-серверу Kubernetes.
Default ServiceAccount
В каждом Kubernetes Namespace имеется свой дефолтный ServiceAccount (SA), который создаётся вместе с самими нейспейсом.
Проверим default namespace:
Для каждого создаваемого ServiceAccount генерируется токен, который хранится в Kubernetes Secret.
Проверяем default SA:
Токен этого SA – в секрете default-token-292g9:
default token
Посмотрим содержимое секрета:
Если токен не default namespace – то будет ещё и третье поле с указанием неймспейса, которому токен принадлежит.
ca.cert подписывается приватным ключём кластера (который играет роль Certificate Authority) и позволяет поду или приложению валидировать запросы к API-серверу, что бы убедиться что это именно тот API-сервер, который нужен.
А вот на token остановимся подробнее.
JWT token
Для удобства сохраним строку из data.token в переменную:
С помощью base64 получаем содержимое:
Тут в […] вырезана часть, но видим, что токен точками разделён на три части:
В нашем случае payload токена будет таким:
Тут в sub видим имя сервис аккаунта, т.е. когда предъявитель токена передаёт его API-серверу Kubernetes – кластер знает, от чьего имени этот токен пришёл.
Но что на счёт пароля? В sub есть “имя пользователя” – но где его “пароль”?
Тут работает третья часть токена – signature.
JWT токен и аутентификация
Почему-то нигде из нагугленных материалов этот момент не рассматривается (см. ссылки в Ссылки по теме), хотя он тут наверно самый интересный.
Вернёмся к первой части токена – header, который в нашем случае содержит тип алгоритма RS256, т.е. RSA (Rivest-Shamir-Adleman) – ассиметричный алгоритм с использованием приватного и публичного ключа, и SHA-256 подписи для проверки данных.
Проверим наш токен на jwt.io:
Invalid Signature – так как мы не предоставили приватный и публичный ключ для верификации.
Запускаем локальный кластер:
В его default нейспейсе уже есть дефолтный токен:
Снова идём на jwt.io, вставляем токен:
Пока что Invalid Signature – берём публичный сертификат minikube – файл
Вставляем в поле Public Key or Certificate.
Получаем приватный ключ кластера – собственно он и используется для подписи тех же ca.crt и токенов – файл
Вставляем в поле Private Key:
Signature Verified – готово, подлинность предъявителя сертификата проверена.
Итак, возвращаясь к ServiceAccount:
Теперь, посмотрим, как это выглядит на практике, плюс проверим, как тут работает Kubernetes RBAC.
ServiceAccounts и RBAC
Для каждого пода, которому явно не задан ServiceAccount, подключается ServiceAccount default, и монтируется дефолтный токен.
Возвращаемся к нашему EKS кластеру, запускаем под:
☸️ Как создать в Kubernetes службу / аккаунт пользователя и ограничить его одним пространством имен с помощью RBAC
Как создать пользователя и ограничить доступ пользователя только к одному пространству имен в Kubernetes?
Kubernetes дает вам возможность регулировать доступ к кластерам и ресурсам Kubernetes на основе ролей отдельных пользователей с помощью функции, называемой управлением доступом на основе ролей (RBAC).
Начиная с выпуска 1.8 Kubernetes, режим RBAC стабилен и поддерживается API rbac.authorization.k8s.io/v1.
Есть несколько определений, которые вы должны понять, прежде чем мы продолжим:
Чтобы добиться полной изоляции в Kubernetes, мы будем использовать концепции пространств имен и управления доступом на основе ролей.
Идея сервисных учетных записей основана на принципе наименьших привилегий.
Учетная запись создается для конкретных задач.
Как создать и ограничить учетную запись службы пространством имен в Kubernetes
Шаг 1: Создайте пространство имен
Давайте начнем с создания пространства имен, которое будет использоваться для этой демонстрации.
Шаг 2. Создание учетной записи службы
Мы создадим учетную запись службы под названием demo-user в пространстве имен demo
Вы получите такой вывод:
Шаг 3: Создать роль
Как объяснялось ранее, роль содержит правила, которые представляют собой набор прав, которые предоставляют доступ к ресурсам в пространстве имен.
Сначала подтвердите версии API для RBAC, доступные в вашем кластере Kubernetes: