Uma análise aprofundada dos controles simplificados de gerenciamento de acesso do Amazon EKS

Por Sheetal Joshi e Mike Stefaniak. Traduzido ao Português por Daniel Abib.

Introdução

Desde o lançamento inicial do Amazon Elastic Kubernetes Service (Amazon EKS), ele tem permitido entidades principais (principals entities) do AWS Identity and Access Management (AWS IAM) como entidades que podem se autenticar em um cluster. Isso foi feito para remover a carga — dos administradores — de ter que manter um provedor de identidade separado. O uso do AWS IAM também permite que os clientes da AWS usem seu conhecimento e experiência no AWS IAM e permite que os administradores usem os recursos de segurança do AWS IAM, como o registro de auditoria e a autenticação multifatorial do AWS CloudTrail.

Até agora, os administradores usavam as APIs do Amazon EKS para criar clusters e, em seguida, migravam para a API Kubernetes para gerenciar mapeamentos dos principals entities do AWS IAM e suas permissões do Kubernetes. Esse processo manual e de várias etapas complicou a forma como os usuários receberam acesso aos clusters do Amazon EKS. Isso impediu que os administradores revogassem as permissões cluster-admin [tipo root] do principal usado para criar o cluster. A necessidade de fazer chamadas para diferentes APIs (AWS e Kubernetes) para gerenciar o acesso também aumentou a probabilidade de configuração incorreta.

Visão geral dos recursos

A equipe do Amazon EKS aprimorou a experiência do usuário de autenticação (AuthN) e autorização (AuthZ) do cluster com controles aprimorados de gerenciamento de acesso ao cluster. Na data desta publicação, os administradores de cluster agora podem conceder aos diretores do AWS IAM acesso a todas as versões suportadas (v1.23 e posteriores) dos clusters e objetos do Kubernetes do Amazon EKS diretamente por meio das APIs do Amazon EKS. Essa nova funcionalidade se baseia em dois novos conceitos: entradas de acesso e políticas de acesso. Uma entrada de acesso é uma identidade de cluster — diretamente vinculada a um usuário ou função principal do AWS IAM — que é usada para autenticação em um cluster Amazon EKS. Uma política de acesso do Amazon EKS autoriza uma entrada de acesso a realizar ações específicas do cluster.

API de gerenciamento de acesso ao cluster

Os novos objetos e comandos da API de gerenciamento de acesso ao cluster permitem que os administradores definam configurações de gerenciamento de acesso, inclusive durante a criação do cluster, usando ferramentas familiares de infraestrutura como código (IaC), como AWS CloudFormation, Terraform ou o AWS Cloud Development Kit (CDK).

Os controles aprimorados de gerenciamento de acesso do cliente permitem que os administradores removam ou refinem completamente as permissões concedidas automaticamente ao diretor do AWS IAM usadas para criar o cluster. Se ocorrer uma configuração incorreta, o acesso ao cluster pode ser restaurado simplesmente chamando uma API do Amazon EKS, desde que o chamador tenha as permissões necessárias. O objetivo desses novos controles é reduzir a sobrecarga associada à concessão de acesso de usuários e aplicativos a clusters e objetos dentro desses clusters.

Nota: sempre recomendamos que as funções do AWS IAM sejam usadas como principals para criar clusters do Amazon EKS. As funções fornecem uma camada de indireção que dissocia os usuários das permissões. Os usuários podem ser removidos das funções sem precisar ajustar as políticas do AWS IAM que fornecem permissões para as funções do criador do cluster.

Autorizadores do Kubernetes

As políticas de acesso são políticas específicas do Amazon EKS que atribuem permissões do Kubernetes para acessar entradas. No lançamento, o Amazon EKS oferece suporte somente a políticas predefinidas e gerenciadas pela AWS. As políticas de acesso não são entidades do AWS IAM e são definidas e gerenciadas pelo Amazon EKS.

