Пользователи типа приложения, аутентифицирующиеся в GCP

#google-cloud-platform #oauth-2.0 #api-gateway #google-cloud-api-gateway

#google-облачная платформа #oauth-2.0 #api-шлюз #google-cloud-api-gateway

Вопрос:

Я ищу стандартный подход Oauth2.0 для пользователей типа службы, выполняющих аутентификацию в API, размещенных в среде GCP с секретами. Самое близкое, что у меня есть, — это пары service accounts ключей.

Однако я хотел бы избежать обновления ESP конфигурации каждый раз service account при добавлении нового (как в примере ниже).

  securityDefinitions:
  service-1:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "service-1@example-project-12345.iam.gserviceaccount.com"
    x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/service-1@example-project-12345.iam.gserviceaccount.com"
  service-2:
    authorizationUrl: ""
    flow: "implicit"
    type: "oauth2"
    x-google-issuer: "service-2@example-project-12345.iam.gserviceaccount.com"
    x-google-jwks_uri: "https://www.googleapis.com/robot/v1/metadata/x509/service-2@example-project-12345.iam.gserviceaccount.com"

    #should be possible to leave the addition of service-X to the end client without needing to update this.
  

РЕДАКТИРОВАТЬ: я пробовал использовать Identity Platform , и ESP конфигурация не будет нуждаться в обновлении при добавлении новых пользователей:

 securityDefinitions:
    auth0:
        authorizationUrl: ""
        flow: "implicit"
        type: "oauth2"
        x-google-issuer: "https://securetoken.google.com/{google-project-ID}"
        x-google-jwks_uri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
        x-google-audiences: "{google-project-ID}"
  

однако электронная почта / пароль не подходят для моего случая и GCP Identity Platform , похоже, не поддерживают пользователей с секретами, если я чего-то не упустил?

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

Apigee обладает всеми необходимыми функциями, однако, по-видимому, является дорогостоящим усложнением для нужд моего проекта.

Комментарии:

1. Платформа идентификации позволяет пользователям проходить аутентификацию в ваших приложениях и службах, таких как многопользовательские SaaS-приложения, мобильные / веб-приложения, игры, API и многое другое. Вы можете изучить стратегии аутентификации . Чтобы создать пользователя, вам может потребоваться изучить G-Suite, который похож на Azure AD. Можете ли вы объяснить вопрос в своих вариантах использования?

2. Мне нужно создавать пользователей с секретами (и желательно иметь возможность добавлять утверждения), а не с электронными письмами / паролями.

3. Вы можете создать секрет с помощью GCP Secret Manager

4. Как можно будет использовать секрет от Secret Manager аутентификации пользователя OAuth?

5. Похоже, эта функция в настоящее время недоступна. Я бы посоветовал вам сообщить о проблеме с помощью общедоступного средства отслеживания проблем

Ответ №1:

Это Identity-Aware Proxy обеспечивает функциональность для моего варианта использования. При добавлении учетной записи службы просто установите IAP-secured Web App User , и у нее будет доступ к защищенному ресурсу. google doc здесь

введите описание изображения здесь