Понимание сервисных аккаунтов в Kubernetes

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

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

В Kubernetes есть два типа пользователей: обычные пользователи и пользователи сервисных аккаунтов. Люди - обычные пользователи, и эти пользователи не управляются кластером Kubernetes. Учетные записи служб обслуживаются кластером Kubernetes. Учетные записи служб предназначены для представления процессов, выполняемых в модулях кластера.

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

С другой стороны, учетные записи служб привязаны к определенному пространству имен. Они создаются автоматически сервером API или вручную посредством вызовов API. Тот факт, что учетная запись службы привязана к определенному пространству имен, очень важен. Это обеспечивает изоляцию пространства имен.

Каждый раз, когда мы создаем модуль в кластере, Kubernetes назначает этому модулю учетную запись службы. Этот сервисный аккаунт идентифицирует процесс модуля при его взаимодействии с сервером API. Однако назначать учетную запись службы модулю или развертыванию необязательно. Это означает, что если в нашем файле манифеста не указана учетная запись службы, наш модуль будет развернут, и он по-прежнему сможет взаимодействовать с сервером API.

Причина вышеупомянутого поведения заключается в том, что всякий раз, когда мы создаем новый namespace в нашем кластере, Kubernetes создает для нас учетную запись службы по умолчанию в этом пространстве имен. Когда модуль не имеет учетной записи службы в своем манифесте и развертывается в этом пространстве имен, этому модулю будет назначена учетная запись службы по умолчанию.

Что такое учетная запись службы?

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

Чтобы получить учетную запись службы в пространстве имен по умолчанию, выполните команду kubectl get serviceaccount -n default. Если вы не создали никакой другой учетной записи службы в этом пространстве имен, вы получите учетную запись службы с именем default.

Чтобы просмотреть дополнительные сведения об этой учетной записи службы, выполните команду, kubectl get serviceaccount default -n default -o yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: "2021-01-26T09:12:15Z"
  name: default
  namespace: default
  resourceVersion: "422"
  uid: 8843bb73-e090-4d48-9cd6-6d8717740af1
secrets:
- name: default-token-srs4v

Выше показано, что эта учетная запись службы имеет набор учетных данных, смонтированных в секретном томе. В данном конкретном случае секрет называется default-token-srs4v.

Чтобы проверить содержимое этого секрета, запустите эту команду kubectl get secret default-token-srs4v -o yaml

apiVersion: v1
data:
  ca.crt: <CONTENT-REMOVED>
  namespace: ZGVmYXVsdA==
  token: <CONTENT-REMOVED>
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: 8843bb73-e090-4d48-9cd6-6d8717740af1
  creationTimestamp: "2021-01-26T09:12:16Z"
  name: default-token-srs4v
  namespace: default
  resourceVersion: "417"
  uid: 46b2c8f4-41cc-4708-8901-15c2021ea8ac
type: kubernetes.io/service-account-token

Мы видим, что секрет включает в себя файл ca.crt  и расширение token.  ca.crt это общедоступный ЦС сервера API, а токен - это подписанный веб-токен JSON (JWT).

Эти секреты монтируются в модуле для доступа к серверу API в кластере, однако вы можете использовать этот кластер в качестве токена Bearer с запросом извне кластера, это не рекомендуется.

Аутентификация с помощью учетной записи службы

Когда процесс в модуле хочет связаться с сервером API, сервер API ожидает заголовок Authorization со значением Bearer THETOKEN. Маркер-носитель - это маркер JWT, который установлен на модуле в качестве секрета.

Когда сервер API получает запрос с правильным токеном носителя, запрос аутентифицируется. Если процесс аутентификации завершится неудачно, сервер API отклонит запрос с кодом состояния 401 HTTP.

После аутентификации пользователя запускается процесс авторизации. Kubernetes использует RBAC, чтобы определить, разрешено ли пользователю выполнять определенное действие с определенным ресурсом. RBAC состоит из Roles и RoleBinding, эти объекты задают область авторизации учетной записи службы.

Как управляются учетные записи служб?

Сервер API использует контроллер допуска учетной записи службы для проверки во время создания модуля, есть ли у модуля пользовательская учетная запись службы и существует ли эта учетная запись? Если учетная запись не указана, модулю назначается служебная учетная запись по умолчанию.

Доступ к учетной записи службы также добавляет том в модуль с маркером API для доступа к API и  volumeSource установленный на 

/var/run/secrets/kubernetes.io/serviceaccount

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

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

Заключение

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