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á.

Gerenciamento de Identidade e Acesso

O Identity and Access Management (IAM) é um serviço da AWS que executa duas funções essenciais: Autenticação e Autorização. A autenticação envolve a verificação de uma identidade, enquanto a autorização rege as ações que podem ser executadas pelos recursos da AWS. Dentro da AWS, um recurso pode ser outro serviço da AWS, por exemplo EC2, ou um diretor da AWS, como um usuário ou função do IAM. As regras que regem as ações que um recurso pode realizar são expressas como políticas do IAM.

Controlando o acesso aos clusters EKS

O projeto Kubernetes oferece suporte a uma variedade de estratégias diferentes para autenticar solicitações no serviço kube-apiserver, por exemplo, Bearer Tokens, certificados X.509, OIDC etc. Atualmente, o EKS tem suporte nativo para autenticação de token de webhook, tokens de conta de serviço e, a partir de 21 de fevereiro de 2021, autenticação OIDC.

A estratégia de autenticação do webhook chama um webhook que verifica os tokens do portador. No EKS, esses tokens portadores são gerados pela AWS CLI ou pelo cliente quando você aws-iam-authenticatorkubectlexecuta comandos. Conforme você executa os comandos, o token é passado para o kube-apiserver, que o encaminha para o webhook de autenticação. Se a solicitação for bem formada, o webhook chamará uma URL pré-assinada incorporada no corpo do token. Esse URL valida a assinatura da solicitação e retorna informações sobre o usuário, por exemplo, a conta do usuário, Arn, e UserId para o kube-apiserver.

Para gerar manualmente um token de autenticação, digite o seguinte comando em uma janela do terminal:

aws eks get-token --cluster-name <cluster_name>

Você também pode obter um token programaticamente. Abaixo está um exemplo escrito em Go:

package main

import (
  "fmt"
  "log"
  "sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main()  {
  g, _ := token.NewGenerator(false, false)
  tk, err := g.Get("<cluster_name>")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(tk)
}

A saída deve ser semelhante a esta:

{
  "kind": "ExecCredential",
  "apiVersion": "client.authentication.k8s.io/v1alpha1",
  "spec": {},
  "status": {
    "expirationTimestamp": "2020-02-19T16:08:27Z",
    "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz"
  }
}

Cada token começa com k8s-aws-v1. seguido por uma string codificada em base64. A string, quando decodificada, deve se parecer com algo parecido com isso:

https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393

O token consiste em uma URL pré-assinada que inclui uma credencial e uma assinatura da Amazon. Para obter detalhes adicionais, consulte https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.

O token tem um tempo de vida (TTL) de 15 minutos, após o qual um novo token precisará ser gerado. Isso é tratado automaticamente quando você usa um clientekubectl, como, no entanto, se você estiver usando o painel do Kubernetes, precisará gerar um novo token e se autenticar novamente sempre que o token expirar.

Depois que a identidade do usuário é autenticada pelo serviço AWS IAM, o kube-apiserver lê o aws-auth ConfigMap no kube-system namespace para determinar o grupo RBAC a ser associado ao usuário. O aws-auth ConfigMap é usado para criar um mapeamento estático entre os principais do IAM, ou seja, usuários e funções do IAM e grupos RBAC do Kubernetes. Os grupos RBAC podem ser referenciados no Kubernetes ou. RoleBindings ClusterRoleBindings Eles são semelhantes aos papéis do IAM, pois definem um conjunto de ações (verbos) que podem ser executadas em uma coleção de recursos (objetos) do Kubernetes.

Gerenciador de acesso ao cluster

O Cluster Access Manager, agora a forma preferida de gerenciar o acesso dos diretores do AWS IAM aos clusters do Amazon EKS, é uma funcionalidade da API da AWS e é um recurso opcional para clusters do EKS v1.23 e posteriores (novos ou existentes). Ele simplifica o mapeamento de identidade entre o AWS IAM e o KubernetesRBACs, eliminando a necessidade de alternar entre a AWS e o Kubernetes APIs ou editá-los aws-auth ConfigMap para gerenciamento de acesso, reduzindo a sobrecarga operacional e ajudando a resolver configurações incorretas. A ferramenta também permite que os administradores do cluster revoguem ou refinem cluster-admin as permissões concedidas automaticamente ao principal do AWS IAM usadas para criar o cluster.

Essa API se baseia em dois conceitos:

No lançamento, o Amazon EKS suporta somente políticas predefinidas e gerenciadas pela AWS. As políticas de acesso não são entidades do IAM e são definidas e gerenciadas pelo Amazon EKS.

O Cluster Access Manager permite a combinação do RBAC upstream com políticas de acesso que permitem e aprovam (mas não negam) as decisões do Kubernetes AuthZ em relação às solicitações do servidor de API. Uma decisão de negação ocorrerá quando os autorizadores do RBAC upstream e do Amazon EKS não conseguirem determinar o resultado da avaliação de uma solicitação.

Com esse recurso, o Amazon EKS oferece suporte a três modos de autenticação:

