Partilhar via

Autoridade de certificação (CA) personalizada no Serviço Kubernetes do Azure (AKS) (visualização)

  • Artigo

O AKS gera e usa os seguintes certificados, Autoridades de Certificação (CAs) e Contas de Serviço (SAs):

  • O servidor de API do AKS cria uma autoridade de certificação chamada CA de cluster.
  • O servidor de API tem uma CA de Cluster, que assina certificados para comunicação unidirecional do servidor de API para kubelets.
  • Cada kubelet também cria uma Solicitação de Assinatura de Certificado (CSR), que é assinada pela CA do Cluster, para comunicação do kubelet com o servidor de API.
  • O agregador de API usa a CA de cluster para emitir certificados para comunicação com outras APIs. O agregador de API também pode ter sua própria autoridade de certificação para emitir esses certificados, mas atualmente usa a autoridade de certificação de cluster.
  • Cada nó usa um token SA, que é assinado pela autoridade de certificação do cluster.
  • O kubectl cliente tem um certificado para se comunicar com o cluster AKS.

Você também pode criar autoridades de certificação personalizadas, que permitem estabelecer confiança entre seus clusters do Serviço Kubernetes do Azure (AKS) e cargas de trabalho, como registros privados, proxies e firewalls. Um segredo do Kubernetes armazena as informações da autoridade de certificação e, em seguida, é passado para todos os nós no cluster. Esse recurso é aplicado por pool de nós, portanto, você precisa habilitá-lo em pools de nós novos e existentes.

Este artigo mostra como criar CAs personalizadas e aplicá-las aos seus clusters AKS.

Pré-requisitos

  • Uma subscrição do Azure. Se não tiver uma subscrição do Azure, crie uma conta gratuita.
  • CLI do Azure instalada (versão 2.43.0 ou superior).
  • Uma cadeia de caracteres de certificado codificada em base64 ou um arquivo de texto com certificado.

Limitações

  • Atualmente, esse recurso não é suportado para pools de nós do Windows.

Instalar a extensão da CLI do aks-preview Azure

Importante

Os recursos de visualização do AKS estão disponíveis em uma base de autosserviço e opt-in. As visualizações prévias são fornecidas "como estão" e "conforme disponíveis" e são excluídas dos contratos de nível de serviço e da garantia limitada. As visualizações do AKS são parcialmente cobertas pelo suporte ao cliente com base no melhor esforço. Como tal, estas funcionalidades não se destinam a utilização em produção. Para obter mais informações, consulte os seguintes artigos de suporte:

  1. Instale a extensão aks-preview usando o az extension add comando.

    az extension add --name aks-preview

  2. Atualize para a versão mais recente da extensão usando o az extension update comando.

    az extension update --name aks-preview

Registrar o sinalizador de CustomCATrustPreview recurso

  1. Registre o CustomCATrustPreview sinalizador de recurso usando o az feature register comando.

    az feature register --namespace "Microsoft.ContainerService" --name "CustomCATrustPreview"

    Leva alguns minutos para que o status mostre Registrado.

  2. Verifique o status do registro usando o az feature show comando.

    az feature show --namespace "Microsoft.ContainerService" --name "CustomCATrustPreview"

  3. Quando o status refletir Registrado, atualize o registro do provedor de recursos Microsoft.ContainerService usando o az provider register comando.

    az provider register --namespace Microsoft.ContainerService

Instalação personalizada de CA em pools de nós AKS

Instalar CAs em pools de nós AKS

  • Se seu ambiente exigir que suas CAs personalizadas sejam adicionadas ao armazenamento confiável do nó para o provisionamento correto, você precisará passar um arquivo de texto contendo até 10 certificados separados por linha em branco durante az aks create as operações ou az aks update operações. Exemplo de arquivo de texto:

    -----BEGIN CERTIFICATE-----
cert1
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
cert2
-----END CERTIFICATE-----

Instalar CAs durante a criação do pool de nós

  • Instale CAs durante a criação do pool de nós usando o parâmetro [az aks create][az-aks-create] command and specifying your text file for the --custom-ca-trust-certificates'.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

Rotação da autoridade de certificação para disponibilidade durante a inicialização do pool de nós

  • Atualize as CAs passadas para o cluster durante a inicialização usando o comando e especificando o az aks update arquivo de texto para o --custom-ca-trust-certificates parâmetro.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --custom-ca-trust-certificates pathToFileWithCAs

    Nota

    Essa operação dispara uma atualização de modelo, garantindo que os novos nós tenham as CAs mais recentes necessárias para o provisionamento correto. O AKS cria nós adicionais, drena os existentes, exclui-os e os substitui por nós que têm o novo conjunto de CAs instalado.

Instalar CAs após a criação do pool de nós

Se seu ambiente puder ser provisionado com êxito sem suas CAs personalizadas, você poderá fornecê-las implantando um segredo no kube-system namespace. Essa abordagem permite a rotação de certificados sem a necessidade de recriação de nós.

  • Crie um manifesto YAML [Kubernetes secret][kubernetes-secrets] com sua cadeia de caracteres de certificado codificada em base64 no data campo.

    apiVersion: v1
