GCP: Identity and Access Management
Я уже кратко описывал работу прав внутри облака в статье “Google Cloud Platform”. Сегодня расскажу как устроен IAM.
Полики IAM содержат роль, пользователя или группу пользователей. Каждая роль содержит в себе список разрешений.
Модель доступа состоит из трех основных частей:
- Участники (members). Любые учетные записи Google, сервисные аккаунты, Google Groups, Cloud Identity или GSuit домен.
- Роль (role). Набор разрешений, определяют какие операции можно выполнять с указанным ресурсом.
- Политика (policy). Объеденение роли и участников.

Также в качестве участника можно установить два специальных значения:
- allUsers — любой пользователь в интернете
- allAuthenticatedUsers — любой пользователь, авторизированный с помощью гугл аккаунта, даже если это личный аккаунт
Отдельно нужно упомянуть иерархию ресурсов. Она позволяет группировать ресурсы и централизованно управлять доступами используя систему наследования прав. Политики установленные на уровне папки будут распространятся на все проекты и подпапки.
Основные концепты
Ресурсы
Компоненты, которые выполняют работу. В основном права выдаются на уровне проекта. Но для некоторых ресурсов можно атомарно настроить права. Например выдать права администратора на конкретный экземпляр виртуальной машины.
Разрешения
Разрешения описывают операции, которые можно выполнять с ресурсами. Имеют следующий вид — service.resource.verb.

В большинстве случаев, разрешения соотносятся одним к одному с методами REST API. То есть, каждая служба Google Cloud содержит соответствующий набор разрешений для каждого метода REST API, который она предоставляет.
Роли
Роли — набор разрешений. Несколько разрешений желательно собирать в отдельную роль, которую назначать группе пользователей, вместо того чтобы раздавать разрешения напрямую пользователям.
Роли делятся на три типа:
- Примитивная роль (Primitive) — самая простая и общая. Указывает какие действия можно выполнить со всеми ресурсами. Всего есть 4 примитивных роли: owner, editor, viewer и billing administrator.
- Предустановленные роли (Predefined). Ими можно тонко настроить права. Указывают кто и какое действие разрешено выполнять с определенным ресурсов. Каждый ресурс в GCP содержит готовый набор predefined ролей.
- Кастомные роли позволяют указать любой набор разрешений и предоставить их любому пользователю или группе.

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

Отличия сервисных аккаунтов от обычных
- Сервисный аккаунт не имеет пароля. Мы не сможем залогиниться через браузер.
- Сервисный аккаунт содержит публичный и приватный ключ с помощью которого он авторизуется в облаке.
- Разрешение serviceAccountUser позволяет выдавать пользователя за сервисный аккаунт.
Типы сервисных аккаунтов
- Пользовательские, можно создать до 100 аккаунтов, количество можно увеличить, поменяв квоту. Такие аккаунты создаются со следующим электронным адресом: [email protected]
- Дефолтные — для каждого проекта автоматически создаются два аккаунта, каждый имеет права Editor. Один используется для взаимодействия с App Engine ([email protected]), а второй для Compute Engine ([email protected]).
- Аккаунты Google API — создаются и управляются на стороне Google, обеспечивают взаимодействие с сервисами гугла.
Рекомендации
- Следовать принципу наименьшей ответственности — выдавать пользователю только те права, которые ему необходимы.
- Выдавать права на группы, а не на отдельных пользователей.
- Внимательно следить за правами serviceAccountUser.
Больше советов можно посмотреть в документации: IAM recommender best practices.