Para começar, os administradores de cluster podem criar ou atualizar clusters do Amazon EKS, definindo a autenticação API_AND_CONFIG_MAP ou o API método preferido e definindo entradas de acesso para conceder acesso aos principais do AWS IAM desejados.

$ aws eks create-cluster \
    --name <CLUSTER_NAME> \
    --role-arn <CLUSTER_ROLE_ARN> \
    --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
    --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false

O comando acima é um exemplo para criar um cluster Amazon EKS sem as permissões de administrador do criador do cluster.

É possível atualizar a configuração de clusters do Amazon EKS para ativar o API AuthenticationMode usando o update-cluster-config comando. Para fazer isso em clusters existentes, CONFIG_MAP você precisará primeiro atualizar para API_AND_CONFIG_MAP e depois para. API Essas operações não podem ser revertidas, o que significa que não é possível alternar de API para API_AND_CONFIG_MAP ou CONFIG_MAP e também de API_AND_CONFIG_MAP paraCONFIG_MAP.

$ aws eks update-cluster-config \
    --name <CLUSTER_NAME> \
    --access-config authenticationMode=API

A API suporta comandos para adicionar e revogar o acesso ao cluster, bem como validar as políticas de acesso e entradas de acesso existentes para o cluster especificado. As políticas padrão são criadas para corresponder ao Kubernetes RBACs da seguinte maneira.

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

Nenhuma entrada de acesso está disponível quando o cluster é criado sem a permissão de administrador do criador do cluster, que é a única entrada criada por padrão.

O aws-auth ConfigMap (obsoleto)

Uma forma pela qual a integração do Kubernetes com a autenticação da AWS pode ser feita é por meio do aws-auth ConfigMap, que reside no Namespace. kube-system Ela é responsável por mapear a autenticação de identidades (usuários, grupos e funções) do AWS IAM para a autorização de controle de acesso baseado em funções (RBAC) do Kubernetes. O aws-auth ConfigMap é criado automaticamente em seu cluster Amazon EKS durante a fase de provisionamento. Ele foi criado inicialmente para permitir que os nós se juntassem ao seu cluster, mas, conforme mencionado, você também pode usá-lo ConfigMap para adicionar RBACs acesso aos principais do IAM.

Para verificar o do seu cluster aws-auth ConfigMap, você pode usar o comando a seguir.

kubectl -n kube-system get configmap aws-auth -o yaml

