Создание и использование сервисных аккаунтов в Google Cloud

Быстрые ссылки

• Создание сервисного аккаунта
• Использование сервисного аккаунта

Что такое сервисный аккаунт

Сервисный аккаунт — это специальный аккаунт, предназначенный для аутентификации приложений и служб с доступом к ресурсам Google Cloud. Он действует как «пользователь» со своими правами, но используется машиной или приложением.

Коротко: сервисный аккаунт — это идентификатор + права для сервисов, не для людей.

Создание сервисного аккаунта

1. Откройте консоль IAM & Admin в Google Cloud.
2. В боковой панели нажмите “Service Accounts” (Сервисные аккаунты).
3. Нажмите “Create” (Создать) для нового аккаунта.

4. Задайте понятное имя и описание. Внутренний email сервисного аккаунта будет иметь вид:

project-id.iam.gserviceaccount.com

5. На следующем шаге назначьте роли (roles) — это наборы прав, которые определяют, что аккаунт может делать в проекте.

6. При необходимости назначьте администраторов или пользователей, которые смогут управлять сервисным аккаунтом.

7. Для более тонкой настройки дайте аккаунту права только на нужные ресурсы — например, добавьте как член в настройки Permissions конкретного Compute Engine инстанса или Cloud Storage bucket.

Important: по возможности применяйте принцип наименьших привилегий — давайте только те роли, которые действительно необходимы.

Использование сервисного аккаунта

• Внутри GCP: многие сервисы (например, Compute Engine, Cloud Functions, Cloud Run) позволяют выбрать сервисный аккаунт в настройках инстанса/службы. Этот аккаунт будет использоваться по умолчанию для запросов из этой среды.

• Вне GCP (локальные приложения, внешние серверы): создайте ключ доступа для сервисного аккаунта в консоли IAM → Service Accounts → Keys → Create Key и скачайте JSON-файл.

Далее передайте путь к JSON-файлу приложению через переменную окружения:

GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json

Или используйте клиентские библиотеки Google, которые автоматически подхватывают эту переменную.

Важно: храните JSON-ключи в защищённом хранилище (секреты, KMS, Vault). При утечке ключа доступ к ресурсам может быть скомпрометирован.

Практические рекомендации и методология внедрения

Мини-методология внедрения сервисных аккаунтов:

1. Определите сценарии: какие приложения/инстансы нуждаются в доступе.
2. Разбейте по окружениям: prod/staging/dev — отдельные аккаунты и минимальные роли.
3. Назначьте роли: сначала минимально (Viewer/Custom), затем тестируйте и расширяйте при необходимости.
4. Управление ключами: если приложение размещено в GCP — не создавайте ключи, используйте привязку сервиса к инстансу; для внешних приложений используйте короткоживущие ключи и ротацию.
5. Мониторинг и аудит: включите аудит логов, регистрируйте использование аккаунтов.

Критерии приёмки

• Приложение успешно аутентифицируется и выполняет только разрешённые действия.
• Нет лишних глобальных (project-wide) ролей, права ограничены ресурсами.
• JSON-ключи сохранены в защищённом хранилище и присутствует план ротации.
• Аудит логирует обращения сервисного аккаунта.

Ролевые чек-листы

Для разработчика:

• Использует клиентские библиотеки Google.
• Переменная GOOGLE_APPLICATION_CREDENTIALS настроена локально для тестов.
• Не встраивает JSON-ключи в исходники.

Для администратора безопасности:

• Настроена ротация ключей.
• Проверены роли на принцип наименьших привилегий.
• Включён аудит доступа.

Для оператора/DevOps:

• Инстансы GCE/Cloud Run используют нужный сервисный аккаунт.
• Секреты с ключами хранятся в защищённом хранилище.

Когда сервисные аккаунты не подходят (примеры)

• Нужно предоставить временный доступ человеку — лучше создать пользовательский аккаунт или использовать временные IAM-последовательности (Short-lived credentials).
• Требуется межпроектный доступ без доверия — лучше настроить межпроектные роли и доверенные механизмы, а не раздавать проектные ключи.
• Потребность в MFA на уровне аккаунта — сервисные аккаунты не поддерживают интерактивную MFA.

Альтернативные подходы

• Workload Identity Federation: позволяет внешним системам (например, AWS, Azure, CI/CD) обмениваться доверенными токенами без хранения долгоживущих JSON-ключей.
• Short-lived credentials (краткоживущие токены) через OAuth/OIDC — лучше для безопасности.

Тестовые сценарии (приёмка)

1. Поднять тестовый инстанс, назначить сервисный аккаунт и выполнить gcloud-запросы с инстанса.

gcloud auth list

2. Запустить локальное приложение с переменной GOOGLE_APPLICATION_CREDENTIALS и попытаться получить доступ к нужному bucket — подтвердить успешный read/write.
3. Удалить ключ и убедиться, что доступ прекращён.

Краткий словарь

• Сервисный аккаунт — идентификатор и права для не‑человеческих сущностей.
• Роль (role) — набор разрешений.
• JSON-ключ — приватный ключ для аутентификации сервисного аккаунта вне GCP.

Заключение

Сервисные аккаунты — основной инструмент для безопасной аутентификации сервисов в Google Cloud. Используйте их вместе с принципом наименьших привилегий, избегайте хранения ключей в публичных местах и рассматривайте современные альтернативы (Workload Identity) для внешней интеграции.

Сводка:

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