Ajudar a melhorar esta página
Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.
Se estiver usando uma conta de serviço do Kubernetes com perfis de IAM para contas de serviço, você poderá configurar o tipo de endpoint do AWS Security Token Service usado pela conta de serviço se o cluster e a versão da plataforma forem iguais ou posteriores aos listados na tabela a seguir. Se a versão do Kubernetes ou da plataforma for anterior às listadas na tabela, as contas de serviço só poderão usar o endpoint global.
Versão do Kubernetes | Versão da plataforma | Tipo de endpoint padrão |
---|---|---|
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
|
|
Regional |
A AWS recomenda usar os endpoints regionais do AWS STS em vez do endpoint global. Isso reduz a latência, fornece redundância integrada e aumenta a validade do token da sessão. O AWS Security Token Service deve estar ativo na região da AWS onde o pod está sendo executado. Além disso, sua aplicação deve ter redundância integrada para uma região da AWS diferente no caso de uma falha do serviço na região AWS. Para obter mais informações, consulte Gerenciar o AWS STS em uma região da AWS, no Guia do usuário do IAM.
-
Um cluster existente. Se não tiver um, você poderá criá-lo usando um dos guias em Começar a usar o Amazon EKS.
-
Um provedor de OIDC do IAM existente para o cluster. Para ter mais informações, consulte Criar um provedor de identidade OIDC do IAM para o cluster.
-
Uma conta de serviço existente do Kubernetes configurada para uso com o recurso Amazon EKS IAM para contas de serviço.
Todos os exemplos a seguir usam a conta de serviço aws-node do Kubernetes usada pelo plug-in CNI da Amazon VPC. É possível substituir os valores de exemplo
pelas suas próprias contas de serviço, pods, namespaces e outros recursos.
-
Selecione um pod que use uma conta de serviço para a qual você deseja alterar o endpoint. Determine em qual região da AWS o pod é executado. Substitua
aws-node-6mfgv
pelo nome do pod ekube-system
pelo namespace do seu pod.kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
Veja um exemplo de saída abaixo.
ip-192-168-79-166.us-west-2/192.168.79.166
Na saída anterior, o pod está sendo executado em um nó na região us-west-2 da AWS.
-
Determine o tipo de endpoint que a conta de serviço do pod estará usando.
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
Veja um exemplo de saída abaixo.
AWS_STS_REGIONAL_ENDPOINTS: regional
Se o endpoint atual for global,
global
será retornado na saída. Se nenhuma saída for retornada, significa que tipo de endpoint padrão está em uso e não foi substituído. -
Se a versão do cluster ou plataforma for a mesma ou posterior à da tabela, você poderá alterar o tipo de endpoint utilizado pela conta de serviço do tipo padrão para um tipo diferente, usando um dos comandos a seguir. Substitua
aws-node
pelo nome da conta de serviço eaws-node
pelo namespace da sua conta de serviço.-
Se o tipo de endpoint padrão ou atual for global e você quiser modificá-lo para regional:
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
Se você estiver usando perfis do IAM para contas de serviço para gerar URLs do S3 pré-assinados na aplicação em execução em contêineres de pods, o formato do URL para endpoints regionais será semelhante ao seguinte exemplo:
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
-
Se o tipo de endpoint padrão ou atual for global, e você quiser modificá-lo para regional:
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
Se a sua aplicação estiver fazendo solicitações explicitamente para endpoints globais do AWS STS e você não substituir o comportamento padrão de usar endpoints regionais em clusters do Amazon EKS, as solicitações falharão com um erro. Para ter mais informações, consulte Os contêineres do pod recebem o seguinte erro: An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region.
Se você estiver usando perfis do IAM para contas de serviço para gerar URLs do S3 pré-assinados na sua aplicação em execução em contêineres de pods, o formato do URL para endpoints globais será semelhante ao seguinte exemplo:
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
Se você tem uma automação que espera o URL pré-assinado em um determinado formato ou se a sua aplicação ou dependências downstream que usam URLs pré-assinados têm expectativas para a região da AWS visada, faça as alterações necessárias para usar o endpoint do AWS STS apropriado.
-
-
Exclua e recrie os pods existentes associados à conta de serviço para aplicar as variáveis de credenciais do ambiente. O webhook de mutação não as aplica aos pods que já estão em execução. É possível substituir
pods
,kube-system
e-l k8s-app=aws-node
pelas informações dos pods para os quais você definiu sua anotação.kubectl delete Pods -n kube-system -l k8s-app=aws-node
-
Verifique se todos os pods foram reiniciados.
kubectl get Pods -n kube-system -l k8s-app=aws-node
-
Visualize as variáveis de ambiente de um dos pods. Verifique se o valor
AWS_STS_REGIONAL_ENDPOINTS
é o que você o definiu em uma etapa anterior.kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
Veja um exemplo de saída abaixo.
AWS_STS_REGIONAL_ENDPOINTS=regional