No Kubernetes, diferentes serviços AuthZ, conhecidos como autorizadores, são encadeados em uma sequência para tomar decisões do AuthZ sobre solicitações de entrada do servidor de API. Isso permite que serviços AuthZ personalizados sejam usados com o servidor da API Kubernetes. O novo recurso permite que você use o RBAC (controle de acesso baseado em função) upstream em combinação com políticas de acesso. Tanto o RBAC upstream quanto o autorizador Amazon EKS oferecem suporte para permitir e aprovar (mas não negar) as decisões do AuthZ. Ao criar uma entrada de acesso com nomes de usuário ou grupos do Kubernetes, o RBAC upstream avalia e retorna imediatamente uma decisão do AuthZ sobre um resultado de permissão. Se o autorizador do RBAC não puder determinar o resultado, ele passará a decisão para o autorizador do Amazon EKS. Se os dois autorizadores forem aprovados, a decisão de negação será retornada.

Passo a passo

Começando

O gerenciamento de acesso ao cluster usando a API de entrada de acesso é um recurso opcional para o Amazon EKS v1.23 e para clusters novos ou existentes. Por padrão, o Amazon EKS usa a versão mais recente da plataforma Amazon EKS quando você cria um novo cluster. O Amazon EKS atualiza automaticamente todos os clusters existentes para a versão mais recente da plataforma Amazon EKS para a versão secundária correspondente do Kubernetes. Você pode usar novos controles de gerenciamento de acesso ao cluster quando atualizações automáticas das versões da plataforma são implementadas nos clusters existentes. Ou você pode atualizar seu cluster para a próxima versão secundária compatível do Kubernetes para aproveitar esse recurso.

Para começar a usar esse recurso, os administradores de cluster criam entradas de acesso ao Amazon EKS com os principals do AWS IAM desejados. Consulte o controle de políticas do IAM para entradas de acesso para configurar a permissão do AWS IAM para administradores. Depois que essas entradas de acesso são criadas, os administradores podem conceder acesso a essas entradas atribuindo políticas de acesso. As políticas de acesso do Amazon EKS incluem conjuntos de permissões que oferecem suporte a casos de uso comuns de administração, edição ou acesso somente de leitura aos recursos do Kubernetes.

O comando e a saída a seguir fornecem uma lista atualizada das políticas de acesso suportadas para gerenciar o acesso ao cluster:

# List all access policies
$ 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"
        }
    ]
}

As seguintes políticas de acesso do Amazon EKS são baseadas nessas funções voltadas para o usuário publicadas na documentação do Kubernetes:

Política de administração de cluster do Amazon EKS — cluster-admin
Política de administrador do AmazonEKS — administrador
Política de edição do AmazonEKSEditPolicy — editar
Política de visualização do AmazonEKS — visualizar

Com os controles de gerenciamento de acesso ao cluster, somente diretores do AWS IAM com as permissões apropriadas podem autorizar outros diretores do AWS IAM a acessar clusters do Amazon EKS. A permissão é concedida criando entradas de acesso e associando políticas de acesso a essas entradas de acesso. Esteja ciente de que o acesso concedido aos diretores do AWS IAM pelas políticas de acesso do Amazon EKS é separado das permissões definidas por qualquer política do AWS IAM associada ao diretor do AWS IAM.

Resumindo, somente o principal do AWS IAM e as políticas de entrada de acesso do Amazon EKS aplicadas são usadas pelo autorizador de gerenciamento de acesso ao cluster. O diagrama a seguir ilustra o fluxo de trabalho:

Nas próximas seções, exploraremos vários casos de uso que agora são possíveis por meio das novas APIs de gerenciamento de acesso ao cluster do Amazon EKS.

Crie ou atualize um cluster para usar a API de gerenciamento de acesso

Com a introdução desse recurso, o Amazon EKS oferece suporte a três modos de autenticação: CONFIG_MAP, API_AND_CONFIG_MAP e API. Você pode permitir que o cluster use APIs de entrada de acesso usando a API AuthenticationMode ou API_AND_CONFIG_MAP. Use AuthenticationMode CONFIG_MAP para continuar usando o aws-auth ConfigMap exclusivamente. Quando API_AND_CONFIG_MAP estiver habilitado, o cluster fornecerá diretores autenticados do AWS IAM das APIs de entrada de acesso do Amazon EKS e do aws-auth ConfigMap, com prioridade dada à API de entrada de acesso.

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