kind: Secret
metadata: 
    name: custom-ca-trust-secret
    namespace: kube-system
type: Opaque
data:
    ca1.crt: |
      {base64EncodedCertStringHere}
    ca2.crt: |
      {anotherBase64EncodedCertStringHere}

    Os dados desse segredo são usados para atualizar CAs em todos os nós. Verifique se o segredo é nomeado custom-ca-trust-secret e criado no kube-system namespace. A instalação de autoridades de certificação usando o segredo no namespace permite a kube-system rotação da autoridade de certificação sem a necessidade de recriação do nó. Para atualizar ou remover uma autoridade de certificação, você pode editar e aplicar o manifesto YAML. O cluster pesquisa alterações e atualiza os nós de acordo. Pode demorar alguns minutos até que as alterações sejam aplicadas.

    Nota

    a reinicialização em contêiner no nó pode ser necessária para que as autoridades de certificação sejam captadas corretamente. Se parecer que as CAs não foram adicionadas corretamente ao armazenamento confiável do nó, você pode disparar uma reinicialização usando o seguinte comando do shell do nó:

    systemctl restart containerd

Configurar um novo cluster AKS para usar uma autoridade de certificação personalizada

  • Configure um novo cluster AKS para usar uma autoridade de certificação personalizada usando o az aks create comando com o --enable-custom-ca-trust parâmetro.

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --generate-ssh-keys

Configurar um novo cluster AKS para usar uma CA personalizada com CAs instaladas antes da inicialização do nó

  • Configure um novo cluster AKS para usar CAs personalizadas com CAs instaladas antes que o nó seja inicializado usando o az aks create comando com os --enable-custom-ca-trust parâmetros e --custom-ca-trust-certificates .

    az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --enable-custom-ca-trust \
    --custom-ca-trust-certificates pathToFileWithCAs \
    --generate-ssh-keys

Configurar um cluster AKS existente para ter CAs personalizadas instaladas antes da inicialização do nó

  • Configure um cluster AKS existente para que suas CAs personalizadas sejam adicionadas ao armazenamento confiável do nó antes que ele seja inicializado usando o az aks update comando com o --custom-ca-trust-certificates parâmetro.

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --custom-ca-trust-certificates pathToFileWithCAs

Configurar um novo pool de nós para usar uma autoridade de certificação personalizada

  • Configure um novo pool de nós para usar uma autoridade de certificação personalizada usando o az aks nodepool add comando com o --enable-custom-ca-trust parâmetro.

    az aks nodepool add \
    --cluster-name myAKSCluster \
    --resource-group myResourceGroup \
    --name myNodepool \
    --enable-custom-ca-trust \
    --os-type Linux

    Se não existirem outros pools de nós com o recurso habilitado, o cluster terá que reconciliar suas configurações para que as alterações entrem em vigor. Esta operação acontece automaticamente como parte do loop de reconciliação do AKS. Antes da operação, o conjunto de daemon e os pods não aparecem no cluster. Você pode acionar uma operação de reconciliação imediata usando o az aks update comando. O conjunto de daemon e os pods aparecem após a conclusão da atualização.

Configurar um pool de nós existente para usar uma autoridade de certificação personalizada

  • Configure um pool de nós existente para usar uma autoridade de certificação personalizada usando o az aks nodepool update comando com o --enable-custom-trust-ca parâmetro.

    az aks nodepool update \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name myNodepool \
    --enable-custom-ca-trust

    Se não existirem outros pools de nós com o recurso habilitado, o cluster terá que reconciliar suas configurações para que as alterações entrem em vigor. Esta operação acontece automaticamente como parte do loop de reconciliação do AKS. Antes da operação, o conjunto de daemon e os pods não aparecem no cluster. Você pode acionar uma operação de reconciliação imediata usando o az aks update comando. O conjunto de daemon e os pods aparecem após a conclusão da atualização.

Resolução de Problemas

O recurso está habilitado e o segredo com CAs é adicionado, mas as operações estão falhando com o erro de certificado X.509 assinado por autoridade desconhecida

Certificados formatados incorretamente passados no segredo

O AKS requer que os certificados passados no segredo criado pelo usuário sejam formatados corretamente e codificados em base64. Verifique se as autoridades de certificação aprovadas estão codificadas corretamente em base64 e se os arquivos com autoridades de certificação não têm quebras de linha CRLF. Os certificados passados para --custom-ca-trust-certificates não devem ser codificados em base64.

containerd não pegou novos certificados

A partir do shell do nó, execute systemctl restart containerd. Depois que o contêiner é reiniciado, os novos certificados são coletados corretamente pelo tempo de execução do contêiner.

Próximos passos

Para obter mais informações sobre as práticas recomendadas de segurança do AKS, consulte Práticas recomendadas para segurança de cluster e atualizações no Serviço Kubernetes do Azure (AKS).