Есть ли максимальное количество проектов, к которым может иметь доступ сервисный аккаунт?

Я пишу приложение, которое выполняет небольшую работу в разных проектах на gcp. Пользователь добавляет учетную запись службы (из моего проекта) по электронной почте в качестве участника политик IAM в свой проект. Затем он назначает некоторые права, и приложение может выполнять свою работу.

Приложение может расти в связанных проектах, поэтому мой вопрос:

существует ли максимальное количество проектов, участником которых может быть учетная запись службы?

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

Есть ли лучший способ обработки учетных записей «многопроектных» служб масштабируемым и безопасным способом?


person user2122552    schedule 22.10.2018    source источник


Ответы (1)


«Существует ли максимальное количество проектов, в которых может участвовать сервисный аккаунт?»

Учетные записи служб используются для вызова API служб Google. Поскольку вы должны добавить учетную запись службы из другого проекта (назовите этот проект B) в качестве участника проекта (назовите этот проект A), чтобы назначить ему роли / разрешения в проекте A, я считаю, что следующие ограничения также применимы к вашему вопросу.

Какое максимальное количество сервисных аккаунтов я могу иметь в проекте?

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

Часто задаваемые вопросы об IAM Google

Вы можете создать до 100 учетных записей служб для каждого проекта (включая учетную запись службы Compute Engine по умолчанию и учетную запись службы App Engine) с помощью IAM API, консоли GCP или инструмента командной строки gcloud. Эти учетные записи служб по умолчанию и явно созданные вами учетные записи служб являются управляемыми пользователями учетными записями служб.

Учетные записи служб Google

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

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

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

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

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

  • Определите соглашение об именах для своих учетных записей служб.

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

  • Воспользуйтесь преимуществами API сервисного аккаунта IAM, чтобы реализовать ротацию ключей.

  • Выполняйте аудит учетных записей и ключей служб с помощью метода serviceAccount.keys.list () или страницы средства просмотра журналов в консоли.

  • Не удаляйте сервисные аккаунты, которые используются запущенными экземплярами в Google App Engine или Google Compute Engine.

Общие сведения об учетных записях служб

person John Hanley    schedule 22.10.2018
comment
Спасибо за ответ от Google docs. Возможно, я не совсем понял, вопрос в том, есть ли у меня проект A, который создает учетную запись службы. К скольким проектам X я могу добавить эту сервисную учетную запись в качестве участника? Есть ли этому предел? Я что-то читал об ограничении в 600 токенов обновления для учетной записи службы. Если эта учетная запись является участником 1k + проектов и через 2 минуты он аутентифицируется во всех этих проектах для выполнения заданий, создаст ли это проблемы с аутентификацией и т. Д.? - person user2122552; 22.10.2018
comment
Google удалил документ с ограничением 600 токенов обновления, поэтому я не знаю об этом. Однако вы неправильно понимаете, что такое учетная запись службы и как она используется. Он используется для вызова API. Это означает, что токен доступа будет сгенерирован и использован для этого вызова API. Вызов API будет направлен на службу. Эта услуга будет в одном проекте. Токен не будет аутентифицироваться в проектах 1K +, только с одной службой в этот момент времени. Токены доступа действительны в течение одного часа (изменяемые), поэтому я не уверен, какое кеширование может быть выполнено, но токен доступа можно повторно использовать снова и снова. - person John Hanley; 22.10.2018
comment
У вас должна быть возможность добавить одну и ту же учетную запись пользователя (в данном случае учетную запись службы) в разные проекты. Хотя эта статья справочного центра актуальна для организаций корпоративного размера и по-прежнему может служить хорошим справочником для вашего варианта использования. Как объясняется там, учетным записям служб может быть предоставлен доступ к нескольким проектам, но при предоставлении доступа к нескольким проектам следите за необходимыми ролями / разрешениями, назначенными этой учетной записи в этом проекте. - person Digil; 24.10.2018
comment
@JohnHanley, спасибо за объяснение, я собираюсь инициировать только API-вызовы с учетной записью службы, но, вероятно, во многих проектах. Это простая функциональность, которую GCP не предоставляет, для которой я хочу создать сервис. В этом случае каждое действие, выполняемое в проекте, имеет свою собственную задачу в очереди задач, которая инициирует вызов appengine, где учетная запись службы используется для выполнения вызова в проекте x. Я никогда не говорил, что хочу использовать токен для нескольких проектов. Вопрос был в том, нужно ли мне создавать несколько учетных записей служб и есть ли лучшие практики для многопроектных учетных записей. - person user2122552; 25.10.2018