O gerenciamento de acesso ao cluster do Amazon EKS agora é o meio preferencial para gerenciar o acesso dos diretores do AWS IAM aos clusters do Amazon EKS. Embora tenhamos tornado o gerenciamento de acesso mais fácil e seguro, fizemos isso sem interromper as operações do cluster ou as configurações atuais. Com essa abordagem, você pode explorar o gerenciamento de acesso ao cluster de acordo com suas necessidades e planejar migrações subsequentes para o gerenciamento de acesso ao cluster quando melhor se adequar à sua agenda.

O Amazon EKS sugere atualizar os clusters existentes para usar o AuthenticationMode API_AND_CONFIG_MAP e criar entradas de acesso equivalentes especificando a mesma identidade e/ou grupos usados no aws-auth ConfigMap. Quando API_AND_CONFIG_MAP estiver habilitado, o cluster fornecerá diretores autenticados do AWS IAM a partir das APIs de entrada de acesso do Amazon EKS e do aws-auth ConfigMap, com a API de entrada de acesso tendo precedência. Quando você define AuthenticationMode como API_AND_CONFIG_MAP, para autenticação, uma entrada de acesso é avaliada antes de um mapa de configuração junto com qualquer nome de usuário e grupos associados. Quando nenhuma entrada de acesso é criada para o principal, o ConfigMap é inspecionado quanto à presença de um principal e seu nome de usuário e grupos associados.

Você pode atualizar a configuração existente do cluster para ativar o API AuthenticationMode. Certifique-se de que a versão da plataforma esteja atualizada antes de executar o comando update-cluster-config. Para clusters existentes usando CONFIG_MAP, você precisará primeiro atualizar o AuthenticationMode para API_AND_CONFIG_MAP e depois para API.

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

Alternar os modos de autenticação em um cluster existente é uma operação unidirecional. Você pode mudar de CONFIG_MAP para API_AND_CONFIG_MAP. Em seguida, você pode mudar de API_AND_CONFIG_MAP para API. Você não pode reverter essas operações na direção oposta. Isso significa que você não pode voltar para CONFIG_MAP ou API_AND_CONFIG_MAP da API. E você não pode voltar para CONFIG_MAP a partir de API_AND_CONFIG_MAP.

Removendo o administrador de cluster padrão

Até agora, quando um cluster Amazon EKS era criado, o principal usado para provisionar o cluster recebia permanentemente privilégios de administrador de cluster do Kubernetes. A partir desse cenário, surgiu a melhor prática de usar uma função do AWS IAM para criar clusters do Amazon EKS. O uso de uma função do AWS IAM forneceu uma camada (layer-of-indirection) para controlar quem poderia assumir a função usando o AWS IAM. Ao remover a capacidade de assumir a função ou remover a função completamente, você pode revogar o acesso de um usuário ao cluster.

Na data desta publicação, os clusters podem ser criados com o diretor do AWS IAM de sua escolha ou sem nenhuma permissão. O exemplo abaixo usa o sinalizador bootstrapClusterCreatorAdminPermissions=false para access-config para impedir que o principal — usado para criar o cluster — receba acesso de administrador do cluster.

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

Para verificar se não existem entradas de acesso para o cluster, o seguinte comando da AWS CLI pode ser usado para listar as entradas de acesso ao cluster existentes:

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

{
    "accessEntries": []
}

Se tentarmos usar o AWS IAM principal com o comando kubectl auth can-i —list, veremos que o principal, mesmo com um arquivo de configuração do kube config corretamente, não está autenticado no cluster:

# Verify cluster creator cannot access cluster
$ kubectl auth can-i --list
error: You must be logged in to the server (Unauthorized)

Para remover a função de administrador do criador do cluster de um cluster existente, execute o comando a seguir na entrada de acesso associada, que aparecerá depois que você atualizar seu cluster para um modo de autenticação compatível com a entrada de acesso.

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

Adicionar administradores de cluster aos clusters existentes