Este é um exemplo de uma configuração padrão do aws-authConfigMap.

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID>
      username: system:node:{{SessionName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2023-10-22T18:19:30Z"
  name: aws-auth
  namespace: kube-system

A sessão principal desta ConfigMap, está abaixo data do mapRoles bloco, que é composto basicamente por 3 parâmetros.

Também é possível mapear permissões para usuários do AWS IAM, definindo um novo bloco de configuração paramapUsers, abaixo data de aws-authConfigMap, substituir o parâmetro rolearn por userarn. No entanto, como melhor prática, é sempre recomendável que o usuário seja substituído. mapRoles

Para gerenciar permissões, você pode editar a aws-auth ConfigMap adição ou remoção do acesso ao seu cluster Amazon EKS. Embora seja possível editá-los aws-auth ConfigMap manualmente, é recomendável usar ferramentas comoeksctl, já que essa é uma configuração muito sensível, e uma configuração imprecisa pode bloquear você fora do seu cluster Amazon EKS. Consulte a subseção Usar ferramentas para fazer alterações no aws-auth ConfigMap abaixo para obter mais detalhes.

Recomendações de acesso ao cluster

Torne o EKS Cluster Endpoint privado

Por padrão, quando você provisiona um cluster EKS, o endpoint do cluster da API é definido como público, ou seja, ele pode ser acessado pela Internet. Apesar de ser acessível pela Internet, o endpoint ainda é considerado seguro porque exige que todas as solicitações de API sejam autenticadas pelo IAM e depois autorizadas pelo Kubernetes RBAC. Dito isso, se sua política de segurança corporativa exigir que você restrinja o acesso à API pela Internet ou impeça o roteamento do tráfego para fora do cluster VPC, você pode:

Não use um token de conta de serviço para autenticação

Um token de conta de serviço é uma credencial estática de longa duração. Se ele for comprometido, perdido ou roubado, um invasor poderá realizar todas as ações associadas a esse token até que a conta de serviço seja excluída. Às vezes, talvez seja necessário conceder uma exceção para aplicativos que precisam consumir a API Kubernetes de fora do cluster, por exemplo, um aplicativo de pipeline de CI/CD. Se esses aplicativos forem executados na infraestrutura da AWS, como EC2 instâncias, considere usar um perfil de instância e mapeá-lo para uma função RBAC do Kubernetes.

Empregue o acesso menos privilegiado aos recursos da AWS

Um usuário do IAM não precisa ter privilégios atribuídos aos recursos da AWS para acessar a API do Kubernetes. Se você precisar conceder a um usuário do IAM acesso a um cluster EKS, crie uma entrada aws-auth ConfigMap para esse usuário que mapeie para um grupo RBAC específico do Kubernetes.

Remova as permissões de administrador do cluster do criador do cluster

Por padrão, os clusters do Amazon EKS são criados com uma cluster-admin permissão permanente vinculada ao principal criador do cluster. Com a API Cluster Access Manager, é possível criar clusters sem essa configuração de permissãofalse, --access-config bootstrapClusterCreatorAdminPermissions ao usar API_AND_CONFIG_MAP nosso modo de API autenticação. Revogar esse acesso é considerado uma prática recomendada para evitar alterações indesejadas na configuração do cluster. O processo para revogar esse acesso segue o mesmo processo para revogar qualquer outro acesso ao cluster.

A API oferece flexibilidade para dissociar apenas um principal do IAM de uma política de acesso, neste caso o. AmazonEKSClusterAdminPolicy

$ aws eks list-associated-access-policies \
    --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN. \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Ou remover completamente a entrada de acesso associada à cluster-admin permissão.

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

$ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

Esse acesso pode ser concedido novamente, se necessário, durante um cenário de incidente, emergência ou quebra de vidro em que o cluster esteja inacessível.

Se o cluster ainda estiver configurado com o método de CONFIG_MAP autenticação, todos os usuários adicionais deverão ter acesso ao cluster por meio da função atribuída à entidade que criou o cluster. Depois aws-auth ConfigMap de configurada, a função atribuída à entidade que criou o cluster poderá ser excluída e recriada somente em caso de incidente, emergência ou cenário de quebra de vidro, ou quando ela aws-auth ConfigMap estiver corrompida e o cluster estiver inacessível. aws-auth ConfigMap Isso pode ser particularmente útil em clusters de produção.

Use funções do IAM quando vários usuários precisarem de acesso idêntico ao cluster

Em vez de criar uma entrada para cada usuário individual do IAM, permita que esses usuários assumam uma função do IAM e mapeiem essa função para um grupo RBAC do Kubernetes. Isso será mais fácil de manter, especialmente à medida que o número de usuários que precisam de acesso aumentar.

Se ainda estiver usando o aws-auth ConfigMap como método de autenticação, ao atribuir permissões RBAC do K8s a uma função do IAM, você deve incluir\ {{}} em seu nome de usuário. SessionName Dessa forma, o registro de auditoria registrará o nome da sessão para que você possa acompanhar quem o usuário real assume essa função junto com o CloudTrail registro.

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

Empregue o acesso menos privilegiado ao criar e RoleBindings ClusterRoleBindings

Como no ponto anterior sobre a concessão de acesso aos recursos da AWS, RoleBindings ClusterRoleBindings deve incluir apenas o conjunto de permissões necessárias para realizar uma função específica. Evite usar ["*"] em suas funções, a ClusterRoles menos que seja absolutamente necessário. Se você não tiver certeza de quais permissões atribuir, considere usar uma ferramenta como audit2rbac para gerar automaticamente funções e vinculações com base nas chamadas de API observadas no registro de auditoria do Kubernetes.

Crie um cluster usando um processo automatizado

Conforme visto nas etapas anteriores, ao criar um cluster Amazon EKS, se não estiver usando o modo de uso API_AND_CONFIG_MAP ou API autenticação e não optar por não delegar cluster-admin permissões ao criador do cluster, o usuário ou a função da entidade IAM, como um usuário federado que cria o cluster, recebe automaticamente system:masters permissões na configuração RBAC do cluster. Mesmo sendo uma prática recomendada remover essa permissão, conforme descrito aqui, se você usar o método de CONFIG_MAP autenticação, confie nele aws-auth ConfigMap, esse acesso não pode ser revogado. Portanto, é uma boa ideia criar o cluster com um pipeline de automação de infraestrutura vinculado à função dedicada do IAM, sem permissões a serem assumidas por outros usuários ou entidades, e auditar regularmente as permissões e políticas dessa função e quem tem acesso para acionar o pipeline. Além disso, essa função não deve ser usada para realizar ações rotineiras no cluster e ser usada exclusivamente para ações em nível de cluster acionadas pelo pipeline, por meio de alterações no código SCM, por exemplo.

Crie o cluster com uma função IAM dedicada

Quando você cria um cluster Amazon EKS, o usuário ou a função da entidade IAM, como um usuário federado que cria o cluster, recebe automaticamente system:masters permissões na configuração RBAC do cluster. Esse acesso não pode ser removido e não é gerenciado por meio do aws-auth ConfigMap. Portanto, é uma boa ideia criar o cluster com uma função dedicada do IAM e auditar regularmente quem pode assumir essa função. Essa função não deve ser usada para realizar ações rotineiras no cluster e, em vez disso, usuários adicionais devem ter acesso ao cluster por meio do aws-auth ConfigMap para essa finalidade. Depois de aws-auth ConfigMap configurada, a função deve ser protegida e usada somente no modo temporário de privilégios elevados /break glass para cenários em que o cluster esteja inacessível de outra forma. Isso pode ser particularmente útil em clusters que não têm o acesso direto do usuário configurado.

Audite regularmente o acesso ao cluster

Quem precisa de acesso provavelmente mudará com o tempo. Planeje auditar periodicamente o aws-auth ConfigMap para ver a quem foi concedido acesso e os direitos que lhes foram atribuídos. Você também pode usar ferramentas de código aberto kubectl-who-can, como rbac-lookup, para examinar as funções vinculadas a uma conta de serviço, usuário ou grupo específico. Exploraremos esse tópico mais detalhadamente quando chegarmos à seção sobre auditoria. Ideias adicionais podem ser encontradas neste artigo do NCC Group.

Se estiver confiando no aws-auth ConfigMap, use ferramentas para fazer alterações

Um aws-auth formatado incorretamente ConfigMap pode fazer com que você perca o acesso ao cluster. Se você precisar fazer alterações no ConfigMap, use uma ferramenta.

eksctl A eksctl CLI inclui um comando para adicionar mapeamentos de identidade ao aws-auth. ConfigMap

Veja a ajuda da CLI:

$ eksctl create iamidentitymapping --help
...

Verifique as identidades mapeadas para o seu cluster Amazon EKS.

$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION
ARN                                                                   USERNAME                        GROUPS                                                  ACCOUNT
arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID>      system:node:{{SessionName}}     system:bootstrappers,system:nodes,system:node-proxier

Transforme uma função do IAM em administrador de cluster:

$ eksctl create iamidentitymapping --cluster  <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin
...

Para obter mais informações, revise os eksctldocumentos

aws-auth por keikoproj

aws-authby keikoproj inclui uma biblioteca cli e uma biblioteca go.

Baixe e veja a ajuda da CLI de ajuda:

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

Como alternativa, instale aws-auth com o gerenciador de plug-ins krew para kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Consulte a documentação do aws-auth em GitHub para obter mais informações, incluindo a biblioteca go.

CLI do AWS IAM Authenticator

O aws-iam-authenticator projeto inclui uma CLI para atualizar o. ConfigMap

Baixe uma versão em GitHub.

Adicione permissões de cluster a uma função do IAM:

$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config
...

Abordagens alternativas para autenticação e gerenciamento de acesso

Embora o IAM seja a forma preferida de autenticar usuários que precisam acessar um cluster EKS, é possível usar um provedor de identidade OIDC, como GitHub usar um proxy de autenticação e a representação do Kubernetes. Publicações sobre duas dessas soluções foram publicadas no blog de código aberto da AWS:

Você também pode usar o AWS SSO para federar a AWS com um provedor de identidade externo, por exemplo, Azure AD. Se você decidir usar isso, a AWS CLI v2.0 inclui uma opção para criar um perfil nomeado que facilita a associação de uma sessão de SSO à sua sessão atual da CLI e a assunção de uma função do IAM. Saiba que você deve assumir uma função antes de executar, kubectl pois a função do IAM é usada para determinar o grupo RBAC do Kubernetes do usuário.

Identidades e credenciais para pods EKS

Certos aplicativos executados em um cluster Kubernetes precisam de permissão para chamar a API Kubernetes para funcionar corretamente. Por exemplo, o AWS Load Balancer Controller precisa ser capaz de listar os endpoints de um serviço. O controlador também precisa ser capaz de invocar a AWS APIs para provisionar e configurar um ALB. Nesta seção, exploraremos as melhores práticas para atribuir direitos e privilégios aos pods.

Contas de serviço do Kubernetes

Uma conta de serviço é um tipo especial de objeto que permite atribuir uma função RBAC do Kubernetes a um pod. Uma conta de serviço padrão é criada automaticamente para cada namespace em um cluster. Quando você implanta um pod em um namespace sem fazer referência a uma conta de serviço específica, a conta de serviço padrão desse Namespace será automaticamente atribuída ao pod e o segredo, ou seja, o token da conta de serviço (JWT) dessa conta de serviço, será montado no pod como um volume em. /var/run/secrets/kubernetes.io/serviceaccount A decodificação do token da conta de serviço nesse diretório revelará os seguintes metadados:

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba",
  "sub": "system:serviceaccount:default:default"
}

A conta de serviço padrão tem as seguintes permissões para a API Kubernetes.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-01-30T18:13:25Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 350d2ab8-438c-11ea-9438-063a49b60fba
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

Essa função autoriza usuários não autenticados e autenticados a ler as informações da API e é considerada segura para ser acessível ao público.

Quando um aplicativo executado em um pod chama o Kubernetes APIs, é necessário atribuir ao pod uma conta de serviço que conceda explicitamente permissão para chamá-los. APIs Semelhante às diretrizes para acesso do usuário, a função ou a ClusterRole vinculação a uma conta de serviço devem ser restritas aos recursos e métodos da API de que o aplicativo precisa para funcionar e nada mais. Para usar uma conta de serviço não padrão, basta definir o spec.serviceAccountName campo de um pod com o nome da conta de serviço que você deseja usar. Para obter informações adicionais sobre a criação de contas de serviço, consulte https://kubernetes. io/docs/reference/access-authn-authz/rbac/# service-account-permissions.

Funções do IAM para contas de serviço (IRSA)

O IRSA é um recurso que permite atribuir uma função do IAM a uma conta de serviço do Kubernetes. Ele funciona aproveitando um recurso do Kubernetes conhecido como Projeção de Volume do Token da Conta de Serviço. Quando os pods são configurados com uma conta de serviço que faz referência a uma função do IAM, o servidor da API Kubernetes chamará o endpoint público de descoberta do OIDC para o cluster na inicialização. O endpoint assina criptograficamente o token OIDC emitido pelo Kubernetes e o token resultante montado como um volume. Esse token assinado permite que o pod chame a função IAM APIs associada à AWS. Quando uma API da AWS é invocada, a AWS SDKs chamasts:AssumeRoleWithWebIdentity. Depois de validar a assinatura do token, o IAM troca o token emitido pelo Kubernetes por uma credencial de função temporária da AWS.

Ao usar o IRSA, é importante reutilizar as sessões do AWS SDK para evitar chamadas desnecessárias para o AWS STS.

A decodificação do token (JWT) para IRSA produzirá uma saída semelhante ao exemplo que você vê abaixo:

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1582306514,
  "iat": 1582220114,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "alpine-57b5664646-rf966",
      "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436"
    },
    "serviceaccount": {
      "name": "s3-read-only",
      "uid": "a720ba5c-5406-11ea-9438-063a49b60fba"
    }
  },
  "nbf": 1582220114,
  "sub": "system:serviceaccount:default:s3-read-only"
}

