Esta página se aplica à Apigee, mas não à Apigee híbrida.
A Apigee suporta autenticação e autorização baseadas no IAM para proxies de API. Com essa solução, o acesso para invocar uma API é baseado em vários fatores, incluindo se o fluxo de solicitação inclui a política VerifyIAM e se o consumidor da API tem a função ou as permissões necessárias do IAM do Google Cloud para invocar APIs da Apigee. A autorização pode ser concedida para qualquer principal do Google Cloud e não é limitada a usuários individuais.
Usar o controle de acesso baseado em IAM
Esta seção descreve o processo completo de configuração da autenticação e autorização com base no IAM, como as solicitações são avaliadas após a configuração do acesso e como revogar o acesso para consumidores da API que já tiveram acesso.
Adicionar gerenciamento de acesso
Para configurar o gerenciamento de acesso de um proxy de API:
- Adicione a política VerifyIAM ao proxy ou aos proxies da API Apigee como parte do fluxo de solicitação.
- O administrador do Cloud para o projeto do Apigee:
- Concede
o papel do IAM
deploymentInvoker
(ou um papel personalizado com a permissãoapigee.deployments.invoke
do IAM) ao principal do Google Cloud do consumidor da API no nível do projeto. Isso dá ao consumidor da API acesso para invocar todas as APIs hospedadas na organização da Apigee associada.
ou - Usa a ação
SetIamPolicy
para conceder o papel ou a permissão ao principal do Google Cloud do consumidor da API em uma implantação específica ou de forma iterativa em várias implantações. Use a operação de lista no recurso de implantação para conferir todas as implantações em um ambiente, incluindo proxies de API e fluxos compartilhados. O nome da implantação é o nome do proxy da API ou do fluxo compartilhado.
- Concede
o papel do IAM
- Direcione o consumidor da API para
gerar um token de acesso,
que será transmitido na solicitação da API Apigee para a verificação de permissão. O token
gerado precisa ter o escopo de autenticação
https://www.googleapis.com/auth/cloud-platform
.
Operações do administrador
Esta seção lista as ações que os administradores de API (produtores de API) realizam ao gerenciar permissões baseadas no IAM.
A documentação de operações baseadas em API usadas ao gerenciar o acesso baseado no IAM está disponível na documentação de referência da API
organizations.environments
e
organizations.environments.deployments
e inclui as operações SetIamPolicy
,
GetIamPolicy
, TestIamPermissions
e
GetDeployment
.
Esta tabela associa operações às permissões necessárias:
Operação do administrador | Ação | Permissão do IAM necessária | Recurso do IAM em que a permissão é necessária* |
---|---|---|---|
GetDeployment | Extrair informações de uma implantação em um ambiente da Apigee | apigee.deployments.get | Projeto do Google Cloud ou ambiente da Apigee |
ListDeployments | Listar as implantações em um ambiente da Apigee | apigee.deployments.list | Projeto ou ambiente da Apigee |
SetIamPolicy | Definir o acesso de invocação para consumidores da API em uma implantação específica | apigee.deployments.setIamPolicy | Projeto do Google Cloud ou ambiente da Apigee |
GetIamPolicy | Buscar o conjunto de configurações de acesso de invocação para uma implantação de API | apigee.deployments.getIamPolicy | Projeto do Google Cloud ou ambiente da Apigee |
TestIamPermissions | Verificar se o usuário que chama essa API tem a permissão mencionada no payload | Nenhuma permissão do IAM necessária | N/A |
Verificação de acesso no tempo de execução
Quando o consumidor da API tenta acessar uma API com controle de acesso baseado no IAM, é realizada uma verificação para saber se ele tem o token de acesso necessário e a função ou permissão adequada no nível do projeto ou da implantação. Se for o caso, o acesso ao proxy será permitido. Caso contrário, eles serão bloqueados.
Remover acesso
Para remover o acesso no nível do projeto: para remover o acesso de um consumidor de API
gerenciado no nível do projeto, o administrador do Cloud para o projeto da Apigee
revoga
o papel do IAM deploymentInvoker
(ou o papel personalizado
com a permissão apigee.deployments.invoke
) do principal do Google Cloud
do consumidor de API para o projeto do Google Cloud.
Se o acesso foi concedido para implantações individuais usando setIamPolicy
,
remova o papel ou a permissão das implantações usando outra operação setIamPolicy
.
Características e limitações do controle de acesso baseado em IAM
Observe estas características e limitações ao usar a autenticação e autorização baseadas no IAM:
- Normalmente, a execução da política com o VerifyIAM leva aproximadamente 10 milissegundos. No entanto,
algumas chamadas podem ter latências de conclusão de aproximadamente 50 ms. Por exemplo, na
região
asia-east2
especificamente, a latência média pode aumentar para 50 ms, e algumas chamadas podem levar cerca de 100 ms para serem concluídas.
Esses valores de latência não são garantidos. - A inclusão da política VerifyIAM para um proxy é uma verificação verificada/não verificada. As funções e permissões específicas do consumidor da API não são consideradas em processos posteriores no fluxo de solicitação ou resposta.
- Como uma verificação de autorização é realizada apenas no momento da execução da política VerifyIAM, ela precisa ser a primeira política no fluxo de solicitações, depois das políticas de gerenciamento de tráfego.
- Se a validação de permissão for bem-sucedida ou o produtor da API tiver marcado a política VerifyIAM para continuar em caso de erro, o fluxo de solicitação continuará a executar as outras políticas, se houver, alcançando o servidor de destino. Se a verificação de permissão falhar e o produtor da API não tiver marcado a política para continuar em caso de erro, o usuário vai receber um erro.
- Adicionar o acesso de invocação (
apigee.deployments.invoke
) no nível do ambiente não transmite o acesso de invocação em todas as implantações de API no ambiente. - As condições do IAM não são compatíveis com o recurso de implantação e não podem ser usadas para controlar o acesso de invocação. Consulte Como adicionar condições do IAM da Apigee às políticas para mais informações.
- O controle de acesso baseado em IAM oferece suporte a um máximo de 1.500 vinculações de função em uma única política e outras limitações. Consulte Cotas e limites do IAM.
- O controle de acesso baseado no IAM está sujeito a atrasos na propagação do IAM.
- A tentativa de gerenciar outras operações
apigee.deployments
, comoapigee.deployments.delete
, usando o setIAMPolicy no nível da implantação, não será eficaz, mas também não retornará um erro. Apenasapigee.deployements.invoke
é eficaz. - O acesso a uma implantação é excluído quando o proxy correspondente é desimplantado do ambiente ou excluído. O acesso precisa ser adicionado novamente na nova implantação.
- No momento, a autenticação e autorização baseadas no IAM não estão disponíveis no modo híbrido.
Exemplos
Esta seção apresenta exemplos de como conceder e revogar o acesso baseado no IAM às APIs. Esses exemplos presumem que o VerifyIAM já foi adicionado ao proxy de API apropriado.
Nestes exemplos, use o console do Cloud ou a gcloud (mostrada) para
gerenciar papéis ou permissões
no principal do Google Cloud do consumidor da API. O $Project
nos exemplos é o
projeto do Google Cloud.
Conceder e revogar o acesso do usuário para invocar todas as APIs em uma organização da Apigee
Para conceder acesso, adicione o papel deploymentInvoker
:
gcloud projects add-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'
Para revogar o acesso, remova a função deploymentInvoker
:
gcloud projects remove-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'
Conceder e revogar o acesso do usuário a implantações específicas em um ambiente
Para adicionar a função de invocação de um usuário a uma implantação específica:
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \ --header 'Authorization: Bearer $TOKEN ' \ --header 'Content-Type: application/json' \ --data '{"policy":{"bindings":[{"members":["user:$user"],"role":"roles/apigee.deploymentInvoker"}]}}'
Uma resposta de sucesso vai ser parecida com esta:
{ "version": 1, "etag": "BwYT8i40Vwo=", "bindings": [ { "role": "roles/apigee.deploymentInvoker", "members": [ "user:$user" ] } ] }
Para confirmar se o objeto de política adicionado foi mantido corretamente (opcional):
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \ --header 'Authorization: Bearer $TOKEN'
Você vai receber uma resposta de sucesso como a mostrada acima.
Para que o usuário verifique se pode acessar a implantação especificada (se a
permissão apigee.deployments.invoke
está definida para o usuário
especificado em uma implantação especificada), instrua o usuário a enviar essa solicitação usando o
token de acesso gerado anteriormente:
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \ --header 'Authorization: Bearer $TOKEN' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data '{"permissions":["apigee.deployments.invoke"]}'
A resposta precisa incluir a permissão apigee.deployments.invoke
para o usuário.
Para revogar o acesso a uma implantação específica, remova a função deploymentInvoker
. Primeiro,
acesse o objeto de política associado à implantação:
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \ --header 'Authorization: Bearer $TOKEN'
A resposta de êxito será semelhante a esta: Talvez você também veja outras vinculações.
{ "version": 1, "etag": "BwYT8i40Vwo=", "bindings": [ { "role": "roles/apigee.deploymentInvoker", "members": [ "user:$user" ] } ] }
Para remover a vinculação:
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \ --header 'Authorization: Bearer $TOKEN' \ --header 'Content-Type: application/json' \ --data '{}'
Fornecer um payload vazio remove o acesso de todos os usuários, mas é apropriado neste exemplo porque temos apenas um usuário com acesso. Ao remover o acesso de um usuário em uma circunstância em que o acesso deve continuar para outros usuários, especifique os usuários que devem continuar tendo acesso no payload, como você faria ao definir o acesso inicial para esses usuários.
Para verificar se a vinculação foi removida, verifique se a
permissão apigee.deployments.invoke
não existe para o usuário na implantação:
curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \ --header 'Authorization: Bearer $USER_TOKEN' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data '{"permissions":["apigee.deployments.invoke"]}'
Isso vai retornar uma saída vazia se nenhum usuário tiver a permissão.