Agora que vimos como lidar com um administrador de cluster durante a criação do cluster, exploraremos como adicionar administradores de cluster aos clusters existentes. Os seguintes comandos da AWS CLI podem ser usados para realizar as seguintes tarefas:

Crie uma entrada de acesso ao cluster para receber o acesso do administrador do cluster
Associe a política de acesso do administrador do cluster à entrada de acesso ao cluster mencionada anteriormente

# Create cluster access entry
$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>
  
{
    "accessEntry": {
        "clusterName": "<value>",
        "principalArn": "<value>",
        "kubernetesGroups": [],
        "accessEntryArn": "<ACCESS_ENTRY_ARN>",
        "createdAt": "2023-03-30T21:38:24.185000-04:00",
        "modifiedAt": "2023-03-30T21:38:24.185000-04:00",
        "tags": {},
        "username": "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/<ROLE_NAME>/{{SessionName}}"
    }
}

Com a entrada de acesso criada e vinculada a um principal do AWS IAM, a AmazonEKSClusterAdminPolicy é atribuída executando o seguinte comando da AWS CLI. Como estamos criando uma entrada de administrador de cluster, definimos o argumento —access-scope type=cluster no comando:

# Associate access policy to access entry
$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
  --access-scope type=cluster
  
  {
    "clusterName": "<CLUSTER_NAME>",
    "principalArn": "<AWS_IAM_PRINCIPAL_ARN>",
    "associatedAccessPolicy": {
        "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy",
        "accessScope": {
            "type": "cluster",
            "namespaces": []
        },
        "associatedAt": "2023-04-03T13:44:09.788000-04:00",
        "modifiedAt": "2023-04-03T13:44:09.788000-04:00"
    }
}

Adicionando administradores de namespace

Os administradores de namespaces têm permissões de administrador que se destinam a namespaces específicos. Eles não conseguem criar recursos com escopo de cluster, como namespaces. Para ilustrar esse caso de uso, criaremos uma entrada de acesso com base em uma função do AWS IAM somente para leitura. Essa função somente para leitura tem acesso somente para leitura à conta subjacente da AWS. Embora esse exemplo possa parecer artificial, ele ilustra a diferença entre as políticas do AWS IAM e as políticas de acesso ao cluster do Amazon EKS. Para referência, a função ReadOnly tem uma política do AWS IAM anexada — arn:aws:iam: :aws:policy/ReadOnlyAccess — que dá à função acesso somente de leitura à conta subjacente da AWS.

# Create access entry
$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly

  {
    "accessEntry": {
        "clusterName": "<CLUSTER_NAME>",
        "principalArn": "<IAM_PRINCIPAL_ARN>",
        "kubernetesGroups": [],
        "accessEntryArn": "arn:aws:eks:<REGION>:<AWS_ACCOUNT_ID>:accessEntry/<CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/ReadOnly/40c3cb02-38ed-3edc-4f8c-0043d4639029",
        "createdAt": "2023-04-18T16:18:06.556000-04:00",
        "modifiedAt": "2023-04-18T16:18:06.556000-04:00",
        "tags": {},
        "username": "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/ReadOnly/{{SessionName}}"
    }
}

O comando acima criou uma entrada de acesso ao cluster sustentada pela função ReadOnly AWS IAM mencionada anteriormente. Em seguida, associaremos a AmazonEksAdminPolicy à entrada de acesso recém-criada.

# Associate access policy to access entry
$ aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy \
  --access-scope type=namespace,namespaces=test*

  {
    "clusterName": "<CLUSTER_NAME>",
    "principalArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly",
    "associatedAccessPolicy": {
        "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
        "accessScope": {
            "type": "namespace",
            "namespaces": [
                "test*"
            ]
        },
        "associatedAt": "2023-04-18T16:42:57.754000-04:00",
        "modifiedAt": "2023-04-18T16:42:57.754000-04:00"
    }
}

Depois de executar esse comando, a função AWS IAM ReadOnly, que só tem acesso somente de leitura à conta subjacente da AWS, agora tem acesso de administrador de namespace aos namespaces test*.

