ServiceAccount
Тема дорожной карты · Kubernetes
Service Account — объекты идентификации Kubernetes, предоставляющие Pod'ам и контроллерам API-учётные данные для аутентификации в kube-apiserver, заменяя использование учётных данных пользователей-людей для внутрикластерной автоматизации. В каждом пространстве имён автоматически создаётся default ServiceAccount, Pod'ы назначаются ServiceAccount через spec.serviceAccountName; kubelet монтирует проецируемый токен сервисного аккаунта по пути /var/run/secrets/kubernetes.io/serviceaccount/token с настраиваемым expirationSeconds для ротации краткоживущих учётных данных. Объекты RBAC RoleBinding и ClusterRoleBinding Kubernetes предоставляют конкретные разрешения ServiceAccount в соответствии с принципом наименьших привилегий — например, контроллеру Argo CD нужны list и watch для всех типов ресурсов, тогда как Pod'у приложения обычно нужен только get для своих ConfigMap и Secret. Workload Identity в GKE и IAM Roles for Service Accounts (IRSA) в EKS позволяют ServiceAccount Kubernetes брать на себя облачные IAM-роли без статических учётных данных, давая Pod'ам доступ к S3, GCS или другим облачным API через федеративную идентичность. ServiceAccount также используются операторами, Helm, хуками post-install Kustomize и CI/CD-конвейерами, взаимодействующими с API Kubernetes изнутри кластера.
Как это работает
ServiceAccount в Kubernetes слоится через несколько контролей: RBAC (кто может делать что на каких ресурсах), Network Policies (какие pods могут общаться с какими), Pod Security Standards (ограничения privileged-операций), admission controllers (валидируют/мутируют ресурсы до persistence), underlying container runtime sandbox. Defence-in-depth: предполагайте, что любой single control будет обойдён, и проектируйте несколько слоёв.
Когда применять
Внедряйте ServiceAccount с создания кластера, не retrofit-ом позже — добавление RBAC в permissive кластер ломает десятки нагрузок. Начните с restrictive defaults и давайте доступ по нужде (least-privilege); применяйте NetworkPolicies в default-deny режиме; включайте PSS на уровне namespace. Регулируемые отрасли (банки, медицина) требуют это с дня 1; consumer-приложения выигрывают от этого до первого production-инцидента.
Типичные ошибки
Security-ловушки: cluster-admin role выдан разработчикам (полная власть; одна плохая команда сносит prod); image pull из ненадёжных registries без верификации подписи; serviceaccount tokens auto-mount в каждом pod (network access к API = lateral movement); пропуск CIS Kubernetes Benchmark-аудитов. Регулярный pentest находит реальные проблемы до того, как их найдут атакующие.