Melhores práticas de autenticação e autorização em Azure Kubernetes Service (AKS)

  • Artigo
  • 10 minutos para ler

À medida que implementa e mantém clusters em Azure Kubernetes Service (AKS), implementa formas de gerir o acesso a recursos e serviços. Sem estes controlos:

  • As contas podem ter acesso a recursos e serviços desnecessários.
  • Seguir credenciais usadas para fazer alterações pode ser difícil.

Neste artigo, discutimos as práticas recomendadas que um operador de cluster pode seguir para gerir o acesso e a identidade para clusters AKS. Vai aprender a:

  • Autenticar utilizadores do cluster AKS com Diretório Azure Ative (Azure AD).
  • Controlar o acesso a recursos com o controlo de acesso baseado em funções da Kubernetes (Kubernetes RBAC).
  • Utilize o RBAC Azure para controlar granulitivamente o acesso ao recurso AKS, à API de Kubernetes em escala e ao kubeconfig.
  • Utilize uma identidade gerida para autenticar cápsulas com outros serviços.

Use diretório ativo Azure (Azure AD)

Orientação de melhor prática

Implementar clusters AKS com Azure AD integração. A utilização de Azure AD centraliza a camada de gestão de identidade. Qualquer alteração na conta de utilizador ou no estado do grupo é automaticamente atualizada no acesso ao cluster AKS. Os utilizadores de âmbito ou grupos até ao mínimo de permissões equivalem a funções, ClusterRoles ou Encadernações.

Os desenvolvedores de clusters Kubernetes e os proprietários de aplicações precisam de acesso a diferentes recursos. A Kubernetes carece de uma solução de gestão de identidade para controlar os recursos com os quais os utilizadores podem interagir. Em vez disso, pode integrar o seu cluster com uma solução de identidade existente como Azure AD, uma solução de gestão de identidade pronta para a empresa.

Com clusters integrados Azure AD em AKS, cria Roles ou ClusterRoles que definem permissões de acesso a recursos. Em seguida, liga as funções a utilizadores ou grupos de Azure AD. Saiba mais sobre estes Kubernetes RBAC na secção seguinte. Azure AD integração e como controla o acesso aos recursos pode ser visto no seguinte diagrama:

Autenticação ao nível do cluster para integração do Azure Ative Directory com a AKS

  1. O desenvolvedor autentica com Azure AD.
  2. O Azure AD ponto final de emissão de símbolos emite o token de acesso.
  3. O desenvolvedor executa uma ação usando o símbolo Azure AD, como kubectl create pod.
  4. Kubernetes valida o token com Azure AD e adquire os membros do grupo do desenvolvedor.
  5. As políticas de kubernetes RBAC e cluster são aplicadas.
  6. O pedido do desenvolvedor é bem sucedido com base na validação anterior de Azure AD membro do grupo e da Kubernetes RBAC e políticas.

Para criar um cluster AKS que utilize Azure AD, consulte Integrar o Azure Ative Directory com a AKS.

Use o controlo de acesso baseado em funções da Kubernetes (Kubernetes RBAC)

Orientação de melhor prática

Defina permissões de utilizador ou grupo para agrupar recursos com o RBAC de Kubernetes. Criar funções e encadernações que atribuam o menor número de permissões necessárias. Integre com Azure AD atualizar automaticamente qualquer estado do utilizador ou alteração de membro do grupo e manter o acesso aos recursos de cluster atual.

Em Kubernetes, você fornece controlo de acesso granular aos recursos do cluster. Você define permissões ao nível do cluster, ou para espaços de nome específicos. Você determina que recursos podem ser geridos e com que permissões. Em seguida, aplica estas funções a utilizadores ou grupos com uma ligação. Para obter mais informações sobre Funções, ClusterRoles e Encadernações, consulte opções de acesso e identidade para Azure Kubernetes Service (AKS).

Por exemplo, cria uma função com acesso total aos recursos no espaço de nome denominado app financeira, como mostra o seguinte exemplo YAML manifesto:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Em seguida, cria um RoleBinding e liga o utilizador Azure AD ao utilizadordeveloper1@contoso.com, como mostra o manifesto YAML seguinte:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Quando developer1@contoso.com são autenticados contra o cluster AKS, eles têm permissões completas para recursos no espaço de nomes de aplicativos financeiros . Desta forma, separa-se logicamente e controla o acesso aos recursos. Utilize o RBAC de Kubernetes com Azure AD-integração.

Para aprender a usar Azure AD grupos para controlar o acesso aos recursos de Kubernetes usando o RBAC de Kubernetes, consulte o Control access to cluster resources usando o controlo de acesso baseado em funções e identidades do Azure Ative Directory em AKS.

Use Azure RBAC

Orientação de melhor prática

Utilize o Azure RBAC para definir as permissões mínimas de utilizador e grupo exigidas aos recursos AKS em uma ou mais subscrições.

Existem dois níveis de acesso necessários para operar totalmente um cluster AKS:

  • Aceda ao recurso AKS na sua subscrição Azure.

    Este nível de acesso permite-lhe:

    • Controlo de dimensionamento ou modernização do seu cluster utilizando as APIs AKS
    • Puxe o seu kubeconfig.

    Para aprender a controlar o acesso ao recurso AKS e ao , consulte limite de kubeconfigacesso ao ficheiro de configuração do cluster.

  • Acesso à API de Kubernetes.

    Este nível de acesso é controlado quer por:

    • Kubernetes RBAC (tradicionalmente) ou
    • Integrando o Azure RBAC com a AKS para a autorização de kubernetes.

    Para aprender a conceder granularmente permissões à API de Kubernetes usando a Azure RBAC, consulte Use Azure RBAC para autorização kubernetes.

Utilizar identidades geridas por pod

Orientação de melhor prática

Não utilize credenciais fixas dentro de cápsulas ou imagens de contentores, uma vez que estão em risco de exposição ou abuso. Em vez disso, utilize identidades de pod para solicitar automaticamente o acesso através de Azure AD.

Nota

As identidades do pod destinam-se apenas a ser utilizadas apenas com cápsulas Linux e imagens de contentores. O suporte de identidades geridas por pod para contentores windows está para breve.

Para aceder a outros recursos Azure, como Azure Cosmos DB, Key Vault ou blob, o casulo precisa de credenciais de autenticação. Pode definir credenciais de autenticação com a imagem do recipiente ou injetá-las como um segredo de Kubernetes. De qualquer forma, teria de os criar manualmente e atribuí-los. Normalmente, estas credenciais são reutilizadas através de cápsulas e não são regularmente giradas.

Com identidades geridas por pod (pré-visualização) para recursos Azure, você automaticamente solicita o acesso aos serviços através Azure AD. As identidades geridas pelo Pod estão atualmente em pré-visualização para a AKS. Consulte as identidades geridas pelo Use Azure Ative Pod em Azure Kubernetes Service documentação (Pré-visualização) para começar.

Nota

Se ativou Azure AD identidade gerida por cápsulas no seu cluster AKS ou está a considerar implementá-la, recomendamos que reveja primeiro o artigo de visão geral da identidade da carga de trabalho para entender as nossas recomendações e opções para configurar o seu cluster para usar uma identidade de carga de trabalho Azure AD (pré-visualização). Este método de autenticação substitui a identidade gerida pelo pod (pré-visualização), que se integra com as capacidades nativas de Kubernetes para federar com quaisquer fornecedores de identidade externos.

A identidade gerida open source Azure AD (pré-visualização) em Azure Kubernetes Service foi depreciada a partir de 10/24/2022.

A identidade gerida pelo Azure Ative(preview) suporta dois modos de funcionamento:

  • Modo standard : Neste modo, os seguintes 2 componentes são implantados no cluster AKS:

    • Controlador de identidade gerido (MIC): Um controlador Kubernetes que observa alterações nas cápsulas, AzureIdentity e AzureIdentityBining através do Servidor API de Kubernetes. Quando deteta uma alteração relevante, o MIC adiciona ou elimina a AzureAssignedIdentity , conforme necessário. Especificamente, quando um casulo é programado, o MIC atribui a identidade gerida em Azure à escala de máquina virtual subjacente usada pelo conjunto de nós durante a fase de criação. Quando todas as cápsulas que utilizam a identidade são eliminadas, remove a identidade do conjunto de escala de máquina virtual do conjunto de nós, a menos que a mesma identidade gerida seja utilizada por outras cápsulas. O MIC toma ações semelhantes quando a AzureIdentity ou AzureIdentityBinding são criadas ou eliminadas.

    • Node Managed Identity (NMI): é um pod que funciona como Um DaemonSet em cada nó no cluster AKS. O NMI interceta pedidos de fichas de segurança ao Serviço de Metadados de Instância Azure em cada nó. Redireciona os pedidos para si mesmo e valida se a cápsula tiver acesso à identidade para a qual está a pedir um sinal, e buscar o símbolo ao inquilino do Azure Ative Directory em nome do pedido.

  • Modo gerido : Neste modo, existe apenas NMI. A identidade tem de ser atribuída manualmente e gerida pelo utilizador. Para obter mais informações, consulte Pod Identity in Managed Mode. Neste modo, quando utiliza o comando de az aks pod-identity add para adicionar uma identidade de casulo a um cluster Azure Kubernetes Service (AKS), cria a AzureIdentity e a AzureIdentityBining no espaço de nome especificado pelo --namespace parâmetro, enquanto o fornecedor de recursos AKS atribui a identidade gerida especificada pelo --identity-resource-id parâmetro à escala de máquina virtual definida no conjunto de cada conjunto de nós no agrupamento AKS.