# Namespace admin cannot access namespaces not on the allowed list
$ kubectl -n kube-system get pods
Error from server (Forbidden): pods is forbidden: 
User "arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/ReadOnly/<SESSION_ID>" 
cannot list resource "pods" in API group "" in the namespace "kube-system"

# Namespace admin can access namespaces on the allowed list
# This step assumes the namespaces exist, use clusteradmin to create these roles
# kubectl create ns test-1
$ kubectl auth can-i get pods -n test-1
yes

# Namespace admin can create pods in test1
$ kubectl create deployment nginx --image=nginx -n test-1
deployment.apps/nginx created

Adicionar usuários com acesso somente para leitura

Para começar com esse caso de uso, usamos a função existente de somente leitura do AWS IAM que usamos no caso de uso anterior. Para fazer isso, precisamos desassociar a política de acesso existente. Os comandos a seguir removem a política de acesso da entrada de acesso do administrador do namespace e, em seguida, listam todas as políticas associadas à entrada de acesso.

# Disassociate access policy from access entry
aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
--principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy

# List associated access policies to access entry
aws eks list-associated-access-policies --cluster-name <CLUSTER_NAME> \
--principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly
{
    "clusterName": "<CLUSTER_NAME>",
    "principalArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly",
    "associatedAccessPolicies": []
}

Como você pode ver, com os comandos anteriores, desassociamos a política de acesso que concedia à nossa função de namespace de leitura somente para leitura do AWS IAM acesso de administrador ao cluster. Com os comandos a seguir, associaremos a AmazonEksViewPolicy à entrada de acesso para fornecer acesso somente de leitura em todo o cluster à função principal do AWS IAM e, em seguida, verificaremos se a entrada de acesso tem acesso somente leitura em todo o cluster.

# Associate access policy to access entry
aws eks associate-access-policy --cluster-name <CLUSTER_NAME> \
  --principal-arn arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=cluster
{
    "clusterName": "<CLUSTER_NAME>",
    "principalArn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ReadOnly",
    "associatedAccessPolicy": {
        "policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
        "accessScope": {
            "type": "cluster",
            "namespaces": []
        },
        "associatedAt": "2023-04-20T10:08:17.503000-04:00",
        "modifiedAt": "2023-04-20T10:08:17.503000-04:00"
    }
}

# Cluster read-only user can GET pods in kube-system namespace
kubectl -n kube-system get po
NAME                       READY   STATUS    RESTARTS   AGE
aws-node-b9cpr             1/1     Running   0          2d20h
...

# Cluster read-only user can GET pods in test1 namespace
kubectl -n test1 get po
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7854ff8877-wnzfs   1/1     Running   0          47s

# Cluster read-only user cannot DELETE pods in test1 namespace
kubectl -n test1 delete deployment nginx
Error from server (Forbidden): error when deleting "nginx": deployment
"nginx" is forbidden: User 
"arn:aws:sts::<AWS_ACCOUNT_ID>:assumed-role/ReadOnly/<SESSION_ID>" 
cannot delete resource "deployments" in API group in the namespace "test1"

Usando entradas de acesso ao cluster com o Kubernetes Role Base Access Control (RBAC)

Conforme mencionado anteriormente, os controles de gerenciamento de acesso ao cluster e as APIs associadas não substituem o autorizador RBAC existente no Amazon EKS. Em vez disso, as entradas de acesso do Amazon EKS podem ser combinadas com o autorizador do RBAC para conceder acesso ao cluster a um principal do AWS IAM e, ao mesmo tempo, contar com o RBAC do Kubernetes para aplicar as permissões desejadas.

Por exemplo, o seguinte comando da API Amazon EKS cria uma entrada de acesso ao cluster e, posteriormente, adiciona um grupo Kubernetes a essa entrada. O comando kubectl apply aplica um recurso de vinculação de função de cluster que vincula o grupo Kubernetes ao recurso de função de cluster cluster-admin. O resultado é uma entrada de acesso ao cluster com permissões concedidas usando o Kubernetes RBAC.

# Create cluster access entry
$ aws eks create-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN> \
  --kubernetes-groups eks-admins
  
# Apply cluster role binding
# This command assumes you have created crb.yaml from the yaml out of below command
$ kubectl apply -f crb.yaml

# Get newly created cluster role binding
$ kubectl get cluster-admin-ae
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-ae
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: eks-admins

Você pode usar o comando kubectl auth can-i —list para verificar se a entrada de acesso ao cluster tem permissões de administrador do cluster e pode realizar todas as ações em todos os recursos do Kubernetes.

# List Kubernetes permissions for authenticated user
$ kubectl auth can-i --list
...
Resources                                       Non-Resource URLs   Resource Names   Verbs
*.*                                             []                  []               [*]
                                                [*]                 []               [*]
...

Excluindo o AWS IAM principal abaixo da entrada de acesso

A referência de uma entrada de acesso ao cluster ao seu principal AWS IAM subjacente é exclusiva, conforme visto no AccessEntryArn no seguinte trecho de saída de create-access-entry:

"accessEntryArn": "arn:aws:eks:us-west-2:<AWS_ACOUNT_ID>:accessEntry/<CLUSTER_NAME>/role/<AWS_ACCOUNT_ID>/ekstest/c8c3cfab-ad74-8943-9741-1297bb3885b6",

Depois que uma entrada de acesso é criada, o principal subjacente do AWS IAM não pode ser alterado, mantendo o acesso ao cluster. A entrada de acesso e as políticas de acesso associadas devem ser recriadas. No cenário a seguir, as seguintes etapas de configuração foram concluídas:

Uma função do AWS IAM chamada ekstest foi criada
Uma entrada de acesso ao cluster foi criada usando a função ekstest
O acesso ao cluster AmazonEksViewPolicy foi associado à entrada de acesso sustentada pela função ekstest do AWS IAM.

Após a configuração, o acesso foi verificado:

# Use whoami to get authenticated principal
$ kubectl whoami
arn:aws:sts::<AWS_CLUSTER_ID>:assumed-role/ekstest/<SESSION_NAME>

# GET pods from kube-system namespace
kubectl -n kube-system get po
NAME                       READY   STATUS    RESTARTS   AGE
aws-node-b9cpr             1/1     Running   0          2d22h
...

O plug-in kubectl whoami indica o principal do cluster Kubernetes atualmente autenticado.

Em seguida, a função ekstest do AWS IAM foi excluída, recriada e reutilizada para autenticação no cluster Amazon EKS. Os comandos a seguir mostram que, embora a função ekstest do AWS IAM tenha sido autenticada com sucesso no cluster Amazon EKS, a entrada de acesso não autoriza mais a nova instância da função ekstest:

# Use whoami to get authenticated principal
kubectl whoami
Error: Unauthorized

# Fail to GET pods from the kube-system namespace
kubectl -n kube-system  get po
error: You must be logged in to the server (Unauthorized)

A nova função ekstest pode ter a mesma aparência, com o mesmo ARN, mas o RoleID — retornado pelo comando aws iam get-role a seguir — é diferente. Esse RoleID — ID de usuário no caso de um usuário principal — é usado pelo armazenamento de dados de entrada de acesso ao cluster para vincular a entrada de acesso à função do AWS IAM ou ao usuário principal.

Observação: devido à separação das permissões da interface de linha de comando (CLI) do Amazon EKS e do AWS IAM, a API do Amazon EKS não expõe os identificadores principais do AWS IAM — RoleID ou UserID — usados para referenciar os principals do AWS IAM.

# Get AWS IAM role
$ aws iam get-role --role-name ekstest
{
    "Role": {
        "Path": "/",
        "RoleName": "ekstest",
        "RoleId": "<ROLE_ID>",
        "Arn": "arn:aws:iam::<AWS_ACCOUNT_ID>:role/ekstest",
...
}

Para evitar um comportamento não determinístico e evitar configurações de segurança incorretas, a melhor prática para alterar ou recriar o princípio subjacente do AWS IAM é primeiro excluir a entrada de acesso do cluster específico do Amazon EKS por meio do comando delete-access-entry. Então, quando o principal do AWS IAM é excluído e recriado, a entrada de acesso pode ser recriada e as políticas de acesso necessárias podem ser associadas.

Conclusão

O gerenciamento de acesso ao cluster do Amazon EKS agora é o meio preferencial para gerenciar o acesso dos diretores do AWS IAM aos clusters do Amazon EKS. Com o gerenciamento de acesso ao cluster, você pode continuar aproveitando os principais mantidos pelo AWS IAM, como entradas de acesso ao Amazon EKS, e aplicar permissões do Kubernetes com políticas de acesso ao cluster. O gerenciamento de acesso ao cluster usa abordagens de API padrão para estender o modelo Kubernetes AuthZ com autorizadores do Amazon EKS. Juntos, o grande conjunto de recursos de gerenciamento de acesso ao cluster fornece integração com o AWS IAM sem interromper os esquemas de segurança existentes do Kubernetes usados atualmente no Amazon EKS. Seus esquemas RBAC do Kubernetes ainda funcionarão, mas você não precisará mais editar o aws-auth ConfigMap.

Com o gerenciamento de acesso ao cluster, você também pode remover o criador do cluster recém-criados sem perder o acesso ao cluster. Esse recurso fornece melhores práticas de DevSecOps por meio de automação e acesso menos privilegiado e baseado em tempo.

Embora o uso do gerenciamento de acesso ao cluster permita uma integração mais clara com os diretores do AWS IAM para AuthN, as permissões AuthZ são separadas do AWS IAM e são modeladas com base em permissões conhecidas do Kubernetes. Isso significa que, embora você possa usar o AWS IAM para gerenciar seus diretores do AuthN, suas permissões do Amazon EKS são separadas das suas permissões do AWS IAM. O resultado é um modelo AuthZ mais flexível em que as permissões do AWS IAM não afetam as permissões de cluster do Amazon EKS.

Por fim, o gerenciamento de acesso ao cluster permite que os administradores do Amazon EKS usem a API do Amazon EKS para gerenciamento do acesso ao cluster sem precisar mudar para a API Kubernetes local para realizar as configurações de AuthZ de última milha para permissões de usuário do cluster. Essa também é uma abordagem melhor para processos automatizados — pipelines de DevSecOps — que criam e atualizam clusters do Amazon EKS.

Experimente o gerenciamento de acesso ao cluster!

Se você está procurando um substituto para evitar o aws-auth ConfigMap e usar as abordagens AuthZ padrão do Kubernetes, experimente o gerenciamento de acesso ao cluster. Você pode executar os dois modelos em conjunto, com uma transição baseada em suas necessidades e cronograma, para o mínimo de interrupção em suas operações do Amazon EKS.

Em uma versão futura do Kubernetes do Amazon EKS, o aws-auth ConfigMap será removido como uma fonte de autenticação compatível, portanto, é altamente recomendável migrar para entradas de acesso.

Confira nosso roteiro de contêineres!

Se você tiver ideias sobre como podemos melhorar o Amazon EKS e nossos outros serviços de contêineres, use nosso roteiro de contêineres, forneça feedback e analise nossos itens de roteiro existentes.

Esse blog foi traduzido para o Português e o conteúdo original pode ser acessado aqui.

Biografia dos Autores

Sheetal Joshi é a principal defensora de desenvolvedores na equipe do Amazon EKS. Sheetal trabalhou para vários fornecedores de software antes de ingressar na AWS, incluindo HP, McAfee, Cisco, Riverbed eMoogsoft. Por cerca de 20 anos, ela se especializou na criação de sistemas de software distribuídos em escala empresarial, tecnologias de virtualização e arquiteturas de nuvem. No momento, ela está trabalhando para facilitar o início, a adoção e a execução de clusters Kubernetes na nuvem, no local e na borda.

Mike Stefaniak é gerente de produto principal da Amazon Web Services, com foco em tudo relacionado ao Kubernetes e fornecendo recursos que ajudam os clientes a acelerar sua jornada de modernização na AWS.

Biografia do Tradutor

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/

O blog da AWS