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

  • Artigo

À medida que implementa e mantém clusters no 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.
  • Pode ser difícil controlar as credenciais utilizadas para fazer alterações.

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

  • Autenticar utilizadores do cluster do AKS com o Azure Active Directory (Azure AD).
  • Controlar o acesso aos recursos com o controlo de acesso baseado em funções do Kubernetes (RBAC do Kubernetes).
  • Utilize o RBAC do Azure para controlar granularmente o acesso ao recurso do AKS, à API do Kubernetes em escala e ao kubeconfig.
  • Utilize uma identidade gerida para autenticar pods com outros serviços.

Utilizar o Azure Active Directory (Azure AD)

Orientação de melhores práticas

Implementar clusters do AKS com integração Azure AD. Utilizar Azure AD centraliza a camada de gestão de identidades. Qualquer alteração no estado da conta de utilizador ou do grupo é atualizada automaticamente no acesso ao cluster do AKS. Defina o âmbito de utilizadores ou grupos para o valor mínimo de permissões através de Funções, ClusterRoles ou Enlaces.

Os programadores de clusters do Kubernetes e os proprietários de aplicações precisam de acesso a diferentes recursos. O Kubernetes não dispõe de uma solução de gestão de identidades para controlar os recursos com os quais os utilizadores podem interagir. Em vez disso, pode integrar o cluster com uma solução de identidade existente, como Azure AD, uma solução de gestão de identidades pronta para empresas.

Com Azure AD clusters integrados no AKS, pode criar Funções ou ClusterRoles que definem permissões de acesso aos recursos. Em seguida, vincula as funções a utilizadores ou grupos de Azure AD. Saiba mais sobre estes RBAC do Kubernetes na secção seguinte. Azure AD integração e como pode controlar o acesso aos recursos no diagrama seguinte:

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

  1. O programador autentica-se com Azure AD.
  2. O ponto final de emissão de tokens de Azure AD emite o token de acesso.
  3. O programador executa uma ação com o token de Azure AD, como kubectl create pod.
  4. O Kubernetes valida o token com Azure AD e obtém as associações de grupo do programador.
  5. As políticas RBAC e de cluster do Kubernetes são aplicadas.
  6. O pedido do programador é efetuado com êxito com base na validação anterior de Azure AD associação a grupos e rbac e políticas do Kubernetes.

Para criar um cluster do AKS que utiliza Azure AD, veja Integrar o Azure Active Directory no AKS.

Utilizar o controlo de acesso baseado em funções do Kubernetes (RBAC do Kubernetes)

Orientação de melhores práticas

Defina permissões de utilizador ou grupo para recursos de cluster com o RBAC do Kubernetes. Crie funções e enlaces que atribuam o mínimo de permissões necessárias. Integre com Azure AD para atualizar automaticamente qualquer estado de utilizador ou alteração de associação a grupos e manter o acesso aos recursos do cluster atual.

No Kubernetes, fornece controlo de acesso granular aos recursos do cluster. Pode definir permissões ao nível do cluster ou para espaços de nomes específicos. Pode determinar que recursos podem ser geridos e com que permissões. Em seguida, aplica estas funções a utilizadores ou grupos com um enlace. Para obter mais informações sobre Funções, ClusterRoles e Enlaces, veja Opções de acesso e identidade para Azure Kubernetes Service (AKS).

Por exemplo, pode criar uma função com acesso total aos recursos no espaço de nomes com o nome finance-app, conforme mostrado no seguinte manifesto YAML de exemplo:

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

Em seguida, crie um RoleBinding e vinculte o Azure AD utilizador developer1@contoso.com ao mesmo, conforme mostrado no seguinte manifesto YAML:

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 é autenticado no cluster do AKS, estes têm permissões totais para recursos no espaço de nomes finance-app . Desta forma, separa e controla logicamente o acesso aos recursos. Utilize o RBAC do Kubernetes com Azure AD integração.

Para saber como utilizar Azure AD grupos para controlar o acesso aos recursos do Kubernetes com o RBAC do Kubernetes, veja Controlar o acesso aos recursos do cluster com o controlo de acesso baseado em funções e as identidades do Azure Active Directory no AKS.

