Как использовать Google Identify Platform для аутентификации на облачных конечных точках?

Question

В нашей организации мы используем Google Kubernetes Engine (GKE) для реализации архитектуры микросервисов. Поскольку мы также являемся пользователями G-Suite, каждому в организации гарантированно предоставляется аккаунт Google. Следовательно, мы хотели бы использовать эти учетные записи для управления аутентификацией и авторизацией микро сервисов.

У нас есть прототип входа в систему с использованием клиента angularfire2 для аутентификации на Google Identity Platform. У нас также настроены конечные точки Google Cloud для контроля доступа к соответствующим службам.

Мы упускаем часть того, как перейти от удостоверения в Google к токену доступа, который мы можем использовать в наших сервисах - к токену доступа, возвращающемуся с помощью Firebase API, претензий нет, и документация по пользовательским утверждениям , кажется, ясно дает понять, что они входят в маркер идентификации.

Я ожидаю, что у JWT будет соответствующая аудитория (наша бэкэнд), содержащая достаточный набор заявок для реализации контроля доступа на основе ролей в сервисах. В идеале инфраструктура могла бы уже подтвердить претензию - некоторые из наших сервисов достаточно малы, чтобы требовать только одну роль, которую можно было бы применить за пределами сервиса. Или мы можем аннотировать наши конечные точки (Protobuf) требуемыми утверждениями.

Каков стандартный процесс создания маркеров доступа, который будет использоваться для доступа к службам GKE, в среде GCP? Есть ли что-нибудь, что поддерживает это?

Answer 1

Кусок, который нам не хватает, - это как получить личность в Google, чтобы токен доступа, который мы можем использовать в наших сервисах - токен доступа назад использование Firebase API не имеет претензий и документации на таможенные претензии, кажется, совершенно ясно, что они идут в идентификационный токен.

Токены доступа Google OAuth не имеют идентификаторов в том смысле, что вы хотите их использовать. Идентификационные данные хранятся в токене. Добавьте область «электронная почта» при аутентификации пользователя. Google вернет идентификационный токен. Для некоторых платформ вы можете запросить пользовательские утверждения для Identity Token.

В среде GCP, каков стандартный процесс создания маркеры доступа, которые будут использоваться для доступа к сервисам GKE? Есть что-нибудь что поддерживает это?

Существует два типа доступа, исключая такие методы, как ключи API. Аккаунты пользователей и сервисные аккаунты. Сервис-сервис обычно использует токены доступа учетной записи службы (RBAC) или токены идентификации учетной записи службы (IBAC). В вашем случае вы хотите использовать Identity Platform, что означает учетные записи пользователей.

Если бы я проектировал эту систему, я бы использовал учетные записи пользователей для аутентификации в системе - Firebase отлично подходит для этой цели. Я бы посмотрел, какие роли поддерживает / разрешает это удостоверение, из моей базы данных (Firestore) и создаю токен доступа учетной записи службы с необходимыми областями для служб GCP. Затем я бы использовал этот токен доступа для авторизации между сервисами GCP. Если бы мне также требовались настраиваемые роли для моих собственных служб, я бы создал настраиваемый токен идентификации с моими настраиваемыми ролями, включил его в качестве настраиваемого заголовка HTTP и включил токен доступа Google в стандартный заголовок HTTP «authorization: bearer». Я бы использовал закрытый ключ учетной записи службы для подписи своего пользовательского токена идентификации или API GCP IAM для своей подписи, чтобы другой конец мог проверить с помощью открытого ключа учетной записи службы. Этот метод предотвращает утечку данных на клиенте, закрытые ключи не раздаются, области / роли не раскрываются и т. Д.

Answer 2

Я бы посоветовал вам следовать этой doc аутентификации между службами с использованием файлов учетных записей служб.