As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Usando a política de permissões verificadas da Amazon, armazene aliases em operações de API
Qualquer operação de permissões verificadas da Amazon que aceite um policyStoreId parâmetro, como IsAuthorized, e IsAuthorizedWithToken GetPolicyStore, pode aceitar um nome de alias de armazenamento de políticas no lugar do ID do armazenamento de políticas.
Importante
Ao usar um alias de armazenamento de políticas como o valor de um policyStoreId parâmetro, você deve incluir o policy-store-alias/ prefixo. Por exemplo, usepolicy-store-alias/example-policy-store, nãoexample-policy-store.
Usando aliases do Policy Store em operações
O IsAuthorized comando a seguir usa um alias de armazenamento de políticas com o nome example-policy-store para identificar um repositório de políticas.
nota
Você não pode usar um alias de armazenamento de políticas no lugar do policyStoreId campo para a DeletePolicyStore operação.
Usando aliases do Policy Store Across Regiões da AWS
Um dos usos mais poderosos dos aliases é em aplicações executadas em várias Regiões da AWS. Por exemplo, você pode ter um aplicativo global que usa diferentes repositórios de políticas em cada região.
-
Em us-east-1, você deseja usar.
PSEXAMPLEabcdefg111111 -
Em eu-west-1, você deseja usar.
PSEXAMPLEabcdefg222222
Você pode criar uma versão diferente do seu aplicativo em cada região ou usar um dicionário ou uma instrução switch para selecionar o repositório de políticas certo para cada região. Mas é muito mais fácil criar um alias de armazenamento de políticas com o mesmo nome de alias de armazenamento de políticas em cada região. Lembre-se de que o nome do alias do repositório de políticas diferencia maiúsculas de minúsculas.
Em seguida, use o alias do repositório de políticas em seu código. Quando seu código é executado em cada região, o alias do repositório de políticas se referirá ao repositório de políticas associado nessa região.
No entanto, existe o risco de que o alias do repositório de políticas seja excluído. Nesse caso, as tentativas do aplicativo de usar o nome do alias do repositório de políticas falharão e talvez seja necessário recriar ou atualizar o alias do repositório de políticas. Para reduzir esse risco, tenha cuidado ao conceder permissão aos diretores para gerenciar os aliases do repositório de políticas que você usa em seu aplicativo.
Os aliases do repositório de políticas não são um mecanismo de controle de tráfego
Um alias de armazenamento de políticas é um nome estável e amigável para um repositório de políticas. Não é um mecanismo para transferir, dividir ou ponderar o tráfego de autorização entre repositórios de políticas. Se você estiver familiarizado com os recursos que direcionam o tráfego entre as versões de um recurso, como aliases do Lambda, observe que os aliases do repositório de políticas não se comportam da mesma maneira. Por design, um alias de armazenamento de políticas está mais próximo de um alias de AWS KMS chave: ele fornece um nome durável para um recurso, não uma camada de roteamento na frente dele.
Por esse motivo, intencionalmente não fornecemos uma UpdatePolicyStoreAlias operação. Para alterar o repositório de políticas para o qual um alias de armazenamento de políticas aponta, você exclui o alias do armazenamento de políticas e cria um novo alias de armazenamento de políticas que tenha o mesmo nome e tenha como alvo um repositório de políticas diferente. Essa não é uma operação atômica e não oferece as garantias que um mecanismo de controle de tráfego forneceria.
Quando você altera o repositório de políticas para o qual um alias de armazenamento de políticas resolve, a alteração não entra em vigor em todos os lugares no mesmo instante:
-
O mapeamento atualizado deve se propagar do plano de controle para o plano de dados que avalia as solicitações de autorização. O mapeamento não se propaga instantaneamente.
-
Como a resolução de alias do repositório de políticas é eventualmente consistente e pode ser armazenada em cache, existe uma janela de transição após uma alteração. Durante essa janela, o repositório de políticas associado anteriormente atende a algumas solicitações e o repositório de políticas recém-associado atende a outras solicitações. O comprimento dessa janela é indeterminado.
Durante essa janela, seu aplicativo pode receber decisões de autorização de qualquer repositório de políticas. Como diferentes repositórios de políticas podem conter políticas, entidades e esquemas diferentes, a mesma solicitação pode produzir decisões diferentes, dependendo de qual repositório de políticas a atende. Os aliases do repositório de políticas, portanto, não podem fornecer uma transição atômica entre os repositórios de políticas e não substituem uma estratégia de implantação ou gerenciamento de tráfego.
Não use aliases como mecanismo de substituição
Não crie uma infraestrutura como código ou uma primitiva de implantação de alto nível que redirecione um alias de armazenamento de políticas para alternar o tráfego de autorização de um repositório de políticas para outro. Como a alteração não é atômica, as solicitações podem ser autorizadas nos dois repositórios de políticas ao mesmo tempo por um período indeterminado. Isso pode levar a decisões de autorização inconsistentes. Para alternar os repositórios de políticas com segurança, consulteRealizando alterações no repositório de políticas sem tempo de inatividade.
Realizando alterações no repositório de políticas sem tempo de inatividade
Como os aliases do repositório de políticas não fornecem uma transferência atômica (consulteOs aliases do repositório de políticas não são um mecanismo de controle de tráfego), recomendamos que você evite migrar de um repositório de políticas para outro reposicionando um alias do repositório de políticas. Em vez disso, controle a migração de dentro do seu aplicativo para que você possa validar o novo repositório de políticas e reverter instantaneamente, se necessário. A abordagem a seguir permite que você alterne os repositórios de políticas sem tempo de inatividade:
-
Crie o novo repositório de políticas e dê a ele seu próprio alias de armazenamento de políticas, para que o repositório de políticas atual e o novo repositório de políticas tenham um nome distinto e estável. Por exemplo, continue
policy-store-alias/example-policy-storeapontando para seu repositório de políticas atual e criepolicy-store-alias/example-policy-store-2para o novo repositório de políticas. Não reutilize nem reaponte um único alias de armazenamento de políticas para realizar a troca. -
Replique suas políticas, esquemas e qualquer outra configuração no novo repositório de políticas e execute-os em paralelo com o armazenamento de políticas atual.
-
Adicione um valor de configuração ou sinalizador de recurso ao seu aplicativo (por exemplo, usando AppConfig) que determine qual alias de armazenamento de políticas é autoritário para decisões de autorização. Não confie na alteração do alias em si para alternar o tráfego.
-
Execute o novo repositório de políticas no modo sombra. Envie o mesmo
IsAuthorizedouIsAuthorizedWithTokensolicite para os dois repositórios de políticas e compare as decisões. Registre e investigue quaisquer discrepâncias até que o novo repositório de políticas retorne as decisões que você espera. -
Use o sinalizador de recurso para transferir gradualmente as decisões de autorização para o novo alias do repositório de políticas, por exemplo, em uma distribuição em fases em seus hosts de aplicativos ou segmentos de usuários. Monitore as decisões de autorização e as taxas de erro à medida que você prossegue.
-
Use o sinalizador de recurso para voltar imediatamente ao alias original do repositório de políticas se você detectar um problema. Como seu aplicativo controla o switch, a reversão é instantânea e não depende da propagação do alias.
-
Desative o antigo repositório de políticas e seu alias do repositório de políticas depois que o novo repositório de políticas estiver totalmente validado e atender a todo o tráfego.
Esse padrão dá ao seu aplicativo, em vez da propagação de aliases, o controle sobre qual repositório de políticas atende a cada solicitação. Esse controle é o que torna a migração segura e reversível e evita a janela de transição que o reposicionamento de um alias de armazenamento de políticas introduziria.
