Introdução
Quando você está construindo um cluster AKS para seu time, uma das primeiras perguntas que você precisa fazer é:
- Como você vai gerenciar o acesso aos diferentes grupos ou pessoas?
- Como ter algo simples de gerenciar, mas ainda seguro?
Ao utilizar o Portal do Azure para criar uma novo cluster do AKS, ele oferece as seguintes opções:
- Local accounts with Kubernetes RBAC
- Azure AD authentication with Kubernetes RBAC
- Azure AD authentication with Azure RBAC
Essas opções estão resumidas neste documento e em seus artigos referenciados. Se você ainda não tem tanta experiência com o Kubernetes e o Azure, a documentação oficial pode ser um pouco complexa. Este artigo tem como objetivo ajudá-lo a decidir qual opção é melhor para o seu caso e fornecer uma maneira “mais fácil” de entender a documentação oficial.
O Cenário
Vamos supor que você seja o administrador/owner do cluster, e esse novo cluster AKS será usado por muitas equipes de desenvolvedores diferentes para entregar seus aplicativos. Portanto, você está planejando:
- Criar um novo namespace no AKS para cada uma das equipes de desenvolvedores.
- Atribuir permissões de namespace a cada equipe. Em seguida, cada equipe de desenvolvimento é subdividida em 2 grupos:
- Grupo de usuários do namespace => pessoas aqui poderão implantar e editar aplicativos dentro do namespace, mas não atribuir acesso a outras pessoas
- Grupo de administradores de namespace => pessoas aqui poderão fazer tudo o que o grupo anterior faz, mas também atribuir/remover o acesso a outras pessoas dentro desse namespace. Isso é útil para que os principais Administradores de Cluster não precisem continuar gerenciando o acesso a todos os namespaces no cluster. Você delega isso para cada equipe.
Este é um cenário muito comum ao construir um cluster AKS que será compartilhado com outras equipes. Então como gerenciamos esse caso na prática em cada opção RBAC disponível no AKS?
Para dar valores reais ao cenário acima, aqui os detalhes que usaremos para o resto do artigo:
- Nome do Namespace : blog
- Grupo do Azure AD com permissão de cluster admin: aks-admins
- Grupo do Azure AD com permissão de namespace admin: aks-blog-admins
- Grupo do Azure AD com permissão de namespace user: aks-blog-users
Local accounts with Kubernetes RBAC
Com essa opção, não há integração entre o Active Directory do Azure e o cluster AKS. Isso significa que você não pode ter um grupo específico de usuários no AD mapeado para um namespace específico dentro do cluster AKS. Você precisa utilizar uma das maneiras nativas do Kubernetes, como usar certificados de cliente, bearer tokens, etc. Mais sobre isso aqui na documentação oficial. Ou, você também pode usar o comando Az CLI az aks get-credentials para buscar credenciais kubeconfig locais se você fizer parte de uma das roles internas do AKS, mas isso dará a todos os usuários o mesmo acesso (clusterAdmin ou clusterUser) dentro do cluster. Não há como diferenciar os usuários dentro do Kubernetes se o Azure AD não estiver habilitado ao usar esse método. Eu só recomendaria a criação de clusters com essa configuração se todos os usuários não estiverem no Azure AD e não tiverem como ser incluídos/convidados para, por algum motivo. O gerenciamento de usuários nesse cenário se torna muito desafiador. O servidor de API do Kubernetes suporta a integração com provedores OpenID Connect exatamente para facilitar o gerenciamento de usuários de fora do Kubernetes. Vamos colocar mais foco neste artigo nas outras duas opções com a integração do Azure AD habilitada.
Azure AD authentication with Kubernetes RBAC
A primeira opção com a integração do Azure AD faz com que o AKS delegue autenticação ao Azure AD, não autorização. Isso significa que o AKS confia no Azure AD em relação a “quem está fazendo logon”. Mas a lista de permissões (quais ações os usuários estão autorizados a fazer dentro do cluster AKS) ainda deve ser definida dentro do cluster e não no sistema de funções e permissões do Azure AD.
Eu sou uma pessoa que aprende principalmente por uma abordagem prática. Então, vamos tentar deixar as coisas mais claras do ponto de vista prático. Quais etapas precisam ser executadas em um cluster AKS para realizar o que descrevi no cenário acima?
Pré-requisitos
- Az CLI
- Kubectl
- Compreensão básica de usuários e grupos do Azure AD
- Verifique se você criou ou atualizou o cluster para usar o Azure AD e se o grupo de administradores está corretamente setado para utilizar o aks-admins. Mais sobre isso aqui
- Verifique se os grupos aks-blog-admins e aks-blog-admins têm permissão para buscar as credenciais do cluster usando “az aks get-credentials” acessando Portal do Azure => AKS => Access Control (IAM) e atribua a função “Azure Kubernetes Service Cluster User Role”
- Há um namespace chamado blog no cluster. Se você ainda não o tem, basta começar pegando suas credenciais kubectl usando az aks get-credentials usando um dos usuários admin do grupo aks-admins e, em seguida, use kubectl:
kubectl create namespace blogEtapas
- A próxima etapa é criar um arquivo YAML RoleBinding do Kubernetes com o seguinte exemplo:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: blog-admin-binding
namespace: blog
subjects:
- kind: Group
name: d89e6a33-eaca-4be4-b1e5-9f5c74d6a35c
#Azure AD group name: aks-blog-admins
namespace: blog
roleRef:
kind: ClusterRole
name: admin
apiGroup: rbac.authorization.k8s.ioAplique o manifesto YAML:
kubectl apply -f <<filename.yaml>>Preste atenção ao número de linha 8: essa é a ID do objeto de grupo do Azure AD. Isso significa que qualquer usuário nesse cluster que pertença a esse grupo obterá a função de administrador interna do Kubernetes (linha 13) para o namespace do blog (linha 10)
- Neste ponto, todos os usuários do grupo aks-blog-admins agora podem fazer login no cluster e ter direitos de acesso total ao namespace do blog. Agora, eles podem criar RoleBindings dentro desse namespace para atribuir permissões a outros usuários. Vamos atribuir acesso agora a um desenvolvedor que terá acesso total ao namespace do blog, exceto permissões para criar RoleBindings:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: blog-user-binding
namespace: blog
subjects:
- kind: Group
name: 996844bd-95a3-48fc-93e9-7f1f1177ff83
#Azure AD group name: aks-blog-users
namespace: blog
roleRef:
kind: ClusterRole
name: edit
apiGroup: rbac.authorization.k8s.ioAplique o manifesto YAML:
kubectl apply -f <<filename.yaml>>Observe que esse novo RoleBinding atribui a edição de função interna (linha 13) em vez de admin ao grupo aks-blog-users (linha 8).
- De agora em diante, a autorização é configurada corretamente dentro do cluster AKS. Você deve usar os grupos do Azure AD para gerenciar pessoas (adicionar e remover) dos grupos para o namespace fornecido. Uma coisa a observar em ambos os arquivos YAML é que não podemos usar o nome de grupo amigável do Azure AD, mas sempre a ID do objeto de grupo. É por isso que é recomendável que em seus arquivos YAML você adicione uma linha de comentário descrevendo o nome do grupo. Esteja ciente de que as linhas comentadas serão removidas pelo Kubernetes ao aplicar os manifestos no cluster, portanto, você precisará procurar nos arquivos de controle do código-fonte(Repositório).
Azure AD authentication with Azure RBAC
Em palavras simples, o RBAC do Azure levará a integração do Azure AD um passo adiante e cuidará da autenticação e da autorização dentro de um cluster AKS. Você não precisa criar nenhum manifesto YAML para gerenciar o acesso do usuário nos namespaces, por exemplo. A ideia aqui é funcionar de forma semelhante aos outros serviços do Azure usando apenas as funções do Azure AD (IAM). Novamente, para deixar as coisas mais claras, vamos replicar o mesmo cenário que fizemos anteriormente para o Kubernetes RBAC.
Pré-requisitos
- Az CLI
- Compreensão básica de usuários e grupos do Azure AD
- Verifique se você tem o cluster criado ou atualizado para usar o Azure AD e o Azure RBAC. Atribua a função do IAM “Azure Kubernetes Service RBAC Cluster Admin” ao grupo aks-admins. Consulte este documento para obter mais informações.
- Verifique se os grupos aks-blog-admins e aks-blog-admins têm permissão para buscar as credenciais de cluster usando “az aks get-credentials” acessando Portal do Azure => AKS => Access Control (IAM) e atribua a função “Azure Kubernetes Service Cluster User Role”.
- Há um namespace chamado blog no cluster. Se você ainda não o tem, basta começar pegando suas credenciais kubectl usando az aks get-credentials usando um dos usuários admin do grupo aks-admins e, em seguida, use kubectl:
kubectl create namespace blogEtapas
- A segunda etapa é atribuir outra função do IAM chamada “Azure Kubernetes Service RBAC Cluster Admin” a aks-blog-admins. No entanto, há um “problema”: você não pode usar o Portal e atribuir essa função usando o Controle de Acesso (IAM) do serviço AKS porque ele atribuirá essa função a todos os namespaces dentro do cluster, não apenas ao namespace do blog. Você precisa usar a CLI Az para atribuir esse RBAC Cluster Admin com escopo somente a um namespace específico:
az role assignment create --role "Azure Kubernetes Service RBAC Admin" --assignee <<groud-id for aks-blog-admins>> --scope /subscriptions/<<subscription>>/resourcegroups/<<rg>>/providers/Microsoft.ContainerService/managedClusters/<<cluster-name>>/namespaces/blogObserve que a propriedade –scope atribui essa função somente para o namespace do blog. Uma desvantagem para essa abordagem é que você também não pode ver essa atribuição de função no Portal. Você precisará utilizar a CLI Az para ver os escopos atribuídos para namespaces:
az role assignment list --scope /subscriptions/<<subscription>>/resourcegroups/<<rg>>/providers/Microsoft.ContainerService/managedClusters/<<cluster-name>>/namespaces/blog- Neste ponto, os usuários do grupo aks-blog-admins podem fazer login usando az aks get-credentials e podem executar quaisquer operações no namespace usando ferramentas como kubectl. Tudo bem, mas como eles podem gerenciar o acesso a outros usuários regulares não administradores para esse namespace e não depender das associações de funções YAML do Kubernetes para isso?
- Usando um usuário Owner para seu cluster, atribua a função do IAM “User Access Administrator” ao grupo aks-blog-admins e, em seguida, eles poderão atribuir funções do IAM a outros usuários para o cluster. Aqui temos o mesmo problema da etapa 2: se você usar o Portal, estará dando ao grupo direitos para gerenciar o acesso a todo o cluster. Você precisa usar novamente a CLI Az para atribuir essa função apenas para o namespace do blog:
az role assignment create --role "User Access Administrator" --assignee <<groud-id for aks-blog-admins>> --scope /subscriptions/<<subscription>>/resourcegroups/<<rg>>/providers/Microsoft.ContainerService/managedClusters/<<cluster-name>>/namespaces/blog- Agora, os usuários em aks-blog-admins têm permissões para atribuir funções RBAC do Azure a outros usuários apenas para o escopo do namespace do blog. Eles podem executar este comando Az CLI para atribuir “Azure Kubernetes Service RBAC Writer” ao grupo aks-blog-users:
az role assignment create --role "Azure Kubernetes Service RBAC Writer" --assignee <<groud-id for aks-blog-users>> --scope /subscriptions/<<subscription>>/resourcegroups/<<rg>>/providers/Microsoft.ContainerService/managedClusters/<<cluster-name>>/namespaces/blogE é isso. Depois disso, qualquer usuário do Azure no grupo aks-blog-users pode obter suas credenciais de cluster usando az aks get-credentials e executar operações de gravação no namespace, mas não pode dar acesso a outras pessoas porque esse grupo não tem a função do IAM de Administrador de Acesso do Usuário como o grupo de administradores. Para obter uma descrição sobre o que cada função RBAC do Azure permite dentro de um cluster AKS, verifique aqui
Conclusão e recomendações
A diferença entre as opções aqui pode ser resumida como “quanto” do RBAC do Azure é usado no AKS quando se trata de autorização e autenticação. Não há escolha absolutamente certa, tudo depende das suas necessidades. Aqui estão alguns fatores decisivos que podem ajudá-lo a escolher uma opção em detrimento das outras:
Local accounts with Kubernetes RBAC
- Utilize esse método se os usuários do cluster AKS não tiverem a possibilidade de estar no Azure AD por algum motivo.
- Gerenciar usuários no Kubernetes “raw” se torna realmente complexo com grandes equipes.
Azure AD authentication with Kubernetes RBAC
- Escolha essa opção se quiser usar o RBAC do Azure apenas para decidir quem poderá obter credenciais do AKS, mas os manifestos YAML do Kubernetes para descrever o que esses usuários podem fazer dentro do cluster.
- Seu cluster se torna mais portável porque contém todas as definições de associações de função nele, mesmo que essas associações contenham IDs de grupo e usuários específicos do Azure em suas definições.
- Verificar quem tem acesso ao quê dentro do cluster não é tão fácil ao trabalhar com grupos do AD porque você precisa trabalhar com IDs de grupo no YAML e não com seus nomes de exibição; certifique-se de salvar suas definições YAML em um controle de origem com comentários de linha adequados para facilitar essa correlação (conforme descrito nas etapas anteriores)
Azure AD authentication with Azure RBAC
- Escolha essa opção se quiser usar o RBAC do Azure apenas para decidir quem e o que os usuários podem fazer dentro do cluster. Esta é uma opção livre de YAML para lidar com o acesso do usuário no AKS.
- Para dar/listar permissões para namespaces específicos, você precisa usar a CLI Az no momento. Ainda não há opção no Portal para gerenciar isso. O Controle de Acesso (IAM) para AKS atribui funções para todo o cluster.
Referências
