Visão geral do gerenciamento de certificados no AKS habilitado pelo Azure Arc

  • Artigo

Aplica-se a: AKS no Azure Stack HCI 22H2, AKS no Windows Server

O AKS habilitado pelo Azure Arc usa uma combinação de autenticação baseada em certificado e token para proteger a comunicação entre serviços (ou agentes) responsáveis por diferentes operações dentro da plataforma. A autenticação baseada em certificado usa um certificado digital para identificar uma entidade (agente, computador, usuário ou dispositivo) antes de conceder acesso a um recurso.

Agente de nuvem

Quando você implanta o AKS habilitado pelo Arc, o AKS instala agentes que são usados para executar várias funções dentro do cluster. Esses agentes incluem:

  • Agente de nuvem: um serviço responsável pela orquestração de plataforma subjacente.
  • Agente de nó: um serviço que reside em cada nó que faz o trabalho real de criação, exclusão, etc. da máquina virtual.
  • Pod kms (sistema de gerenciamento de chaves): um serviço responsável pelo gerenciamento de chaves.
  • Outros serviços: operador de nuvem, gerenciador de certificados etc.

O serviço de agente de nuvem no AKS é responsável por orquestrar as operações CRUD (criação, leitura, atualização e exclusão) de componentes de infraestrutura, como VMs (Máquinas Virtuais), VNICs (Interfaces Rede Virtual) e VNETs (Redes Virtuais) no cluster.

Para se comunicar com o agente de nuvem, os clientes exigem que os certificados sejam provisionados para proteger essa comunicação. Cada cliente requer que uma identidade seja associada a ela, o que define as regras rbac (Controle de Acesso baseadas em função) associadas ao cliente. Cada identidade consiste em duas entidades:

  • Um token, usado para autenticação inicial, que retorna um certificado e
  • Um certificado, obtido do processo de entrada acima e usado para autenticação em qualquer comunicação.

Cada entidade é válida por um período específico (o padrão é 90 dias), no final do qual expira. Para acesso contínuo ao agente de nuvem, cada cliente requer que o certificado seja renovado e o token girado.

Tipos de certificado

Há dois tipos de certificados usados no AKS habilitados pelo Arc:

  • Certificado de autoridade de certificação do agente de nuvem: o certificado usado para assinar/validar certificados de cliente. Esse certificado é válido por 365 dias (1 ano).
  • Certificados de cliente: certificados emitidos pelo certificado de AC do agente de nuvem para que os clientes se autentiquem no agente de nuvem. Esses certificados geralmente são válidos por 90 dias.

A Microsoft recomenda que você atualize os clusters dentro de 60 dias após uma nova versão, não apenas para garantir que os certificados e tokens internos sejam mantidos atualizados, mas também para garantir que você tenha acesso a novos recursos, correções de bugs e fique atualizado com patches de segurança críticos. Durante essas atualizações mensais, o processo de atualização gira todos os tokens que não podem ser girados automaticamente durante as operações normais do cluster. A validade do certificado e do token é redefinida para o padrão 90 dias a partir da data em que o cluster é atualizado.

Proteger a comunicação com certificados no AKS habilitados pelo Arc

Os certificados são usados para criar uma comunicação segura entre componentes no cluster. O AKS fornece provisionamento de toque zero, pronto para uso e gerenciamento de certificados para componentes internos do Kubernetes. Neste artigo, você aprenderá a provisionar e gerenciar certificados no AKS habilitados pelo Arc.

Certificados e CAs

O AKS gera e usa as seguintes ACs (Autoridades de Certificação) e certificados.

AC do cluster

  • O servidor de API tem uma AC de cluster, que assina certificados para comunicação unidirecional do servidor de API para kubelet.
  • Cada kubelet um também cria uma CSR (Solicitação de Assinatura de Certificado), que é assinada pela AC do cluster, para comunicação do para o servidor de kubelet API.
  • O repositório de valores de chave etcd tem um certificado assinado pela AC do Cluster para comunicação do etcd com o servidor de API.

etcd CA

O repositório de valores de chave etcd tem uma AC etcd que assina certificados para autenticar e autorizar a replicação de dados entre réplicas etcd no cluster.

AC de proxy frontal

A AC de Proxy Frontal protege a comunicação entre o servidor de API e o servidor de API de extensão.

Provisionamento de certificado

O provisionamento de certificado para um kubelet é feito usando inicialização TLS. Para todos os outros certificados, use a criação de certificado e chave baseada em YAML.

  • Os certificados são armazenados em /etc/kubernetes/pki.
  • As chaves são RSA 4096, EcdsaCurve: P384

Observação

Os certificados raiz são válidos por 10 anos. Todos os outros certificados não raiz são de curta duração e são válidos por quatro dias.

Renovação e gerenciamento de certificados

Certificados não raiz são renovados automaticamente. Todos os certificados do painel de controle para Kubernetes, exceto os seguintes certificados, são gerenciados:

  • Certificado do servidor Kubelet
  • Certificado do cliente Kubeconfig

Como prática recomendada de segurança, você deve usar o logon único do Active Directory para autenticação de usuário.

Revogação de certificado

A revogação do certificado deve ser rara e deve ser feita no momento da renovação do certificado.

Depois de ter o número de série do certificado que deseja revogar, use o Recurso Personalizado do Kubernetes para definir e persistir informações de revogação. Cada objeto de revogação pode consistir em uma ou mais entradas de revogação.

Para executar uma revogação, use uma das seguintes opções:

  • Número de série
  • Grupo
  • Nome DNS
  • Endereço IP

Um notBefore tempo pode ser especificado para revogar apenas certificados emitidos antes de um determinado carimbo de data/hora. Se um notBefore tempo não for especificado, todos os certificados existentes e futuros correspondentes à revogação serão revogados.

Observação

Atualmente, a revogação de certificados de kubelet servidor não está disponível.

Se você usar um número de série ao executar uma revogação, poderá usar o comando do Repair-AksHciClusterCerts PowerShell, descrito abaixo, para colocar o cluster em um estado de trabalho. Se você usar qualquer um dos outros campos listados anteriormente, especifique uma notBefore hora.

apiVersion: certificates.microsoft.com/v1 
kind: RenewRevocation 
metadata: 
  name: my-renew-revocation 
  namespace: kube-system 
spec: 
  description: My list of renew revocations 
  revocations: 
  - description: Revoked certificates by serial number 
    kind: serialnumber 
    notBefore: "2020-04-17T17:22:05Z" 
    serialNumber: 77fdf4b1033b387aaace6ce1c18710c2 
  - description: Revoked certificates by group 
    group: system:nodes 
    kind: Group 
  - description: Revoked certificates by DNS 
    dns: kubernetes.default.svc. 
    kind: DNS 
  - description: Revoked certificates by DNS Suffix 
    dns: .cluster.local 
    kind: DNS 
  - description: Revoked certificates by IP 
    ip: 170.63.128.124 
    kind: IP

Próximas etapas