Проект Google с внутренним согласием / Кто является участником моей организации и как мне управлять участниками?

Отказ от ответственности: https://console.cloud.google.com/support/community ведет сюда. Документация Google ужасна, так что давайте попробуем это сделать на случай, если я не проиграю до глубины dev / null

Из-за надвигающейся необходимости я переношу частное приложение, которое отслеживает наши действия Gmail, на OAuth 2, и как часть этого процесса необходимо было создать экран согласия OAuth. Поскольку это приложение будет использоваться только для внутреннего использования, имеет смысл выбрать «Internal» в качестве типа приложения, который описывается следующим образом:

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

Пользователи этого проекта состоят из двух «владельцев» - я использую свою личную учетную запись Gmail, и еще один сотрудник, который является частью корпоративной учетной записи G Suite.

У меня вопрос: кто квалифицируется как "пользователь в моей организации"? Это основано на владельцах проекта? Подходит ли мой аккаунт, не связанный с G-Suite (который является владельцем проекта)? Связывает ли включение одного участника в аккаунт G Suite автоматически другие аккаунты сотрудников? Есть ли где на самом деле видеть этих пользователей или управлять ими напрямую?

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

ОБНОВЛЕНИЕ. Чтобы уточнить, когда я захожу на страницу согласия, войдя в систему как участник нашего G Suite в том же домене, что и владелец проекта, все в порядке. Однако у нас есть другие участники, управляемые в той же учетной записи G Suite, которые находятся в другом домене, и для них я получаю сообщение:

Ошибка 403: org_internal. Доступ к этому клиенту ограничен пользователями внутри организации.

Более того, я даже не могу предоставить доступ, используя свой адрес электронной почты, который является создателем и владельцем приложения. Я хотел бы знать, как я могу добавить себя и других участников G Suite, чтобы иметь возможность предоставлять доступ к приложению, не делая его общедоступным. Ниже было предложено добавить их (или их домен) в Google Cloud IAM, но я не понимаю, как заставить это работать. Моя собственная электронная почта уже существует в IAM с ролью «владельца» и, очевидно, это не удовлетворяет требованиям.


google-cloud-platform google-cloud-iam google-iam google-oauth google-workspace
person billynoah    schedule 17.12.2019    source источник
comment
Роль Owner является унаследованной ролью. У этой роли нет all разрешений. Ответ на вопрос, как это сделать, зависит от того, как у вас настроена учетная запись. Если это Organization в определении Google Cloud, вам необходимо добавить свой идентификатор участника IAM на уровне организации с ролью администратора организации.   -  person John Hanley    schedule 18.12.2019
comment
Описание владельца проекта: Полный доступ ко всем ресурсам i.stack. imgur.com/ezHJX.png - кроме того, это приложение довольно новое, я не уверен, почему это можно считать устаревшей ролью   -  person billynoah    schedule 18.12.2019
comment
вам необходимо добавить свой идентификатор участника IAM - как я уже упоминал в вопросе, я использовал свою личную учетную запись Gmail, чтобы настроить это. Я не являюсь участником связанной учетной записи G Suite.   -  person billynoah    schedule 18.12.2019
comment
G Suite - это источник идентификационных данных, а не единственный. Пожалуйста, перечитайте мои комментарии и мой ответ. Вы можете использовать свой адрес электронной почты Gmail. Вам просто нужно разместить его на правильном уровне в организации с правильной ролью. Повторюсь - 1) Владелец не имеет всех разрешений в Google Cloud. Есть разрешения выше Владельца. 2) Владелец может предоставить себе больше разрешений. cloud.google.com/resource-manager/docs/quickstart-organizations   -  person John Hanley    schedule 18.12.2019
comment
Хорошо, я добавил свой личный адрес электронной почты с ролью Администратор организации через IAM. Теперь я вижу, что у меня есть доступ ко всем ресурсам организации в облачной консоли. Однако страница согласия по-прежнему возвращает ошибку: Ошибка авторизации - Ошибка 403: org_internal. Доступ к этому клиенту ограничен пользователями внутри организации.   -  person billynoah    schedule 18.12.2019

Ответы (3)


arrow_upward
4
arrow_downward

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

Учетные записи не-GSuite не могут использоваться внутренними приложениями. Дополнительную информацию об этом можно найти здесь: https://support.google.com/cloud/answer/6158849#public-and-internal.

person user2705223    schedule 18.12.2019
comment
Спасибо за краткий ответ с авторитетной ссылкой. К сожалению для меня, вы правы. Было бы неплохо, если бы Google сделал это более ясным на самой странице конфигурации согласия. Поскольку он говорит только в вашей организации, он оставляет вещи достаточно неоднозначными, чтобы я тратил много времени на попытки различных вещей через IAM (как предлагается в других ответах здесь). - person billynoah; 19.12.2019

arrow_upward
4
arrow_downward

Кто является членом моей организации?

Все, кого вы добавили в Google Cloud IAM для проекта, папки или на уровне организации. Это могут быть учетные записи Google (адреса электронной почты Gmail), G Suite и Google Identity. Последние два используют доменное имя (example.com) и всех, кто имеет личность в этом домене ([email protected]).

Цель Google - повысить безопасность Google Cloud Platform. Раньше любой, у кого был адрес электронной почты аккаунта Google, мог использовать OAuth ваших проектов для запроса доступа. Уровень доступа контролируется областями действия OAuth. Сегодня при предоставлении такого доступа отображается экран согласия с предупреждением о непроверенном приложении. Чтобы выйти за рамки (удалить) это предупреждение, часто требуется аудит безопасности вашего приложения, стоимость которого оценивается в 75 000 долларов США.

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

