Короткий ответ
ServiceAccount — это идентификатор, от имени которого процессы внутри Pod обращаются к Kubernetes API; каждый Pod использует какой-либо ServiceAccount (по умолчанию — default в своём namespace), и права этого аккаунта определяются через RBAC.
Как это работает подробнее
при создании Pod в него автоматически монтируется токен ServiceAccount (JWT), который приложение может использовать для аутентификации при обращении к Kubernetes API сервера. Сами по себе права не предоставляются ServiceAccount автоматически — их нужно явно выдать через Role/RoleBinding или ClusterRole/ClusterRoleBinding.
Пример кода
manifest.yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: ci-deployer }
---
apiVersion: v1
kind: Pod
metadata: { name: deployer-pod }
spec:
serviceAccountName: ci-deployer
containers:
- name: app
image: bitnami/kubectl:1.29Что использовать на практике
- Практика. ServiceAccount нужен, когда приложению внутри кластера требуется взаимодействовать с Kubernetes API — например, оператору, который следит за ресурсами, или CI-агенту, разворачивающему манифесты. Для приложений, которым не нужен доступ к API Kubernetes, лучше явно отключить автомонтирование токена (
automountServiceAccountToken: false), чтобы снизить площадь атаки.
Подводные камни
- Риски. давать
defaultServiceAccount широкие права через ClusterRoleBinding "на всякий случай", что делает любой под в namespace потенциально опасным, если у него есть доступ к API; не отключать automount токена у подов, которым он не нужен, оставляя неиспользуемые учётные данные внутри каждого контейнера.