Файл service account.json — это ключ (credential) сервисного аккаунта Google Cloud (GCP) в формате JSON. По сути это приватный ключ в удобном для машин виде плюс метаданные: идентификаторы проекта и аккаунта, URL для OAuth2 и сертификаты. Такой файл позволяет приложению аутентифицироваться в GCP от имени сервисного аккаунта и выполнять операции в рамках его прав.
Ключевые свойства:
Ниже — пример и краткие пояснения полей (обрезано для краткости):
{ "type": "service_account", "project_id": "my-project-123", "private_key_id": "abcd1234...", "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkq...\n-----END PRIVATE KEY-----\n", "client_email": "sa-name@my-project-123.iam.gserviceaccount.com", "client_id": "12345678901234567890", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token", "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", "client_x509_cert_url": "https://www.googleapis.com/..." }
Пояснения:
Через консоль: 1. IAM → Service Accounts → выбрать аккаунт → Keys → Add Key → Create new key → JSON → Download.
Через gcloud:
Команда выдаст JSON-файл, аналогичный примеру выше.
JSON даёт полный контроль над сервисным аккаунтом. С помощью него злоумышленник может:
Практические характеристики риска:
1. Откажитесь от долгоживущих user-managed ключей, где возможно - Используйте метаданные VM / Workload Identity / ADC вместо JSON. - Приложения на Compute Engine, GKE и Cloud Run должны получать short-lived токены из metadata server или через Workload Identity.
2. Workload Identity Federation (WIF) — предпочтительный подход - Позволяет приложениям за пределами GCP (on-prem, CI/CD, GitHub Actions) обменивать внешний токен (OIDC) на временные креденшалы без JSON-файлов. - Минимизирует необходимость хранения приватных ключей.
3. Принцип наименьших привилегий - Один сервисный аккаунт = одна задача/сервис. - Давать конкретные роли, не role/owner. Предпочитайте набор кастомных ролей с минимальным набором разрешений. - Пример: доступ к конкретному bucket — roles/storage.objectAdmin на уровне бакета, а не проекта.
4. Храните ключи только в менеджерах секретов - Google Secret Manager, HashiCorp Vault, AWS Secrets Manager и т.п. - Пример загрузки в Secret Manager: gcloud secrets create sa-key --replication-policy="automatic" gcloud secrets versions add sa-key --data-file=key.json
5. Ограничьте возможность создания ключей на уровне организации - Включите организационную политику, запрещающую создание user-managed ключей (org policy constraint для key creation) — это снижает вероятность появления долгоживущих ключей.
6. Логирование и мониторинг - Включите Cloud Audit Logs и настраивайте детектирование аномалий (создание ключей, нехарактерные IP, внезапные большие запросы к API). - Настройте оповещения на события создания ключей, имперсонации (ServiceAccountTokenCreator) и доступ к чувствительным ресурсам.
7. Ротация и удаление ключей - Регулярно ротация: рекомендуется периодичность от 30 до 90 дней для user-managed ключей, но лучше — 7–14 дней для критичных сервисов при возможности. - Удаляйте неиспользуемые ключи.
1. Немедленно удалить скомпрометированный ключ: - Найти key ID: gcloud iam service-accounts keys list --iam-account=sa-name@project.iam.gserviceaccount.com - Удалить: gcloud iam service-accounts keys delete KEY_ID --iam-account=sa-name@...
2. Отозвать временные токены (если нужно) и пересмотреть роли сервисного аккаунта. 3. Просмотреть Cloud Audit Logs на предмет активности: - Поиск по principalEmail: gcloud logging read 'protoPayload.authenticationInfo.principalEmail="sa-name@my-project.iam.gserviceaccount.com"' --limit=50 4. Временно приостановить/удалить сервисный аккаунт, если подозрение серьёзное: - gcloud iam service-accounts disable sa-name@... (Если нужно немедленно остановить все действия — можно удалить аккаунт, но это влияет на сервисы.) 5. Проанализировать инцидент (время, IP, вызовы API) и докрутить права и сеть (VPC Service Controls, firewall). 6. Сообщить команде безопасности и провести пост-мортем.
Создать SA: gcloud iam service-accounts create my-sa --display-name="Service account for app"
Добавить роль: gcloud projects add-iam-policy-binding my-project --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" --role="roles/storage.objectAdmin"
Создать ключ (если всё же нужно): gcloud iam service-accounts keys create key.json --iam-account=my-sa@my-project.iam.gserviceaccount.com
Загрузить ключ в Secret Manager: gcloud secrets create my-sa-key --replication-policy="automatic" gcloud secrets versions add my-sa-key --data-file=key.json
Удалить ключ: gcloud iam service-accounts keys delete KEY_ID --iam-account=my-sa@my-project.iam.gserviceaccount.com
Проверить логи по SA: gcloud logging read 'protoPayload.authenticationInfo.principalEmail="my-sa@my-project.iam.gserviceaccount.com"' --limit=100 --format="json"
Совет: минимальный набор прав + audit = лучший баланс.
Файл service account.json — удобный и мощный инструмент для автоматизации в GCP. Но его же удобство делает его опасным: утерянный JSON — это зачастую «ключ от облака». Современная практика безопасности предлагает двигаться от долгоживущих ключей к short-lived токенам и Workload Identity Federation, хранить секреты в менеджерах, ограничивать права и логировать любую активность. Если у вас в инфраструктуре ещё живут user-managed JSON-ключи — пора планировать их замену и вводить механизмы контроля: ротацию, аудит и автоматизированное управление доступом.