Работа с сервисами GCP. Проекты и ресурсы.

Все ресурсы, которые используются в GCP, являются ли они виртуальными машинами, облачными хранилищами, таблицами и большим запросом или чем-то еще, организованы в проекты (project). По желанию, эти проекты могут быть организованы в папки (folder). Папки могут содержать другие папки. Все папки и проекты могут быть объединены в узле организации (node). Проекты, папки и узел организации — это места, где могут быть определены политики. Некоторые ресурсы GCP позволяют устанавливать политики на отдельные ресурсы, например, на корзины облачных хранилищ. Политики наследуются вниз по иерархии. Все ресурсы платформы Google Cloud принадлежат проекту. Проекты являются основой для включения и использования GCP-сервисов, таких как управление API, включение биллинга, добавление и удаление сотрудников и включение других сервисов Google.

Каждый проект представляет собой отдельный отсек, и каждый ресурс принадлежит ровно одному. Проекты могут иметь разных владельцев и пользователей - они построены отдельно и управляются отдельно. Каждый проект GCP имеет имя и идентификатор проекта, которые ему назначаеся при создании. Идентификатор проекта является постоянным, неизменным идентификатором и должен быть уникальным в GCP. Идентификаторы проектов в используются в нескольких контекстах, чтобы сообщить GCP, с каким проектом необходимо работать. Для удобства можно присвоить названия проектов. GCP также присваивает каждому из проектов уникальный номер проекта, и он отображается в различных контекстах. В общем, идентификаторы проекта сделаны как строки, читаемые человеком, и вы будете использовать их часто для ссылки на проекты.

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

Папки позволяют командам делегировать административные права, чтобы они могли работать независимо. Ресурсы в папке наследуют политики IAM из папки. Итак, если проекты project_3 и project_4 управляются одной и той же командой по дизайну, то можно поместить политики IAM в папку B.

Размещение дубликатов этих политик в непосредственно project_3 и project_4 излишне и подвержено ошибкам.

Для того чтобы использовать папки, необходим узел организации в верхней части иерархии. Он предназначен для объединения всех проектов в компании в единую структуру централизованного мониторинга использования ресурсов и применения политик.

Есть некоторые особые роли, связанные с этим узлом. Например, можно назначить пользователя администратором политики организации, чтобы только пользователи с данными привилегиями могли изменять политики. Можно назначить роль создателя проекта, что является отличным способом контролировать, кто может тратить деньги. После того, когда создан узел организации, можно создать в нем папки и размещать в них проекты.

Преимущества организационного ресурса:

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

Кроме того, администраторы организации имеют централизованный контроль над всеми ресурсами. Они могут просматривать и управлять всеми проектами вашей компании. Это принудительное применение означает, что больше не может быть теневых проектов или администраторов-мошенников.

Кроме того, можно предоставлять роли на уровне организации, которые наследуются всеми проектами и папками в рамках ресурса Организации. Например, предоставить роль администратора сети сетевой команде на уровне организации, позволяя управлять всеми сетями во всех проектах вашей компании, вместо того, чтобы предоставлять им роль для всех отдельных проектов.

Ресурс организации, предоставляемый API-интерфейсом менеджера ресурсов, состоит из следующих компонентов:

• Идентификатор организации, который является уникальным идентификатором организации.

• Отображаемое имя, которое создается на основе основного доменного имени в Google Workspace или Cloud Identity.

• Время создания организации.

• Время последнего изменения организации.

• Владелец организации. Владелец указывается при создании ресурса Организации. Его нельзя изменить, как только он установлен. Это идентификатор клиента Google Workspace, указанный в API каталога.

Вот пример того, как можете организовать свои ресурсы.

Есть три проекта, каждый из которых использует ресурсы нескольких сервисов GCP. В этом примере мы не использовали никаких папок, хотя мы всегда могли перемещать проекты в папки. Ресурсы наследуют политики родительского ресурса. Например, если установить политику на уровне организации, она автоматически наследуется всеми дочерними проектами. И это наследство является транзитивным, что означает, что все ресурсы в этих проектах тоже наследуют политику. Эффективная политика на каждом узле иерархии является результатом политик, непосредственно применяемых на узле, и политик, унаследованных от его предков.

Attention

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