AC (autoridade de certificação) personalizada no AKS (Serviço de Kubernetes do Azure) (versão prévia)

  • Artigo

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

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

Você também pode criar autoridades de certificação personalizadas, que permitem estabelecer confiança entre clusters do AKS (Serviço de Kubernetes do Azure) e cargas de trabalho, como registros privados, proxies e firewalls. Um segredo do Kubernetes armazena as informações da autoridade de certificação e depois é transmitido 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 ACs personalizadas e aplicá-las aos clusters do AKS.

Pré-requisitos

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

Limitações

  • No momento, não há suporte para esse recurso em pools de nós do Windows.

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

Importante

As versões prévias do recurso AKS estão disponíveis em uma base de autoatendimento e aceitação. As visualizações são fornecidas "como estão" e "conforme disponíveis" e estão excluídas dos acordos de nível de serviço e da garantia limitada. As versões prévias do AKS são parcialmente cobertas pelo suporte ao cliente em uma base de melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção. Para obter mais informações, consulte os seguintes artigos:

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

    az extension add --name aks-preview

  2. Atualize para a última versão da extensão usando o comando az extension update.

    az extension update --name aks-preview

Registrar o sinalizador de recurso CustomCATrustPreview

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

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

    Demora alguns minutos para o status exibir Registrado.

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

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

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

    az provider register --namespace Microsoft.ContainerService

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

Instalar ACs em pools de nós do AKS

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

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

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

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

  • Instale as ACs durante a criação do pool de nós usando o comando az aks create e especificando o arquivo de texto para o parâmetro --custom-ca-trust-certificates.

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

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

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

    az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --custom-ca-trust-certificates pathToFileWithCAs

    Observação

    Essa operação dispara uma atualização de modelo, garantindo que novos os nós tenham as ACs 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 ACs instalado.

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

Se o ambiente puder ser provisionado com êxito sem as ACs personalizadas, você pode fornecer as ACs implantando um segredo no namespace kube-system. Essa abordagem permite a rotação de certificados sem a necessidade de recriação de nó.

  • Crie um manifesto YAML segredo do Kubernetes com a cadeia de caracteres de certificado codificada em base64 no campo data.

    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 as ACs em todos os nós. Verifique se o segredo é denominado custom-ca-trust-secret e criado no namespace kube-system. A instalação de ACs usando o segredo no namespace kube-system permite a rotação da AC sem precisar recriar o nó. Para atualizar ou remover uma AC, edite e aplique o manifesto YAML. O cluster sonda as alterações e atualiza os nós adequadamente. Pode levar alguns minutos até que as alterações sejam aplicadas.

    Observação

    A reinicialização em contêiner no nó pode ser necessária para que as ACs sejam escolhidas corretamente. Se parecer que as ACs não foram adicionadas corretamente ao repositório confiável do nó, você pode disparar uma reinicialização usando o seguinte comando do shell de nó:

    systemctl restart containerd

Configurar um novo cluster do AKS para usar uma AC personalizada

  • Configure um novo cluster do AKS para usar uma AC personalizada usando o comando az aks create com o parâmetro --enable-custom-ca-trust.

    az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --node-count 2 \
    --enable-custom-ca-trust \
    --generate-ssh-keys

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

  • Configure um novo cluster do AKS para usar a AC personalizada com ACs instaladas antes que o nó inicialize usando o comando az aks create com os parâmetros --enable-custom-ca-trust e --custom-ca-trust-certificates.

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

Configurar um cluster do AKS existente para ter CAs personalizadas instaladas antes que o nó seja inicializado

  • Configure um cluster do AKS existente para que as ACs personalizadas sejam adicionadas ao repositório confiável do nó antes de inicializar usando o comando az aks update com o parâmetro --custom-ca-trust-certificates.

    az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --custom-ca-trust-certificates pathToFileWithCAs

Configurar um novo pool de nós para usar uma CA personalizada

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

    az aks nodepool add \
    --cluster-name <cluster-name> \
    --resource-group <resource-group-name> \
    --name <node-pool-name> \
    --enable-custom-ca-trust \
    --os-type Linux

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

Configurar um pool de nós existente para usar uma CA personalizada

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

    az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --enable-custom-ca-trust

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

Desabilitar a AC personalizada em um pool de nós

  • Desabilite o recurso de AC personalizada em um pool de nós existente usando o comando az aks nodepool update com o parâmetro --disable-custom-ca-trust.

    az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --disable-custom-ca-trust

Solução de problemas

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

Certificados formatados incorretamente passados no segredo

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

o contêiner não pegou novos certificados

No shell do nó, execute systemctl restart containerd. Os novos certificados serão coletados corretamente pelo runtime do contêiner depois que o contêiner for reiniciado.

Próximas etapas

Para saber mais sobre as melhores práticas de segurança do AKS, confira Melhores práticas para segurança de cluster e atualizações no AKS (Serviço de Kubernetes do Azure).