Это персонификация учетной записи службы в GCP - лучший способ обработки учетных данных и разрешений разработчика.

Question

В персонализации учетной записи службы GCP это способ создания временных учетных данных IAM для выполнения действий в качестве разработчика (см. здесь ). Это было описано как эквивалент принятия роли в AWS, см. Этот другой вопрос .

Мой вопрос:

это рекомендуемый / канонический способ делать это в облаке Google, а именно: группировать разрешения для учетных записей служб и разрешать разработчикам персонифицировать эту учетную запись службы? Или, в качестве альтернативы, лучше создавать собственные роли и назначать их непосредственно удостоверениям разработчиков (а не косвенно через учетную запись службы)? Но тогда, конечно, вы теряете преимущество коротких учетных данных.

Если первый вариант действителен, это также будет означать, что у вас будет столько учетных записей служб, сколько ролей в AWS.

Answer 1

В general необходимо предоставить роли IAM группам, а затем добавить разработчиков в соответствующие группы.

Например, вы можете предоставить всем разработчикам «Редактор» доступ к проект. Для этого предоставьте group:ll-developers@yourcompany.com роль редактора проекту. Затем используйте LDAP или G Suite, чтобы убедиться, что все разработчики являются членами этой группы.

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