Utilizar o RBAC do Azure

Orientação de melhores práticas

Utilize o RBAC do Azure para definir as permissões mínimas de utilizador e grupo necessárias para recursos do AKS numa ou mais subscrições.

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

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

    Este nível de acesso permite-lhe:

    • Controlar o dimensionamento ou a atualização do cluster com as APIs do AKS
    • Puxe o seu kubeconfig.

    Para saber como controlar o acesso ao recurso do AKS e ao , veja Limitar o kubeconfigacesso ao ficheiro de configuração do cluster.

  • Acesso à API do Kubernetes.

    Este nível de acesso é controlado por:

    • RBAC do Kubernetes (tradicionalmente) ou
    • Ao integrar o RBAC do Azure com a autorização do AKS para kubernetes.

    Para saber como conceder permissões granularmente à API do Kubernetes com o RBAC do Azure, veja Utilizar o RBAC do Azure para autorização do Kubernetes.

Utilizar identidades geridas por pods

Não utilize credenciais fixas em pods ou imagens de contentor, uma vez que estão em risco de exposição ou abuso. Em vez disso, utilize identidades de pods para pedir automaticamente acesso com Azure AD.

Nota

As identidades dos pods destinam-se apenas a ser utilizadas com pods do Linux e imagens de contentor. O suporte de identidades geridas por pods (pré-visualização) para contentores do Windows estará disponível em breve.

Para aceder a outros recursos do Azure, como o Azure Cosmos DB, o Key Vault ou o Armazenamento de blobs, o pod precisa de credenciais de autenticação. Pode definir credenciais de autenticação com a imagem de contentor ou injetá-las como um segredo do Kubernetes. De qualquer forma, teria de criá-los e atribuí-los manualmente. Normalmente, estas credenciais são reutilizadas em pods e não são regularmente rodadas.

Com identidades geridas por pods (pré-visualização) para recursos do Azure, pede automaticamente acesso aos serviços através de Azure AD. As identidades geridas por pods estão atualmente em pré-visualização para o AKS. Veja a documentação Utilizar identidades geridas por pods do Azure Active Directory no Azure Kubernetes Service (Pré-visualização) para começar.

Nota

Se tiver ativado Azure AD identidade gerida por pods no cluster do AKS ou estiver a considerar implementá-la, recomendamos que reveja primeiro o artigo descrição geral da identidade da carga de trabalho para compreender as nossas recomendações e opções para configurar o cluster para utilizar uma identidade de carga de trabalho Azure AD (pré-visualização). Este método de autenticação substitui a identidade gerida por pods (pré-visualização), que se integra com as capacidades nativas do Kubernetes para federar com quaisquer fornecedores de identidade externos.

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

A identidade gerida por pods (pré-visualização) do Azure Active Directory suporta dois modos de operação:

  • Modo padrão : neste modo, são implementados os dois componentes seguintes no cluster do AKS:

    • Managed Identity Controller(MIC): um controlador Kubernetes que observa alterações nos pods, AzureIdentity e AzureIdentityBinding através do Servidor de API do Kubernetes. Quando deteta uma alteração relevante, o MIC adiciona ou elimina AzureAssignedIdentity conforme necessário. Especificamente, quando um pod é agendado, o MIC atribui a identidade gerida no Azure ao conjunto de dimensionamento de máquinas virtuais subjacente utilizado pelo conjunto de nós durante a fase de criação. Quando todos os pods que utilizam a identidade são eliminados, remove a identidade do conjunto de dimensionamento de máquinas virtuais do conjunto de nós, a menos que a mesma identidade gerida seja utilizada por outros pods. O MIC executa ações semelhantes quando a AzureIdentity ou a AzureIdentityBinding são criadas ou eliminadas.

    • Node Managed Identity (NMI): é um pod que é executado como um DaemonSet em cada nó no cluster do AKS. A NMI interceta pedidos de tokens de segurança para o Azure Instance Metadata Service em cada nó. Redireciona os pedidos para si próprio e valida se o pod tem acesso à identidade para a qual está a pedir um token e obtém o token do inquilino do Azure Active Directory em nome da aplicação.

  • Modo gerido : neste modo, existe apenas a NMI. A identidade tem de ser atribuída manualmente e gerida pelo utilizador. Para obter mais informações, veja Identidade do Pod no Modo Gerido. Neste modo, quando utiliza o comando az aks pod-identity add para adicionar uma identidade de pod a um cluster do Azure Kubernetes Service (AKS), cria o AzureIdentity e o AzureIdentityBinding no espaço de nomes especificado pelo --namespace parâmetro, enquanto o fornecedor de recursos do AKS atribui a identidade gerida especificada pelo --identity-resource-id parâmetro ao conjunto de dimensionamento de máquinas virtuais de cada conjunto de nós no cluster do AKS.

