Я уже кратко описывал работу прав внутри облака в статье “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, обеспечивают взаимодействие с сервисами гугла.

Рекомендации

1. Следовать принципу наименьшей ответственности — выдавать пользователю только те права, которые ему необходимы.
2. Выдавать права на группы, а не на отдельных пользователей.
3. Внимательно следить за правами serviceAccountUser.

Больше советов можно посмотреть в документации: IAM recommender best practices.