É possível usar o Workflows para invocar um endpoint em que o Identity-Aware Proxy (IAP) foi ativado. O endpoint pode ser um local, do Compute Engine, do Google Kubernetes Engine (GKE) ou outro Google Cloud endpoint.
O IAP verifica a identidade e aplica a autorização no nível do aplicativo. Assim, é possível usar um modelo de controle de acesso no nível do aplicativo em vez de depender de firewalls no nível da rede. Quando um aplicativo ou recurso é protegido pelo IAP, ele só pode ser acessado por meio do proxy por principais que têm o papel correto do Identity and Access Management (IAM).
Para mais informações, consulte a visão geral do IAP e os seguintes guias:
- Ativar o IAP para o App Engine
- Ativar o IAP para o Cloud Run
- Ativar o IAP para o Compute Engine
- Ativar o IAP para GKE
- Ativar o IAP para apps locais
Fazer uma solicitação HTTP
Para chamar ou invocar um endpoint dos Workflows, é necessário fazer uma solicitação
HTTP. Os métodos de solicitação HTTP mais comuns têm um atalho
de chamada (como http.get e
http.post), mas é possível fazer qualquer
tipo de solicitação HTTP definindo o campo call como http.request e
especificando o tipo de solicitação usando o campo method. Para mais informações,
consulte Fazer uma solicitação HTTP.
Usar uma conta de serviço com as permissões necessárias
Ao fazer solicitações a outros serviços do Google Cloud , seu fluxo de trabalho precisa estar associado a uma conta de serviço que tenha recebido um ou mais papéis do Identity and Access Management (IAM) com as permissões necessárias para acessar os recursos solicitados. Para saber qual conta de serviço está associada a um fluxo de trabalho atual, consulte Verificar a conta de serviço associada a um fluxo de trabalho.
Ao configurar uma conta de serviço, você associa a identidade do solicitante ao recurso a que você quer conceder acesso. A identidade do solicitante é transformada em um principal, ou usuário, do recurso e, em seguida, o papel apropriado é atribuído. O papel define quais permissões a identidade tem no contexto do recurso. Quando um aplicativo ou recurso é protegido pelo IAP, ele só pode ser acessado por meio do proxy por principais que têm a função correta.
Por exemplo, após a autenticação, o IAP aplica a política de permissão relevante para verificar se o principal está autorizado a acessar o recurso solicitado. Se o principal tiver o papel Usuário do app da Web protegido pelo IAP
(roles/iap.httpsResourceAccessor) no projeto do console Google Cloud
em que o recurso existe, ele estará autorizado a acessar o aplicativo.
É possível configurar o acesso ao recurso protegido pelo IAP na página do IAP adicionando a conta de serviço do Workflows como uma principal. Para mais informações, consulte Como gerenciar o acesso a recursos protegidos pelo IAP.
Adicionar informações de autenticação ao fluxo de trabalho
Por padrão, as solicitações HTTP não contêm tokens de identidade ou acesso por motivos de segurança. É necessário adicionar as informações de autenticação à definição do fluxo de trabalho explicitamente. Ao fazer solicitações para um endpoint, use o OIDC para autenticar pelo IAP.
Para fazer uma solicitação HTTP usando o OIDC, adicione uma seção auth à seção args
da definição do fluxo de trabalho, depois de especificar o URL.
YAML
- step_A: call: http.get args: url: https://www.example.com/endpoint body: someValue: "Hello World" anotherValue: 123 auth: type: OIDC audience: OIDC_AUDIENCE
JSON
[ { "step_A": { "call": "http.get", "args": { "url": "https://www.example.com/endpoint", "body": { "someValue": "Hello World", "anotherValue": 123 }, "auth": { "type": "OIDC", "audience": "OIDC_AUDIENCE" } } } } ]
É possível usar o parâmetro audience para especificar o público-alvo do OIDC para o token.
Ao invocar um endpoint ativado para IAP, especifique o
ID do cliente OAuth 2.0 configurado para seu aplicativo. Isso pode ser
obtido na página "Credenciais".
A seguir
- Conceder permissão a um fluxo de trabalho para acessar recursos do Google Cloud
- Acessar dados de resposta HTTP salvos em uma variável
- Invocar um endpoint particular usando o registro de serviço do Service Directory