Почему они выбрали токены идентификатора OIDC для обслуживания
коммуникация? Я много раз использовал OIDC на стороне пользователя, но никогда на
сервер на серверную сторону. Итак, получение идентификатора токена для сервера на сервер
общение кажется очень странным. хотелось бы ссылку на точки
документы, объясняющие этот выбор архитектуры на сервере к серверу
сторона .. Я бы ожидал, что токен доступа OAuth2 с клиентом
Учетные данные для связи между службами, а не токеном идентификатора.
В Google Cloud существует два типа авторизации. На основе ролей (маркер доступа OAuth) и на основе удостоверений (маркер идентификации OIDC). Авторизация на основе ролей обеспечивает доступ ко всем ресурсам на основе ролей. Например, доступ для просмотра ко всем экземплярам Compute Engine. Этот тип разрешений управляется на уровне проекта/папки/организации. Авторизация на основе идентификации обеспечивает доступ к отдельному ресурсу. Ключевое отличие заключается в том, где назначается разрешение/роль: на уровне проекта или на уровне ресурса. Так как роль слишком широка для разрешений на уровне ресурсов, вам нужен другой способ.Это тождества. я предоставляю Джон доступ к ключу KMS секрет2. Идентификация + разрешения хранятся на уровне управления доступом к ключу KMS.
Почему поле «Аудитория» произвольное? В облачном планировщике это
кажется, что пока я использую действующую учетную запись службы в проекте,
Я могу указать любое значение в поле аудитории? Я уверен, что есть причина
для этого люди из Google умны, но это похоже на дыру в безопасности.
Я имею в виду, что аудиторией может быть любой действительный URL-адрес (насколько я могу судить). Могу я
поместите аудиторию конечной точки Cloud Run в другой проект и сделайте
этот звонок?
Если ваш код создает токен идентификации, аудитория требуется. Существуют определенные идентификаторы клиентов OAuth, управляемые Google, которые позволяют игнорировать аудиторию. Поскольку удостоверение и разрешения хранятся в ресурсе, вызов другой конечной точки Cloud Run не пройдет проверку удостоверения. ИМХО, поле аудитории — это быстрый способ для системы идентификации сначала проверить, должен ли токен идентификации быть одобрен для уровня IAM.
Очевидно, что здесь существует разделение между AuthN и AuthZ, поэтому
id_token больше относится к authN, но поле аудитории проверяется на
запрос токена будет указывать на надежный Authz. НО при этом
произвольно, я чувствую, что проверке аудитории нельзя доверять
потому что любой может положить туда что угодно. Пожалуйста, скажи мне, что я
отсутствует.
Идентификационные токены подписаны. Только авторизованные службы и код могут создавать токены идентификации. Как я уже упоминал в предыдущем пункте, аудитория не предоставляет разрешение или доступ. Это один из этапов авторизации доступа на основе токена идентификации. Конечная проверка — это удостоверение + разрешение, назначенное ресурсу. Аудитория не предоставляет ничего из этого, но может использоваться в качестве фильтра для быстрого сброса токенов.
