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 **dica** [Explore as](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) melhores práticas por meio de workshops do Amazon EKS. O [Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (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](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html#intro-structure-principal) da AWS, como um [usuário ou [função](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_iam-roles) do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_iam-users). As regras que regem as ações que um recurso pode realizar são expressas como [políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html). ## 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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication), [tokens de conta de serviço](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) 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-authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator)`kubectl`executa 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 --region ``` A saída deve ser semelhante a esta: ``` { "kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": { "expirationTimestamp": "2024-12-20T17:38:48Z", "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0yLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZ...." } } ``` 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("") 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 \$1 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 cliente`kubectl`, 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. ### CloudWatch consulta para ajudar os usuários a identificar clientes que enviam solicitações para o endpoint STS global Execute a CloudWatch consulta abaixo para obter o endpoint sts. Se stsendpoint for igual a “sts.amazonaws.com”, então é um endpoint STS global. Se stsendpoint for igual a “sts. .amazonaws.com”, então é um endpoint regional do STS. ``` fields @timestamp, @message, @logStream, @log,stsendpoint | filter @logStream like /authenticator/ | filter @message like /stsendpoint/ | sort @timestamp desc | limit 10000 ``` ### 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: + **Entradas de acesso:** uma identidade de cluster diretamente vinculada a um principal (usuário ou função) do AWS IAM com permissão para se autenticar em um cluster Amazon EKS. + **Políticas de acesso:** são políticas específicas do Amazon EKS que fornecem a autorização para que uma entrada de acesso execute ações no cluster do Amazon EKS. 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: 1. `CONFIG_MAP`para continuar usando o `aws-auth` ConfigMap exclusivamente. 1. `API_AND_CONFIG_MAP`para obter os principais autenticados do IAM do EKS Access Entry APIs e do `aws-auth` ConfigMap, priorizando as entradas de acesso. Ideal para migrar as `aws-auth` permissões existentes para o Access Entries. 1. `API`confiar exclusivamente no EKS Access Entry APIs. Essa é a nova **abordagem recomendada**. 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 \ --role-arn \ --resources-vpc-config subnetIds=,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 habilitar 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` para`CONFIG_MAP`. ``` $ aws eks update-cluster-config \ --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. | Política de acesso ao EKS | RBAC do Kubernetes | | --- | --- | | Amazon EKSCluster AdminPolicy | administrador de cluster | | EKSAdminPolítica da Amazon | admin | | EKSEditPolítica da Amazon | editar | | EKSViewPolítica da Amazon | visualizar | ``` $ 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 { "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-auth`ConfigMap. ``` apiVersion: v1 data: mapRoles: | - groups: - system:bootstrappers - system:nodes - system:node-proxier rolearn: arn:aws:iam:::role/kube-system- 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. + **grupos:** o Kubernetes group/groups para o qual mapear a função do IAM. Isso pode ser um grupo padrão ou um grupo personalizado especificado em um `clusterrolebinding` ou`rolebinding`. No exemplo acima, temos apenas grupos de sistemas declarados. + **rolearn:** O ARN da função AWS IAM deve ser mapeado para a adição de grupos/grupos do Kubernetes, usando o formato a seguir. `arn::iam:::role/role-name` + **nome de usuário:** o nome de usuário no Kubernetes a ser mapeado para a função AWS IAM. Isso pode ser qualquer nome personalizado. Também é possível mapear permissões para usuários do AWS IAM, definindo um novo bloco de configuração para`mapUsers`, abaixo `data` de `aws-auth`ConfigMap, 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 como`eksctl`, 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](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_cluster_access_recommendations) obter mais detalhes. ### Benefícios ConfigMap em relação ao gerenciamento de acesso baseado 1. **Risco reduzido de configurações incorretas**: o gerenciamento direto baseado em API elimina erros comuns associados à edição manual. ConfigMap Isso ajuda a evitar exclusões acidentais ou erros de sintaxe que podem impedir que os usuários saiam do cluster. 1. **Princípio aprimorado de privilégios mínimos**: elimina a necessidade de permissão de administrador de cluster da identidade do criador do cluster e permite uma atribuição de permissões mais granular e apropriada. Você pode optar por adicionar essa permissão para casos de uso de quebra-vidros. 1. **Modelo de segurança aprimorado**: fornece validação integrada das entradas de acesso antes de serem aplicadas. Além disso, oferece maior integração com o AWS IAM para autenticação. 1. **Operações simplificadas**: oferece uma maneira mais intuitiva de gerenciar permissões por meio de ferramentas nativas da AWS. ## Recomendações de acesso ao cluster ### Combine o IAM Identity Center com a API CAM + **Gerenciamento simplificado**: ao usar a API Cluster Access Management em conjunto com o IAM Identity Center, os administradores podem gerenciar o acesso ao cluster EKS junto com outros serviços da AWS, reduzindo a necessidade de alternar entre diferentes interfaces ou editar ConfigMaps manualmente. + Use entradas de acesso para gerenciar as permissões do Kubernetes das entidades principais do IAM de fora do cluster. Você pode adicionar e gerenciar o acesso ao cluster usando a API EKS, a interface de linha de comando da AWS, a AWS SDKs, a AWS CloudFormation e o AWS Management Console. Isso significa que você pode gerenciar usuários com as mesmas ferramentas com as quais criou o cluster. + Aproveite a automação, conforme demonstrado [neste exemplo,](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/sso-iam-identity-center) para implantar clusters com o AWS IAM Identity Center como IdP e a API CAM como ponto de entrada. + As permissões granulares do Kubernetes podem ser aplicadas com o mapeamento de usuários ou grupos do Kubernetes com diretores do IAM associados a identidades de SSO por meio de entradas de acesso e políticas de acesso. + Para começar, siga [Alterar o modo de autenticação para usar entradas de acesso e, em seguida, Migrar entradas](https://docs.aws.amazon.com/eks/latest/userguide/setting-up-access-entries.html#access-entries-setup-console) [aws-auth existentes para ConfigMap entradas](https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html) de acesso. ### 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: + Configure o endpoint do cluster EKS para ser privado. Consulte [Modificando o acesso ao Cluster Endpoint](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) para obter mais informações sobre esse tópico. + Deixe o endpoint do cluster público e especifique quais blocos CIDR podem se comunicar com o endpoint do cluster. Os blocos são, na verdade, um conjunto de endereços IP públicos na lista branca que têm permissão para acessar o endpoint do cluster. + Configure o acesso público com um conjunto de blocos CIDR na lista branca e defina o acesso ao endpoint privado como ativado. Isso permitirá o acesso público de uma faixa específica de público e, IPs ao mesmo tempo, forçará todo o tráfego de rede entre os kubelets (trabalhadores) e a API do Kubernetes por meio da conta cruzada que é provisionada ENIs na VPC do cluster quando o plano de controle é provisionado. ### 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 instâncias EC2, 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ão`false`, `--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 \ --principal-arn $ aws eks disassociate-access-policy --cluster-name \ --principal-arn { "accessEntries": [] } $ aws eks delete-access-entry --cluster-name \ --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 a função `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. **Importante** Ao acessar o cluster EKS com a entidade IAM mapeada por `aws-auth` ConfigMap, o nome de usuário descrito é registrado no campo de usuário do registro de auditoria do Kubernetes. Se você estiver usando uma função do IAM, os usuários reais que assumem essa função não são registrados e não podem ser auditados. 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\$1 \$1\$1\$1\$1 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 ``` No Kubernetes 1.20 e versões posteriores, essa alteração não é mais necessária, pois `user.extra.sessionName.0` foi adicionada ao registro de auditoria do Kubernetes. ### 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](https://github.com/liggitt/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](#iam-cluster-creator), 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](https://github.com/aquasecurity/kubectl-who-can), como [rbac-lookup](https://github.com/FairwindsOps/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.](auditing-and-logging.md) Ideias adicionais podem ser encontradas neste [artigo](https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/august/tools-and-methods-for-auditing-kubernetes-rbac-policies/?mkt_tok=eyJpIjoiWWpGa056SXlNV1E0WWpRNSIsInQiOiJBT1hyUTRHYkg1TGxBV0hTZnRibDAyRUZ0VzBxbndnRzNGbTAxZzI0WmFHckJJbWlKdE5WWDdUQlBrYVZpMnNuTFJ1R3hacVYrRCsxYWQ2RTRcL2pMN1BtRVA1ZFZcL0NtaEtIUDdZV3pENzNLcE1zWGVwUndEXC9Pb2tmSERcL1pUaGUifQ%3D%3D) 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- system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier ``` Transforme uma função do IAM em administrador de cluster: ``` $ eksctl create iamidentitymapping --cluster --region= --arn arn:aws:iam::123456:role/testing --group system:masters --username admin ... ``` Para obter mais informações, revise os [`eksctl`documentos](https://eksctl.io/usage/iam-identity-mappings/) **[aws-auth](https://github.com/keikoproj/aws-auth) por keikoproj** `aws-auth`by 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](https://krew.sigs.k8s.io) para kubectl. ``` $ kubectl krew install aws-auth ... $ kubectl aws-auth ... ``` [Consulte a documentação do aws-auth em GitHub](https://github.com/keikoproj/aws-auth/blob/master/README.md) para obter mais informações, incluindo a biblioteca go. **[CLI do AWS IAM Authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator/tree/master/cmd/aws-iam-authenticator)** O `aws-iam-authenticator` projeto inclui uma CLI para atualizar o. ConfigMap [Baixe uma versão](https://github.com/kubernetes-sigs/aws-iam-authenticator/releases) 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.](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) Publicações sobre duas dessas soluções foram publicadas no blog de código aberto da AWS: + [Autenticação no EKS usando GitHub credenciais com teleporte](https://aws.amazon.com/blogs/opensource/authenticating-eks-github-credentials-teleport/) + [Autenticação OIDC consistente em vários clusters EKS usando kube-oidc-proxy](https://aws.amazon.com/blogs/opensource/consistent-oidc-authentication-across-multiple-eks-clusters-using-kube-oidc-proxy/) **Importante** O EKS oferece suporte nativo à autenticação OIDC sem usar um proxy. Para obter mais informações, leia o blog de lançamento, [Apresentando a autenticação do provedor de identidade OIDC para o Amazon EKS](https://aws.amazon.com/blogs/containers/introducing-oidc-identity-provider-authentication-amazon-eks/). Para ver um exemplo de como configurar o EKS com o Dex, um popular provedor OIDC de código aberto com conectores para uma variedade de métodos de autenticação diferentes, consulte [Uso do Dex e do autenticador dex-k8s-para](https://aws.amazon.com/blogs/containers/using-dex-dex-k8s-authenticator-to-authenticate-to-amazon-eks/) autenticação no Amazon EKS. Conforme descrito nos blogs, os username/group usuários autenticados por um provedor OIDC aparecerão no registro de auditoria do Kubernetes. Você também pode usar o [AWS SSO](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 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 do Kubernetes para funcionar corretamente. Por exemplo, o [AWS Load Balancer Controller](https://github.com/kubernetes-sigs/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/\$1service-account-permissions. **nota** Antes do Kubernetes 1.24, o Kubernetes criava automaticamente um segredo para cada conta de serviço. Esse segredo foi montado no pod em/var/run/secrets/kubernetes.io/serviceaccounte seria usado pelo pod para se autenticar no servidor da API Kubernetes. No Kubernetes 1.24, um token de conta de serviço é gerado dinamicamente quando o pod é executado e, por padrão, só é válido por uma hora. Um segredo para a conta de serviço não será criado. Se você tiver um aplicativo executado fora do cluster que precisa se autenticar na API Kubernetes, por exemplo, Jenkins, precisará criar um segredo do tipo `kubernetes.io/service-account-token` junto com uma anotação que faça referência à conta de serviço, como. `metadata.annotations.kubernetes.io/service-account.name: ` Os segredos criados dessa maneira não expiram. ### 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](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection). 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 chama`sts: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](#iam-reuse-sessions) 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% do 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](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) é 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](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html) 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](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) O token de identidade do pod entregue aos seus pods é um JWT emitido do seu cluster EKS e assinado criptograficamente, com declarações JWT apropriadas para uso com o EKS Pod Identities. Para saber mais sobre o EKS Pod Identities, consulte [este blog](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/). 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](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html). 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 + O EKS Pod Identities só pode assumir diretamente uma função do IAM que pertença à mesma conta da AWS do cluster EKS. Para acessar uma função do IAM em outra conta da AWS, você deve assumir essa função [configurando um perfil na configuração do SDK](https://docs.aws.amazon.com/sdkref/latest/guide/feature-assume-role-credentials.html) ou no código [do seu aplicativo](https://docs.aws.amazon.com/IAM/latest/UserGuide/sts_example_sts_AssumeRole_section.html). + Quando as identidades de pod do EKS estão sendo configuradas para contas de serviço, a pessoa ou o processo que configura a associação de identidade do pod deve ter o `iam:PassRole` direito a essa função. + Cada conta de serviço pode ter apenas uma função do IAM associada a ela por meio do EKS Pod Identities, mas você pode associar a mesma função do IAM a várias contas de serviço. + As funções do IAM usadas com o EKS Pod Identities devem permitir que o responsável pelo `pods.eks.amazonaws.com` serviço as assuma *e* defina tags de sessão. Veja a seguir um exemplo de política de confiança de função que permite que o EKS Pod Identities use uma função do IAM: ``` { "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](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html#cross-service-confused-deputy-prevention). 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: | Tag de sessão EKS Pod Identities | Valor | | --- | --- | | namespace kubernetes | O namespace em que o pod associado ao EKS Pod Identities é executado. | | kubernetes-service-account | O nome da conta de serviço kubernetes associada ao EKS Pod Identities | | eks-cluster-arn | O ARN do cluster EKS, por exemplo. `arn:${Partition}:eks:${Region}:${Account}:cluster/${ClusterName}` O ARN do cluster é exclusivo, mas se um cluster for excluído e recriado na mesma região com o mesmo nome, dentro da mesma conta da AWS, ele terá o mesmo ARN. | | eks-cluster-name | O nome do cluster do EKS. Observe que os nomes dos clusters do EKS podem ser os mesmos na sua conta da AWS e dos clusters do EKS em outras contas da AWS. | | kubernetes-pod-name | O nome do pod no EKS. | | kubernetes-pod-uid | O UID do pod no EKS. | Essas tags de sessão permitem que você use o [Attribute Based Access Control (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) 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/` 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 se`kubernetes-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. | \$1 | EKS Pod Identities | IRSA | | --- | --- | --- | | Requer permissão para criar um IDP do OIDC em suas contas da AWS? | Não | Sim | | Requer configuração exclusiva de IDP por cluster | Não | Sim | | Define tags de sessão relevantes para uso com o ABAC | Sim | Não | | Requer um objetivo: PassRole Verificar? | Sim | Não | | Usa a cota do AWS STS da sua conta da AWS? | Não | Sim | | Pode acessar outras contas da AWS | Indiretamente com o encadeamento de funções | Diretamente com sts: AssumeRoleWithWebIdentity | | Compatível com a AWS SDKs | Sim | Sim | | Requer o Pod Identity Agent Daemonset nos nós? | Sim | Não | ## 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 instâncias do EC2 para atribuir aos pods. IPs Essa função inclui várias políticas gerenciadas pela AWS, por exemplo, Amazoneks\$1CNI\$1Policy, 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 atualizar o daemonset aws-node para usar o IRSA. Um script para fazer isso pode ser encontrado no [repositório](https://github.com/aws/aws-eks-best-practices/tree/master/projects/enable-irsa/src) 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) para ajudar a garantir que seus aplicativos tenham apenas as permissões necessárias, e não seus nós. **Atenção** Bloquear o acesso aos metadados da instância impedirá que pods que não usam identidades de pod IRSA ou EKS herdem a função atribuída ao node de trabalho. 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 --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 metadados do EC2 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html#instance-metadata-limiting-access). 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 dar 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 o IMDSv2 e aumente o limite de saltos nas instâncias do EC2 para 2 [IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html)exige 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 dos SDKs da AWS lidarão com isso e com a renovação desse token automaticamente. Também é importante estar ciente de que o limite de salto padrão nas instâncias do EC2 é definido intencionalmente como 1 para evitar o encaminhamento de IP. Como consequência, os pods que solicitam um token de sessão executado em instâncias do EC2 podem eventualmente expirar e voltar a usar o IMDSv1 fluxo de 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. **Importante** Se você empregar uma blue/green abordagem para atualizações de cluster em vez de realizar uma atualização de cluster no local ao usar o IRSA, precisará atualizar a política de confiança de cada uma das funções do IRSA IAM com o endpoint OIDC do novo cluster. Uma atualização de blue/green cluster é quando você cria um cluster executando uma versão mais recente do Kubernetes junto com o cluster antigo e usa um balanceador de carga ou uma malha de serviços para transferir facilmente o tráfego dos serviços executados no cluster antigo para o novo cluster. Ao usar atualizações de blue/green cluster com o EKS Pod Identity, você criaria associações de identidade de pod entre as funções do IAM e as contas de serviço no novo cluster. E atualize a política de confiança da função do IAM se você tiver uma `sourceArn` condição. ### 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](https://github.com/princespaghetti/actionhero) é 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html), 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) recursos da AWS para obter mais informações. Considere definir um [limite de permissões](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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.](https://github.com/aws-samples/example-permissions-boundary) ### 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](https://github.com/FairwindsOps/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 system:unauthenticated group tem permissões system:discovery em 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 o EC2, para o EKS com 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, for EKS Pod Identities, see https://docs.aws.amazon.com/eks/latest/userguide/pod - id-minimum-sdk .html. [https://github.com/jtblin/kube2iam](https://github.com/jtblin/kube2iam) 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 + [Workshop de imersão em segurança do Amazon EKS — Identity and Access Management](https://catalog.workshops.aws/eks-security-immersionday/en-US/2-identity-and-access-management) + [Padrão de projetos do Terraform EKS - Cluster Amazon EKS totalmente privado](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/fully-private-cluster) + [Padrão de blueprints do Terraform EKS - Login único do IAM Identity Center para o cluster Amazon EKS](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/sso-iam-identity-center) + [Padrão de blueprints do Terraform EKS - Login único Okta para o cluster Amazon EKS](https://github.com/aws-ia/terraform-aws-eks-blueprints/tree/main/patterns/sso-okta) + [auditoria 2rbac](https://github.com/liggitt/audit2rbac) + [rbac.dev](https://github.com/mhausenblas/rbac.dev) Uma lista de recursos adicionais, incluindo blogs e ferramentas, para o Kubernetes RBAC + [Herói de ação](https://github.com/princespaghetti/actionhero) + [kube2iam](https://github.com/jtblin/kube2iam) + [kiam](https://github.com/uswitch/kiam)