Esse token específico concede privilégios somente de visualização do Pod ao S3 ao assumir uma função do IAM. Quando o aplicativo tenta ler do S3, o token é trocado por um conjunto temporário de credenciais do IAM semelhante a este:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc",
        "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=",
        "Expiration": "2020-02-20T18:49:50Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

Um webhook mutante que é executado como parte do plano de controle do EKS injeta o ARN da função da AWS e o caminho para um arquivo de token de identidade da web no pod como variáveis de ambiente. Esses valores também podem ser fornecidos manualmente.

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

O kubelet rotacionará automaticamente o token projetado quando ele tiver mais de 80% de seu TTL total ou após 24 horas. A AWS SDKs é responsável por recarregar o token quando ele gira. Para obter mais informações sobre o IRSA, consulte https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -technical-overview.html.

EKS Pod Identities

O EKS Pod Identities é um recurso lançado no re:Invent 2023 que permite atribuir uma função do IAM a uma conta de serviço do Kubernetes, sem a necessidade de configurar um provedor de identidade (IDP) do Open Id Connect (OIDC) para cada cluster em sua conta da AWS. Para usar o EKS Pod Identity, você deve implantar um agente que seja executado como um DaemonSet pod em cada nó de trabalho qualificado. Esse agente é disponibilizado para você como um complemento do EKS e é um pré-requisito para usar o recurso EKS Pod Identity. Seus aplicativos devem usar uma versão compatível do AWS SDK para usar esse recurso.

Quando as identidades de pod do EKS são configuradas para um pod, o EKS monta e atualiza um token de identidade do pod em. /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token Esse token será usado pelo AWS SDK para se comunicar com o EKS Pod Identity Agent, que usa o token de identidade do pod e a função IAM do agente para criar credenciais temporárias para seus pods chamando a API. AssumeRoleForPodIdentity O token de identidade do pod entregue aos seus pods é um JWT emitido do seu cluster EKS e assinado criptograficamente, com declarações de JWT apropriadas para uso com o EKS Pod Identities.

Para saber mais sobre o EKS Pod Identities, consulte este blog.

Você não precisa fazer nenhuma modificação no código do aplicativo para usar o EKS Pod Identities. As versões compatíveis do AWS SDK descobrirão automaticamente as credenciais disponibilizadas com o EKS Pod Identities usando a cadeia de fornecedores de credenciais. Assim como o IRSA, as identidades de pods do EKS definem variáveis em seus pods para orientá-los a encontrar as credenciais da AWS.

Trabalhando com funções do IAM para EKS Pod Identities

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceOrgId": "${aws:ResourceOrgId}"
        }
      }
    }
  ]
}

A AWS recomenda o uso de chaves de condição aws:SourceOrgId para ajudar a se proteger contra o problema confuso de representantes entre serviços. No exemplo acima, a política de confiança da função ResourceOrgId é uma variável igual ao ID da organização do AWS Organizations da organização da AWS à qual a conta da AWS pertence. O EKS passará um valor aws:SourceOrgId igual a esse ao assumir uma função com o EKS Pod Identities.

Identidades de pod ABAC e EKS

Quando o EKS Pod Identities assume uma função do IAM, ele define as seguintes tags de sessão:

Essas tags de sessão permitem que você use o Attribute Based Access Control (ABAC) para conceder acesso aos seus recursos da AWS somente para contas específicas do serviço Kubernetes. Ao fazer isso, é muito importante entender que as contas de serviço do Kubernetes são exclusivas somente dentro de um namespace, e os namespaces do Kubernetes são exclusivos somente dentro de um cluster EKS. Essas tags de sessão podem ser acessadas nas políticas da AWS usando a chave de condição aws:PrincipalTag/<tag-key> global, como aws:PrincipalTag/eks-cluster-arn

Por exemplo, se você quiser conceder acesso somente a uma conta de serviço específica para acessar um recurso da AWS em sua conta com um IAM ou uma política de recursos, você precisaria verificar as kubernetes-namespace tags eks-cluster-arn e também as tags kubernetes-service-account para garantir que somente as contas de serviço do cluster pretendido tenham acesso a esse recurso, pois outros clusters poderiam ter acesso idêntico kubernetes-service-accounts kubernetes-namespaces e.

Este exemplo de política do S3 Bucket só concede acesso aos objetos no bucket do S3 ao qual está anexado, somente sekubernetes-service-account,kubernetes-namespace, eks-cluster-arn todos atenderem aos valores esperados, onde o cluster EKS está hospedado na conta da AWS. 111122223333

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource":            [
                "arn:aws:s3:::ExampleBucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "s3objectservice",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace"
                }
            }
        }
    ]
}

Identidades do EKS Pod em comparação com a IRSA

Tanto o EKS Pod Identities quanto o IRSA são formas preferidas de fornecer credenciais temporárias da AWS para seus pods EKS. A menos que você tenha casos de uso específicos para o IRSA, recomendamos que você use o EKS Pod Identities ao usar o EKS. Essa tabela ajuda a comparar os dois recursos.

Recomendações de identidades e credenciais para pods EKS

Atualize o daemonset aws-node para usar o IRSA

No momento, o daemonset aws-node está configurado para usar uma função atribuída às EC2 instâncias a serem atribuídas aos pods. IPs Essa função inclui várias políticas gerenciadas pela AWS, por exemplo, Amazoneks_CNI_Policy, que permitem efetivamente que todos os pods executados em um nó acessem EC2 ContainerRegistryReadOnly endereços IP ou extraiam imagens do ECR. attach/detach ENIs assign/unassign Como isso representa um risco para seu cluster, é recomendável que você atualize o daemonset aws-node para usar o IRSA. Um script para fazer isso pode ser encontrado no repositório deste guia.

O daemonset aws-node é compatível com EKS Pod Identities nas versões v1.15.5 e posteriores.

Restrinja o acesso ao perfil da instância atribuído ao nó de trabalho

Quando você usa o IRSA ou o EKS Pod Identities, ele atualiza a cadeia de credenciais do pod para usar o IRSA ou o EKS Pod Identities primeiro. No entanto, o pod ainda pode herdar os direitos do perfil da instância atribuído ao nó de trabalho. Para pods que não precisam dessas permissões, você pode bloquear o acesso aos metadados da instância para ajudar a garantir que seus aplicativos tenham apenas as permissões necessárias, e não seus nós.

Você pode bloquear o acesso aos metadados da instância exigindo que a instância use IMDSv2 somente e atualizando a contagem de saltos para 1, como no exemplo abaixo. Você também pode incluir essas configurações no modelo de lançamento do grupo de nós. Não desative os metadados da instância, pois isso impedirá que componentes como o manipulador de terminação do nó e outras coisas que dependem dos metadados da instância funcionem corretamente.

$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1
...

Se você estiver usando o Terraform para criar modelos de lançamento para uso com grupos de nós gerenciados, adicione o bloco de metadados para configurar a contagem de saltos, conforme visto neste trecho de código:

tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" …​ metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …​

Você também pode bloquear o acesso de um pod aos EC2 metadados manipulando iptables no nó. Para obter mais informações sobre esse método, consulte Limitar o acesso ao serviço de metadados da instância.

Se você tem um aplicativo que está usando uma versão mais antiga do AWS SDK que não é compatível com IRSA ou EKS Pod Identities, você deve atualizar a versão do SDK.

Defina o escopo da política de confiança do IAM Role para IRSA Roles para o nome da conta de serviço, namespace e cluster

A política de confiança pode ter como escopo um namespace ou uma conta de serviço específica dentro de um namespace. Ao usar o IRSA, é melhor tornar a política de confiança da função o mais explícita possível, incluindo o nome da conta de serviço. Isso evitará efetivamente que outros pods no mesmo namespace assumam a função. A CLI eksctl fará isso automaticamente quando você a usar para criar funções de serviço accounts/IAM . Consulte https://eksctl. io/usage/iamserviceaccounts/para obter mais informações.

Ao trabalhar diretamente com o IAM, isso significa adicionar uma condição à política de confiança da função que usa condições para garantir que a :sub declaração seja o namespace e a conta de serviço que você espera. Como exemplo, antes tínhamos um token IRSA com uma subdeclaração de “system:serviceaccount:default:s3-read-only”. Esse é o default namespace e a conta de serviço é. s3-read-only Você usaria uma condição como a seguinte para garantir que somente sua conta de serviço em um determinado namespace do seu cluster possa assumir essa função:

  "Condition": {
      "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com",
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only"
      }
  }

Use uma função do IAM por aplicativo

Com o IRSA e o EKS Pod Identity, é uma prática recomendada atribuir a cada aplicativo sua própria função de IAM. Isso proporciona um isolamento aprimorado, pois você pode modificar um aplicativo sem afetar outro e permite aplicar o princípio de menor privilégio concedendo a um aplicativo apenas as permissões necessárias.

Ao usar o ABAC com o EKS Pod Identity, você pode usar uma função comum do IAM em várias contas de serviço e confiar nos atributos de sessão para controle de acesso. Isso é especialmente útil ao operar em grande escala, pois o ABAC permite que você opere com menos funções do IAM.

Quando seu aplicativo precisar acessar o IMDS, use IMDSv2 e aumente o limite de salto nas EC2 instâncias para 2

IMDSv2exige que você use uma solicitação PUT para obter um token de sessão. A solicitação PUT inicial precisa incluir um TTL para o token da sessão. As versões mais recentes da AWS SDKs lidarão com isso e com a renovação do referido token automaticamente. Também é importante estar ciente de que o limite de salto padrão nas EC2 instâncias é definido intencionalmente como 1 para evitar o encaminhamento de IP. Como consequência, os pods que solicitam um token de sessão executado em EC2 instâncias podem eventualmente expirar e voltar a usar o fluxo de IMDSv1 dados. O EKS adiciona suporte IMDSv2 habilitando a v1 e a v2 e alterando o limite de saltos para 2 nos nós provisionados pelo eksctl ou com os modelos oficiais. CloudFormation

Desativar a montagem automática de tokens da conta de serviço

Se seu aplicativo não precisar chamar a API Kubernetes, defina o automountServiceAccountToken atributo como false in PodSpec para seu aplicativo ou corrija a conta de serviço padrão em cada namespace para que ela não seja mais montada automaticamente nos pods. Por exemplo:

kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

Use contas de serviço dedicadas para cada aplicativo

Cada aplicativo deve ter sua própria conta de serviço dedicada. Isso se aplica às contas de serviço da API Kubernetes, bem como ao IRSA e ao EKS Pod Identity.

Execute o aplicativo como um usuário não root

Os contêineres são executados como root por padrão. Embora isso permita que eles leiam o arquivo de token de identidade da web, executar um contêiner como root não é considerado uma prática recomendada. Como alternativa, considere adicionar o spec.securityContext.runAsUser atributo ao PodSpec. O valor de runAsUser é um valor arbitrário.

No exemplo a seguir, todos os processos dentro do pod serão executados com o ID de usuário especificado no runAsUser campo.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

Quando você executa um contêiner como usuário não root, isso impede que o contêiner leia o token da conta de serviço IRSA porque o token recebe permissões 0600 [root] por padrão. Se você atualizar o SecurityContext do seu contêiner para incluir fsgroup=65534 [Ninguém], isso permitirá que o contêiner leia o token.

spec:
  securityContext:
    fsGroup: 65534

No Kubernetes 1.19 e versões posteriores, essa alteração não é mais necessária e os aplicativos podem ler o token da conta de serviço IRSA sem adicioná-los ao grupo Ninguém.

Conceda acesso menos privilegiado aos aplicativos

O Action Hero é um utilitário que você pode executar junto com seu aplicativo para identificar as chamadas de API da AWS e as permissões de IAM correspondentes que seu aplicativo precisa para funcionar adequadamente. É semelhante ao IAM Access Advisor, pois ajuda você a limitar gradualmente o escopo das funções do IAM atribuídas aos aplicativos. Consulte a documentação sobre como conceder acesso menos privilegiado aos recursos da AWS para obter mais informações.

Considere definir um limite de permissões nas funções do IAM usadas com IRSA e Pod Identities. Você pode usar o limite de permissões para garantir que as funções usadas pelo IRSA ou pelo Pod Identities não excedam o nível máximo de permissões. Para obter um exemplo de guia sobre como começar a usar limites de permissões com um exemplo de política de limite de permissões, consulte este repositório do github.

Revise e revogue o acesso anônimo desnecessário ao seu cluster EKS

Idealmente, o acesso anônimo deve ser desativado para todas as ações da API. O acesso anônimo é concedido criando um RoleBinding ou ClusterRoleBinding para o sistema de usuário integrado do Kubernetes:anonymous. Você pode usar a ferramenta rbac-lookup para identificar as permissões que o usuário system:anonymous tem em seu cluster:

./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)'
system:anonymous               cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:public-info-viewer

Qualquer função ou ClusterRole outra que não seja system: não public-info-viewer deve ser vinculada ao system:anonymous user ou system:unauthenticated group.

Pode haver alguns motivos legítimos para permitir o acesso anônimo em determinadas áreas APIs. Se esse for o caso do seu cluster, certifique-se de que somente aqueles específicos APIs sejam acessíveis por usuários anônimos e expô-los APIs sem autenticação não tornará seu cluster vulnerável.

Antes da Kubernetes/EKS versão 1.14, o grupo system:unauthenticated era associado a system:discovery e system:basic-user por padrão. ClusterRoles Observe que, mesmo que você tenha atualizado seu cluster para a versão 1.14 ou superior, essas permissões ainda podem estar habilitadas em seu cluster, já que as atualizações do cluster não revogam essas permissões. Para verificar quais ClusterRoles têm “system:unauthenticated”, exceto system: public-info-viewer você pode executar o seguinte comando (requer jq util):

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'

E “system:unauthenticated” pode ser removido de todas as funções, exceto “system:” usando: public-info-viewer

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -

Como alternativa, você pode verificá-la e removê-la manualmente usando kubectl describe e kubectl edit. Para verificar se o grupo system:unauthenticated tem permissões system:discovery no seu cluster, execute o seguinte comando:

kubectl describe clusterrolebindings system:discovery

Name:         system:discovery
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:discovery
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Para verificar se system:unauthenticated group tem permissão system:basic-user em seu cluster, execute o seguinte comando:

kubectl describe clusterrolebindings system:basic-user

Name:         system:basic-user
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:basic-user
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Se o grupo system:unauthenticated estiver vinculado a system:discovery e/ou system:basic-user em seu cluster, você deverá desassociar essas funções do grupo ClusterRoles system:unauthenticated. Edite system:discovery ClusterRoleBinding usando o seguinte comando:

kubectl edit clusterrolebindings system:discovery

O comando acima abrirá a definição atual de system:discovery ClusterRoleBinding em um editor, conforme mostrado abaixo:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-06-17T20:50:49Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "24502985"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: b7936268-5043-431a-a0e1-171a423abeb6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

Exclua a entrada para system:unauthenticated group da seção “assuntos” na tela do editor acima.

Repita as mesmas etapas para ClusterRoleBinding system:basic-user.

Reutilize sessões do AWS SDK com a IRSA

Quando você usa o IRSA, os aplicativos criados usando o SDK da AWS usam o token entregue aos seus pods para fazer chamadas sts:AssumeRoleWithWebIdentity para gerar credenciais temporárias da AWS. Isso é diferente de outros serviços computacionais da AWS, nos quais o serviço computacional entrega credenciais temporárias da AWS diretamente para o recurso computacional da AWS, como uma função lambda. Isso significa que toda vez que uma sessão do AWS SDK é inicializada, uma chamada para o AWS STS for AssumeRoleWithWebIdentity é feita. Se seu aplicativo escalar rapidamente e inicializar muitas sessões do AWS SDK, você poderá enfrentar a limitação do AWS STS, pois seu código fará muitas chamadas. AssumeRoleWithWebIdentity

Para evitar esse cenário, recomendamos reutilizar as sessões do AWS SDK em seu aplicativo para que chamadas desnecessárias não AssumeRoleWithWebIdentity sejam feitas.

No código de exemplo a seguir, uma sessão é criada usando o SDK boto3 python, e essa mesma sessão é usada para criar clientes e interagir com o Amazon S3 e o Amazon SQS. AssumeRoleWithWebIdentityé chamado apenas uma vez, e o SDK da AWS atualizará as credenciais de my_session quando elas expirarem automaticamente.

import boto3

= Create your own session

my_session = boto3.session.Session()

= Now we can create low-level clients from our session

sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`')

s3response = s3.list_buckets() sqsresponse = sqs.list_queues()

#print the response from the S3 and SQS APIs print("`s3 response:`")
print(s3response) print("`—`") print("`sqs response:`")
print(sqsresponse) ```

Se você estiver migrando um aplicativo de outro serviço computacional da AWS, como EC2, para o EKS com o IRSA, esse é um detalhe particularmente importante. Em outros serviços de computação, a inicialização de uma sessão do AWS SDK não chama o AWS STS, a menos que você o instrua.

Abordagens alternativas

Embora as identidades de pod IRSA e EKS sejam as formas preferidas de atribuir uma identidade da AWS a um pod, elas exigem que você inclua uma versão recente da AWS SDKs em seu aplicativo. Para obter uma lista completa dos SDKs que atualmente oferecem suporte ao IRSA, consulte https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -minimum-sdk.html, para EKS Pod Identities, consulte https://docs.aws.amazon.com/eks/latest/userguide/pod- id-minimum-sdk .html. Se você tem um aplicativo que não pode ser atualizado imediatamente com um SDK compatível, há várias soluções criadas pela comunidade disponíveis para atribuir funções do IAM aos pods do Kubernetes, incluindo kube2iam e kiam. Embora a AWS não endosse, tolere nem apoie o uso dessas soluções, elas são frequentemente usadas pela comunidade em geral para obter resultados semelhantes aos das identidades IRSA e EKS Pod.

Se você precisar usar uma dessas soluções não fornecidas pela AWS, faça a devida diligência e certifique-se de entender as implicações de segurança de fazer isso.

Ferramentas e recursos