Через Google Cloud IAM. Вы можете добавлять и удалять участников; назначать и удалять роли IAM, прикрепленные к идентификаторам участников. Через G Suite или Google Identity путем добавления или удаления учетных записей участников. Не забывайте, что участники могут быть частью группы Google и частью домена, каждый из которых также является идентификатором в Google Cloud Platform.

person John Hanley    schedule 17.12.2019
comment
Спасибо, Джон, это очень помогло. Я взглянул на панель IAM и увидел, что для каждого участника требуется роль - не могли бы вы предложить какие-либо рекомендации относительно того, какая роль будет наиболее подходящей, если я хочу разрешить только согласие и токен OAuth работать на данного участника? - person billynoah; 18.12.2019
comment
Еще раз привет, Джон, кажется, добавление участников в IAM на самом деле не позволяет им предоставлять доступ по желанию. См. Мой обновленный вопрос. - person billynoah; 18.12.2019
comment
@billynoah Вы существенно меняете вопрос. Вы не предоставляете разрешения приложениям. Вы предоставляете сервисную учетную запись приложению, и оно должно использовать эту сервисную учетную запись. Ваши приложения не являются участниками Google Cloud IAM. Учетные записи служб - это еще один тип идентификатора Google Cloud IAM. Учетные записи служб назначаются облачным службам Google для предоставления им ролей IAM службы. Я рекомендую вернуться к вопросу, на который я ответил, а затем создать новый вопрос о том, как использовать учетные записи служб с облачными службами Google. - person John Hanley; 18.12.2019
comment
Если я не неправильно понимаю ваш ответ здесь, мне кажется, что я не могу использовать свою учетную запись Gmail, несмотря на то, что назначил ей роль в активе организации. Если это правда, это несколько противоречит утверждению в вашем первом абзаце. - person billynoah; 18.12.2019

arrow_upward
1
arrow_downward

Для пользователей GSuite:

Cloud IAM имеет дело только с авторизацией, которая вам понадобится для аутентификации где-то еще. По умолчанию GSuite интегрируется с CloudIAM в качестве поставщика аутентификации по умолчанию.

Для пользователей Non-GSuite:

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

Система единого входа без GSuite

Если вам нужен вариант единого входа, вы также можете использовать Google Cloud Directory Sync для синхронизации с локальным сервером Active Directory или LDAP для аутентификации. Таким образом, пользователи могут сохранить свои данные для входа.

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

Cloud IAM и авторизация

Обычно вы назначаете доступ с помощью групп Google и иерархии ресурсов, чтобы сделать вам будет проще управлять доступом пользователей. Но имейте в виду, что если вы предоставляете доступ к чему-либо через папку ascenstor в иерархии ресурсов, вы не можете запретить доступ ниже по течению. Поэтому вам необходимо соответствующим образом спланировать иерархию доступа.

Чтобы ответить на ваш вопрос, кто квалифицируется как "пользователь в моей организации"?, каждый может войти в систему, но по умолчанию они не могут получить доступ к каким-либо проектам, это ресурсы или API, если им не предоставлен доступ индивидуально или через группу.

Надеюсь, это немного проясняет ситуацию.

person Parth Mehta    schedule 17.12.2019
comment
Спасибо, но я боюсь, что большая часть этого пролетела у меня в голове. Я хочу только управлять тем, какие участники могут предоставлять OAuth-доступ к приложению для использования с Gmail API, но я не хочу, чтобы они могли видеть или получать доступ к проекту в облачной консоли. Какая роль наиболее подходит для этой цели? - person billynoah; 18.12.2019
comment
Вам не нужно предоставлять никаких ролей, отсутствие ролей означает отсутствие доступа. Gmail является частью семейства GSuite. Если ваш вопрос ориентирован на OAuth, то ответ Джона более уместен. Мой ответ касается того, как вы предоставляете доступ к Google Cloud Platform. - person Parth Mehta; 18.12.2019
comment
Я пробовал без роли, но, похоже, это необходимо: i.stack.imgur.com/o7mUe. png - person billynoah; 18.12.2019
comment
какие варианты доступны в раскрывающемся списке? - person Parth Mehta; 18.12.2019
comment
Их много - 2574 различных разрешения, если быть точным. Я могу создать роль клиента, но это не позволит мне создать роль без назначенных разрешений. Полагаю, я мог бы здесь сделать что-нибудь взломанное, но я бы не стал этого делать. Я не могу быть единственным человеком, которому нужно разрешить OAuth участникам, не предоставляя им доступ к облачной платформе. Вот некоторые документы: cloud.google.com/iam/docs/permissions-reference - person billynoah; 18.12.2019
comment
Вы пытаетесь создать учетную запись службы? В таком случае вы можете создать собственную роль без разрешения: stackoverflow.com/questions/55270838/. Но, читая ваше описание, кажется, что веб-приложения OAuth 2 могут быть более подходящими для ваших требований. - person Parth Mehta; 18.12.2019
comment
Нет, я так не думаю ... Я так и сказал. OAuth2 необходим для доступа к нашей электронной почте. Поэтому каждая учетная запись участника в нашей организации должна иметь возможность посещать страницу согласия, чтобы предоставить доступ. Насколько я понимаю, это означает, что мне нужно добавить их в IAM, поскольку это частное приложение. - person billynoah; 18.12.2019
comment
из вашего описания кажется, что веб-приложения OAuth 2 могут быть более подходящими для ваших требований - именно так это и настроено. - person billynoah; 18.12.2019
comment
Экран согласия Oauth 2 позволяет реализовать уровень аутентификации в ваших приложениях, но не обязательно добавлять пользователей в вашу организацию. Поскольку ваше приложение является внутренним, оно работает только с участниками вашего проекта, если вы не хотите добавлять участников, вы можете добавить роль без разрешений или сделать общедоступным экран авторизации вашего согласия. - person Jan Hernandez; 18.12.2019