Nota

Se, em vez disso, decidir instalar a identidade gerida pelo pod do Azure Ative, utilizando o add-on do cluster AKS, a configuração utiliza o managed modo.

O managed modo proporciona as seguintes vantagens sobre:standard

  • A atribuição de identidade no conjunto de escala de máquina virtual de um conjunto de nós pode ocupar 40-60s. Com cronjobs ou aplicações que requerem acesso à identidade e não podem tolerar o atraso de atribuição, o melhor é usar managed o modo, uma vez que a identidade é pré-atribuída ao conjunto de escala de máquina virtual do conjunto de nós. Ou manualmente ou utilizando o comando de adicionar identidade az aks .
  • No standard modo, o MIC requer permissões de escrita na balança de máquina virtual utilizada pelo cluster AKS e Managed Identity Operator permissão nas identidades geridas atribuídas pelo utilizador. Quando se candidata managed mode, uma vez que não há MIC, as atribuições de papéis não são necessárias.

Em vez de definir manualmente credenciais para cápsulas, as identidades geridas por pods solicitam um token de acesso em tempo real, usando-o apenas para aceder aos seus recursos atribuídos. Na AKS, existem dois componentes que lidam com as operações para permitir que as cápsulas utilizem identidades geridas:

  • O servidor Node Management Identity (NMI) é um pod que funciona como Um DaemonSet em cada nó no cluster AKS. O servidor NMI ouve pedidos de pod para os serviços Azure.
  • O Fornecedor de Recursos Azure consulta o servidor API de Kubernetes e verifica um mapeamento de identidade Azure que corresponde a uma cápsula.

Quando as cápsulas solicitam um token de segurança do Azure Ative Directory para aceder a um recurso Azure, as regras de rede redirecionam o tráfego para o servidor NMI.

  1. O servidor NMI:

    • Identifica cápsulas que solicitam acesso aos recursos Azure com base no seu endereço remoto.
    • Consultas ao Fornecedor de Recursos Azure.

  2. O Fornecedor de Recursos Azure verifica os mapeamentos de identidade Azure no cluster AKS.

  3. O servidor NMI solicita um token de acesso a partir de Azure AD com base no mapeamento de identidade da cápsula.

  4. Azure AD fornece acesso ao servidor NMI, que é devolvido à cápsula.

    • Este token de acesso pode ser usado pela cápsula para, em seguida, solicitar acesso aos recursos em Azure.

No exemplo seguinte, um desenvolvedor cria um casulo que utiliza uma identidade gerida para solicitar o acesso à Base de Dados SQL do Azure:

As identidades do Pod permitem que um casulo solicite automaticamente o acesso a outros recursos.

  1. O operador do cluster cria uma conta de serviço para mapear identidades quando as cápsulas solicitam o acesso aos recursos.
  2. O servidor NMI é implantado para transmitir quaisquer pedidos de pod, juntamente com o Fornecedor de Recursos Azure, para acesso a tokens para Azure AD.
  3. Um desenvolvedor implementa um pod com uma identidade gerida que solicita um token de acesso através do servidor NMI.
  4. O token é devolvido à cápsula e usado para aceder à base de dados SQL do Azure

Para utilizar identidades geridas pelo Pod, consulte use identidades geridas pelo Azure Ative Pod em Azure Kubernetes Service (pré-visualização).

Passos seguintes

Este artigo de boas práticas focado na autenticação e autorização para o seu cluster e recursos. Para implementar algumas destas boas práticas, consulte os seguintes artigos:

Para obter mais informações sobre as operações de cluster em AKS, consulte as seguintes boas práticas: