Учетные записи ServiceAccount – это ресурсы, такие же, как модули, секреты, словари конфигурации и т. д., которые ограничиваются отдельными простран[1]ствами имен. Устанавливаемая по умолчанию учетная запись ServiceAccount создается автоматически для каждого пространства имен (именно их и ис[1]пользовали ваши модули все время). Список учетных записей ServiceAccount можно вывести точно так же, как вы делаете это с другими ресурсами:

$ kubectl get sa

Текущее пространство имен содержит учетную запись по умолчанию ServiceAccount. При необходимости могут быть добавлены дополнительные учетные записи служб. Каждый модуль связан ровно с одной учетной записью службы, но несколько модулей могут использовать одну и ту же учетную запись. Как видно на рисунке, модуль может использовать учетную запись ServiceAccount только из того же пространства имен.

Как учетные записи служб связаны с авторизацией Вы можете назначить модулю учетную запись службы, указав имя учетной записи в манифесте модуля. Если вы не назначите ее явно, модуль будет использовать учетную запись службы по умолчанию в пространстве имен. Назначая модулям различные учетные записи служб, вы можете контролировать то, к каким ресурсам имеет доступ каждый модуль. Когда запрос, несущий в себе токен аутентификации, поступает на сервер API, сервер использует этот токен для аутентификации клиента, отправляющего запрос, а затем определяет, разрешено ли соответствующей учетной записи службы выполнять запрошенную операцию. Сервер API получает эту информацию от общесистемного плагина авторизации, сконфигурированного администратором кластера. Одним из плагинов авторизации является плагин управления ролевым доступом (role-based access control, RBAC), который рассматривается далее в этой главе. Начиная с Kubernetes версии 1.6 плагин RBAC должен использоваться большинством кластеров.

Создание учетных записей ServiceAccount

Для каждого пространства имен задана своя собственная, установленная по умолчанию учетная запись ServiceAccount, но при необходимости могут создаваться дополнительные. Но почему вы должны беспокоиться о создании учетных записей службы вместо использования тех, которые заданы для всех ваших модулей по умолчанию? Очевидная причина – это безопасность кластера. Модули, которым не нужно читать метаданные кластера, должны работать в соответствии с ограничен[1]ной учетной записью, которая не позволяет им извлекать или изменять ресурсы, развернутые в кластере. Модули, которым нужно извлекать метаданные ресурса, должны работать в соответствии с учетной записью ServiceAccount, которая позволяет только читать метаданные этих объектов, в то время как модули, которым нужно эти объекты модифицировать, должны работать в соответствии со своей собственной учетной записью ServiceAccount, разрешаю[1]щей производить модификацию объектов API. Давайте посмотрим, каким образом создаются дополнительные учетные записи служб, как они соотносятся с секретами и как их можно назначать вашим модулям.

Создание учетной записи службы

Создать учетную запись службы невероятно легко благодаря специальной команде kubectl create serviceaccount. Давайте создадим новую учетную запись с именем foo:

$ kubectl create serviceaccount foo

Теперь вы можете проверить эту учетную запись с помощью команды describe, как показано в следующем ниже листинге.

$ kubectl describe sa dre

Вы можете видеть, что секрет индивидуально настроенного токена был создан и связан с учетной записью службы. Если посмотреть на данные секрета с помощью команды kubectl describe secret footoken-dsf346, то вы увидите, что он содержит те же элементы (сертификат CA, пространство имен и токен), что и у токена учетной записи службы по умолчанию (сам токен, очевидно, будет другим). Это показано в следующем ниже листинге.

$ kubectl describe secret dre-token-dsf346

Монтируемые секреты учетной записи службы

Если проинспектировать учетную запись службы с помощью команды kubectl describe, то токен будет показан в списке монтируемых секретов (Mountable secrets). По умолчанию модуль может смонтировать любой секрет, который он захочет. Но учетная запись службы модуля может быть сконфигурирована так, чтобы разрешать модулю монтировать только те секреты, которые перечислены как монтируемые секреты в учетной записи службы. Чтобы активировать эту функциональную возможность, учетная запись службы ServiceAccount должна содержать следующую аннотацию: kubernetes.io/enforce-mountable secrets=»true». Если учетная запись ServiceAccount аннотируется этой аннотацией, любые использующие ее модули могут монтировать только монтируемые секреты учетных записей – они не могут использовать никакой другой секрет.

Секреты учетной записи для выгрузки образов

Учетная запись ServiceAccount также может содержать список секретов для выгрузки образов. Если вы не помните, то это секреты, которые содержат учетные данные для выгрузки образов контейнеров из приватного хранилища образов. В следующем списке показан пример определения учетной записи, который включает секрет извлечения образа

apiVersion: v1
kind: ServiceAccount
metadata:
   name: my-service-account
imagePullSecrets:
- name: my-dockerhub-secret

Секреты учетной записи ServiceAccount для выгрузки образа ведут себя не[1]много иначе, чем ее монтируемые секреты. В отличие от монтируемых секретов, они не определяют, какие секреты выгрузки образов используются модулем, а определяют, какие секреты автоматически добавляются во все модули с помощью учетной записи службы. Добавление секретов выгрузки образов в учетную запись ServiceAccount избавляет от необходимости добавлять их в каждый модуль по отдельности.

Назначение модулю учетной записи службы

осле создания дополнительных учетных записей ServiceAccount вам нужно назначить их модулям. Это делается путем выставления в определении модуля имени учетной записи службы в поле spec.serviceAccountName.

ПРИМЕЧАНИЕ. Учетная запись службы модуля должна быть установлена при создании модуля. Она не может быть изменена позже.