Nota

Se, em vez disso, decidir instalar a identidade gerida por pods do Azure Active Directory com o suplemento de cluster do AKS, a configuração utiliza o managed modo .

O managed modo fornece as seguintes vantagens sobre o standard:

  • A atribuição de identidade no conjunto de dimensionamento de máquinas virtuais de um conjunto de nós pode demorar entre 40 e 60 anos. Com cronjobs ou aplicações que necessitam de acesso à identidade e não conseguem tolerar o atraso da atribuição, é melhor utilizar managed o modo, uma vez que a identidade está pré-atribuída ao conjunto de dimensionamento de máquinas virtuais do conjunto de nós. Manualmente ou com o comando az aks pod-identity add .
  • No standard modo, o MIC requer permissões de escrita no conjunto de dimensionamento de máquinas virtuais utilizado pelo cluster do AKS e Managed Identity Operator a permissão nas identidades geridas atribuídas pelo utilizador. Ao executar no managed mode, uma vez que não existe nenhum MIC, as atribuições de funções não são necessárias.

Em vez de definir manualmente credenciais para pods, as identidades geridas por pods pedem um token de acesso em tempo real, utilizando-o para aceder apenas aos recursos atribuídos. No AKS, existem dois componentes que processam as operações para permitir que os pods utilizem identidades geridas:

  • O servidor NMI (Node Management Identity) é um pod que é executado como um DaemonSet em cada nó no cluster do AKS. O servidor NMI escuta pedidos de pod para os serviços do Azure.
  • O Fornecedor de Recursos do Azure consulta o servidor da API do Kubernetes e verifica se há um mapeamento de identidades do Azure que corresponda a um pod.

Quando os pods pedem um token de segurança do Azure Active Directory para aceder a um recurso do Azure, as regras de rede redirecionam o tráfego para o servidor NMI.

  1. O servidor NMI:

    • Identifica pods que pedem acesso aos recursos do Azure com base no respetivo endereço remoto.
    • Consulta o Fornecedor de Recursos do Azure.

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

  3. O servidor NMI pede um token de acesso a partir de Azure AD com base no mapeamento de identidades do pod.

  4. Azure AD fornece acesso ao servidor NMI, que é devolvido ao pod.

    • Este token de acesso pode ser utilizado pelo pod para, em seguida, pedir acesso aos recursos no Azure.

No exemplo seguinte, um programador cria um pod que utiliza uma identidade gerida para pedir acesso à Base de Dados SQL do Azure:

As identidades do pod permitem que um pod solicite automaticamente acesso a outros recursos.

  1. O operador de cluster cria uma conta de serviço para mapear identidades quando os pods pedem acesso aos recursos.
  2. O servidor NMI é implementado para reencaminhar quaisquer pedidos de pod, juntamente com o Fornecedor de Recursos do Azure, para tokens de acesso a Azure AD.
  3. Um programador implementa um pod com uma identidade gerida que pede um token de acesso através do servidor NMI.
  4. O token é devolvido ao pod e utilizado para aceder à Base de Dados SQL do Azure

Para utilizar identidades geridas pelo Pod, veja Utilizar identidades geridas por pods do Azure Active Directory no Azure Kubernetes Service (pré-visualização).

Passos seguintes

Este artigo de melhores práticas focava-se na autenticação e autorização para o cluster e os recursos. Para implementar algumas destas melhores práticas, veja os seguintes artigos:

Para obter mais informações sobre as operações de cluster no AKS, veja as seguintes melhores práticas: