Estratégia de várias contas

A AWS recomenda usar uma estratégia de várias contas e organizações da AWS para ajudar a isolar e gerenciar seus aplicativos e dados comerciais. Há muitos benefícios em usar uma estratégia de várias contas:

• Aumento das cotas de serviços de API da AWS. As cotas são aplicadas às contas da AWS, e o uso de várias contas para suas cargas de trabalho aumenta a cota geral disponível para suas cargas de trabalho.

• Políticas mais simples de Identity and Access Management (IAM). Conceder às cargas de trabalho e aos operadores que as apoiam acesso somente às suas próprias contas da AWS significa menos tempo criando políticas de IAM refinadas para alcançar o princípio do menor privilégio.

• Isolamento aprimorado dos recursos da AWS. Por padrão, todos os recursos provisionados em uma conta são logicamente isolados dos recursos provisionados em outras contas. Esse limite de isolamento fornece uma maneira de limitar os riscos de um problema relacionado à aplicação, a uma configuração incorreta ou a ações mal-intencionadas. Se ocorrer um problema em uma conta, os impactos nas workloads contidas em outras contas poderão ser reduzidos ou eliminados.

• Mais benefícios, conforme descrito no whitepaper da AWS Multi Account Strategy

As seções a seguir explicarão como implementar uma estratégia de várias contas para suas cargas de trabalho do EKS usando uma abordagem de cluster EKS centralizada ou descentralizada.

Planejando uma estratégia de conta com várias cargas de trabalho para clusters com vários inquilinos

Em uma estratégia multiconta da AWS, os recursos que pertencem a uma determinada carga de trabalho, como buckets S3, clusters ElastiCache e tabelas do DynamoDB, são todos criados em uma conta da AWS que contém todos os recursos dessa carga de trabalho. Elas são chamadas de conta de carga de trabalho, e o cluster EKS é implantado em uma conta chamada conta de cluster. As contas de cluster serão exploradas na próxima seção. A implantação de recursos em uma conta de carga de trabalho dedicada é semelhante à implantação de recursos do kubernetes em um namespace dedicado.

As contas de carga de trabalho podem então ser mais detalhadas por ciclo de vida de desenvolvimento de software ou outros requisitos, se apropriado. Por exemplo, uma determinada carga de trabalho pode ter uma conta de produção, uma conta de desenvolvimento ou contas para hospedar instâncias dessa carga de trabalho em uma região específica. Mais informações estão disponíveis neste whitepaper da AWS.

Você pode adotar as seguintes abordagens ao implementar a estratégia EKS Multi Account:

Cluster EKS centralizado

Nessa abordagem, seu cluster EKS será implantado em uma única conta da AWS chamada deCluster Account. Usando as funções do IAM para contas de serviço (IRSA) ou EKS Pod Identities para fornecer credenciais temporárias da AWS e o AWS Resource Access Manager (RAM) para simplificar o acesso à rede, você pode adotar uma estratégia de várias contas para seu cluster EKS multilocatário. A conta do cluster conterá a VPC, as sub-redes, o cluster EKS, os recursos computacionais EC2 /Fargate (nós de trabalho) e todas as configurações de rede adicionais necessárias para executar seu cluster EKS.

Em uma estratégia de contas com várias cargas de trabalho para clusters multilocatários, as contas da AWS normalmente se alinham aos namespaces do Kubernetes como um mecanismo para isolar grupos de recursos. As melhores práticas para isolamento de inquilinos em um cluster EKS ainda devem ser seguidas ao implementar uma estratégia de várias contas para clusters EKS de vários inquilinos.

É possível ter vários Cluster Accounts em sua organização da AWS, e é uma prática recomendada ter vários Cluster Accounts que se alinhem às suas necessidades do ciclo de vida de desenvolvimento de software. Para cargas de trabalho que operam em uma escala muito grande, você pode precisar de várias Cluster Accounts para garantir que haja cotas de serviços de Kubernetes e AWS suficientes disponíveis para todas as suas cargas de trabalho.

|No diagrama acima, a AWS RAM é usada para compartilhar sub-redes de uma conta de cluster em uma conta de carga de trabalho. Em seguida, as cargas de trabalho executadas em pods EKS usam IRSA ou EKS Pod Identities e o encadeamento de funções para assumir uma função em sua conta de carga de trabalho e acessar seus recursos da AWS.

Implementando uma estratégia de conta com várias cargas de trabalho para clusters multilocatários

Compartilhamento de sub-redes com o AWS Resource Access Manager

O AWS Resource Access Manager (RAM) permite que você compartilhe recursos entre contas da AWS.

Se a RAM estiver habilitada para sua organização da AWS, você poderá compartilhar as sub-redes VPC da conta Cluster com suas contas de carga de trabalho. Isso permitirá que os recursos da AWS pertencentes às suas contas de carga de trabalho, como Amazon ElastiCache Clusters ou bancos de dados Amazon Relational Database Service (RDS), sejam implantados na mesma VPC do seu cluster EKS e possam ser consumidos pelas cargas de trabalho em execução no seu cluster EKS.

Para compartilhar um recurso via RAM, abra a RAM no console AWS da conta do cluster e selecione “Resource Shares” e “Create Resource Share”. Nomeie seu compartilhamento de recursos e selecione as sub-redes que você deseja compartilhar. Selecione Avançar novamente e insira a conta de 12 dígitos IDs para as contas de carga de trabalho com as quais você deseja compartilhar as sub-redes, selecione Avançar novamente e clique em Criar compartilhamento de recursos para concluir. Após essa etapa, a conta de carga de trabalho pode implantar recursos nessas sub-redes.

Os compartilhamentos de RAM também podem ser criados programaticamente ou com infraestrutura como código.

Escolhendo entre o EKS Pod Identities e o IRSA

No re:Invent 2023, a AWS lançou o EKS Pod Identities como uma forma mais simples de entregar credenciais temporárias da AWS para seus pods no EKS. Tanto o IRSA quanto o EKS Pod Identities são métodos válidos para entregar credenciais temporárias da AWS aos seus pods EKS e continuarão sendo suportados. Você deve considerar qual método de entrega atende melhor às suas necessidades.

Ao trabalhar com um cluster EKS e várias contas da AWS, a IRSA pode assumir diretamente funções nas contas da AWS que não sejam a conta na qual o cluster EKS está hospedado diretamente, enquanto as identidades do EKS Pod exigem que você configure o encadeamento de funções. Consulte a documentação do EKS para uma comparação detalhada.

Acessando recursos de API da AWS com funções do IAM para contas de serviço

O IAM Roles for Service Accounts (IRSA) permite que você entregue credenciais temporárias da AWS para suas cargas de trabalho executadas no EKS. O IRSA pode ser usado para obter credenciais temporárias para funções do IAM nas contas de carga de trabalho da conta do cluster. Isso permite que suas cargas de trabalho em execução nos clusters do EKS na conta do cluster consumam recursos da API da AWS, como buckets do S3 hospedados na conta de carga de trabalho, sem interrupções, e usem a autenticação do IAM para recursos como bancos de dados do Amazon RDS ou Amazon EFS. FileSystems

Os recursos da API da AWS e outros recursos que usam a autenticação do IAM em uma conta de carga de trabalho só podem ser acessados por credenciais para funções do IAM nessa mesma conta de carga de trabalho, exceto quando o acesso entre contas é possível e foi habilitado explicitamente.

Habilitando o IRSA para acesso entre contas

Para habilitar o IRSA para cargas de trabalho em sua conta de cluster para acessar recursos em suas contas de carga de trabalho, primeiro você deve criar um provedor de identidade IAM OIDC em sua conta de carga de trabalho. Isso pode ser feito com o mesmo procedimento para configurar o IRSA, exceto que o provedor de identidade será criado na conta da carga de trabalho.

Então, ao configurar o IRSA para suas cargas de trabalho no EKS, você pode seguir as mesmas etapas da documentação, mas usar o ID da conta de carga de trabalho de 12 dígitos, conforme mencionado na seção “Exemplo de criação de um provedor de identidade a partir do cluster de outra conta”.

Depois que isso for configurado, seu aplicativo executado no EKS poderá usar diretamente sua conta de serviço para assumir uma função na conta de carga de trabalho e usar recursos dentro dela.

Acessando recursos de API da AWS com o EKS Pod Identities

O EKS Pod Identities é uma nova forma de fornecer credenciais da AWS para suas cargas de trabalho executadas no EKS. As identidades de pod do EKS simplificam a configuração dos recursos da AWS, pois você não precisa mais gerenciar as configurações do OIDC para entregar as credenciais da AWS aos seus pods no EKS.

Habilitando o EKS Pod Identities para acesso entre contas

Ao contrário do IRSA, o EKS Pod Identities só pode ser usado para conceder acesso direto a uma função na mesma conta do cluster EKS. Para acessar uma função em outra conta da AWS, os pods que usam o EKS Pod Identities devem realizar o encadeamento de funções.

O encadeamento de funções pode ser configurado em um perfil de aplicativos com seu arquivo de configuração da AWS usando o Process Credentials Provider disponível em várias AWS. SDKs credential_processpode ser usado como fonte de credencial ao configurar um perfil, como:

# Content of the AWS Config file
[profile account_b_role]
source_profile = account_a_role
role_arn = arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
credential_process = /eks-credential-processrole.sh

A fonte do script chamado por credential_process:

#!/bin/bash
# Content of the eks-credential-processrole.sh
# This will retreive the credential from the pod identities agent,
# and return it to the AWS SDK when referenced in a profile
curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'

Você pode criar um arquivo de configuração aws conforme mostrado acima com as funções da Conta A e B e especificar as variáveis AWS_CONFIG_FILE e AWS_PROFILE env na especificação do seu pod. O webhook de identidade do EKS Pod não será substituído se os env vars já existirem na especificação do pod.

# Snippet of the PodSpec
containers:
  - name: container-name
    image: container-image:version
    env:
    - name: AWS_CONFIG_FILE
      value: path-to-customer-provided-aws-config-file
    - name: AWS_PROFILE
      value: account_b_role

Ao configurar políticas de confiança de funções para encadeamento de funções com identidades de pod do EKS, você pode referenciar atributos específicos do EKS como tags de sessão e usar o controle de acesso baseado em atributos (ABAC) para limitar o acesso às suas funções do IAM somente a sessões de identidade específicas do EKS Pod, como a conta de serviço do Kubernetes à qual um pod pertence.

Observe que alguns desses atributos podem não ser universalmente exclusivos, por exemplo, dois clusters EKS podem ter namespaces idênticos e um cluster pode ter contas de serviço com nomes idênticos em todos os namespaces. Portanto, ao conceder acesso via EKS Pod Identities e ABAC, é uma prática recomendada sempre considerar o arn e o namespace do cluster ao conceder acesso a uma conta de serviço.

Identidades ABAC e EKS Pod para acesso entre contas

Ao usar o EKS Pod Identities para assumir funções (encadeamento de funções) em outras contas como parte de uma estratégia de várias contas, você tem a opção de atribuir uma função exclusiva do IAM para cada conta de serviço que precisa acessar outra conta ou usar uma função comum do IAM em várias contas de serviço e usar o ABAC para controlar quais contas ela pode acessar.

Para usar o ABAC para controlar quais contas de serviço podem assumir uma função em outra conta com o encadeamento de funções, você cria uma declaração de política de confiança de função que só permite que uma função seja assumida por uma sessão de função quando os valores esperados estão presentes. A política de confiança de função a seguir só permitirá que uma função da conta de cluster do EKS (ID da conta 111122223333) assuma uma função se todas as kubernetes-namespace tags eks-cluster-arn e tiverem o kubernetes-service-account valor esperado.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

Ao usar essa estratégia, é uma prática recomendada garantir que a função comum do IAM tenha apenas sts:AssumeRole permissões e nenhum outro acesso à AWS.

Ao usar o ABAC, é importante que você controle quem tem a capacidade de marcar funções e usuários do IAM somente para aqueles que têm uma necessidade estrita de fazer isso. Alguém com a capacidade de marcar uma função ou usuário do IAM seria capaz de definir tags roles/users idênticas às definidas pelo EKS Pod Identities e poderia escalar seus privilégios. Você pode restringir quem tem acesso para definir tags e tags na função kubernetes- e eks- nos usuários do IAM usando a política do IAM ou a Política de Controle de Serviços (SCP).

Clusters EKS descentralizados

Nessa abordagem, os clusters EKS são implantados nas respectivas contas de carga de trabalho da AWS e coexistem com outros recursos da AWS, como buckets do Amazon S3, tabelas do VPCs Amazon DynamoDB etc. Cada conta de carga de trabalho é independente, autossuficiente e operada pelo respectivo cluster de Unit/Application teams. This model allows the creation of reusuable blueprints for various cluster capabilities — AI/ML negócios, processamento em lote, uso geral etc., e vende os clusters com base nos requisitos da equipe de aplicativos. As equipes de aplicativos e plataformas operam em seus respectivos GitOpsrepositórios para gerenciar as implantações nos clusters de carga de trabalho.

No diagrama acima, os clusters do Amazon EKS e outros recursos da AWS são implantados nas respectivas contas de carga de trabalho. Em seguida, as cargas de trabalho executadas em pods EKS usam IRSA ou EKS Pod Identities para acessar seus recursos da AWS.

GitOps é uma forma de gerenciar a implantação de aplicativos e infraestrutura para que todo o sistema seja descrito declarativamente em um repositório Git. É um modelo operacional que oferece a capacidade de gerenciar o estado de vários clusters Kubernetes usando as melhores práticas de controle de versão, artefatos imutáveis e automação. Nesse modelo de vários clusters, cada cluster de carga de trabalho é inicializado com vários repositórios Git, permitindo que cada equipe (aplicativo, plataforma, segurança etc.) implemente suas respectivas alterações no cluster.

Você utilizaria funções do IAM para contas de serviço (IRSA) ou identidades de pod do EKS em cada conta para permitir que suas cargas de trabalho do EKS obtivessem credenciais temporárias da AWS para acessar com segurança outros recursos da AWS. As funções do IAM são criadas nas respectivas contas da AWS de carga de trabalho e as mapeiam para as contas de serviço k8s para fornecer acesso temporário ao IAM. Portanto, nenhum acesso entre contas é necessário nessa abordagem. Siga a documentação das funções do IAM para contas de serviço sobre como configurar em cada carga de trabalho do IRSA e a documentação do EKS Pod Identities sobre como configurar as identidades de pod do EKS em cada conta.

Rede centralizada

Você também pode utilizar a AWS RAM para compartilhar as sub-redes da VPC com contas de carga de trabalho e lançar clusters do Amazon EKS e outros recursos da AWS nelas. Isso permite gerenciamento/administração de rede centralizados, conectividade de rede simplificada e clusters EKS descentralizados. Consulte este blog da AWS para ver um passo a passo detalhado e considerações sobre essa abordagem.

No diagrama acima, a AWS RAM é usada para compartilhar sub-redes de uma conta de rede central em uma conta de carga de trabalho. Em seguida, o cluster EKS e outros recursos da AWS são lançados nessas sub-redes nas respectivas contas de carga de trabalho. Os pods EKS usam IRSA ou EKS Pod Identities para acessar seus recursos da AWS.

Clusters EKS centralizados versus descentralizados

A decisão de executar com um sistema centralizado ou descentralizado dependerá de seus requisitos. Esta tabela demonstra as principais diferenças com cada estratégia.

#	Cluster EKS centralizado	Clusters EKS descentralizados
Gerenciamento de clusters:	Gerenciar um único cluster EKS é mais fácil do que administrar vários clusters	Uma automação eficiente do gerenciamento de clusters é necessária para reduzir a sobrecarga operacional do gerenciamento de vários clusters EKS
Eficiência de custos:	Permite a reutilização do cluster e dos recursos de rede do EKS, o que promove a eficiência de custos	Requer configurações de rede e cluster por carga de trabalho, o que requer recursos adicionais
Resiliência:	Várias cargas de trabalho no cluster centralizado podem ser afetadas se um cluster for prejudicado	Se um cluster for prejudicado, o dano será limitado somente às cargas de trabalho executadas nesse cluster. Todas as outras cargas de trabalho não são afetadas
Isolamento e segurança:	A multilocação isolada/flexível é obtida usando construções nativas do k8s, como. Namespaces As cargas de trabalho podem compartilhar os recursos subjacentes, como CPU, memória etc. Os recursos da AWS são isolados em suas próprias contas de carga de trabalho que, por padrão, não são acessíveis a partir de outras contas da AWS.	Maior isolamento dos recursos computacionais, pois as cargas de trabalho são executadas em clusters e nós individuais que não compartilham nenhum recurso. Os recursos da AWS são isolados em suas próprias contas de carga de trabalho que, por padrão, não são acessíveis a partir de outras contas da AWS.
Desempenho e escalabilidade:	À medida que as cargas de trabalho crescem em escalas muito grandes, você pode encontrar kubernetes e cotas de serviços da AWS na conta do cluster. Você pode implantar contas de cluster adicionais para escalar ainda mais	À medida que mais clusters VPCs estão presentes, cada carga de trabalho tem mais k8s disponíveis e cota de serviços da AWS
Redes:	Uma única VPC é usada por cluster, permitindo uma conectividade mais simples para aplicativos nesse cluster	O roteamento deve ser estabelecido entre o cluster EKS descentralizado VPCs
Gerenciamento de acesso ao Kubernetes:	É necessário manter muitas funções e usuários diferentes no cluster para fornecer acesso a todas as equipes de carga de trabalho e garantir que os recursos do Kubernetes sejam segregados adequadamente	Gerenciamento de acesso simplificado, pois cada cluster é dedicado a uma carga de trabalho/equipe
Gerenciamento de acesso da AWS:	Os recursos da AWS são implantados em sua própria conta, que só pode ser acessada por padrão com funções do IAM na conta de carga de trabalho. As funções do IAM nas contas de carga de trabalho são assumidas em várias contas com IRSA ou EKS Pod Identities.	Os recursos da AWS são implantados em sua própria conta, que só pode ser acessada por padrão com funções do IAM na conta de carga de trabalho. As funções do IAM nas contas de carga de trabalho são entregues diretamente aos pods com IRSA ou EKS Pod Identities