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

Artigo
11/23/2024

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 na plataforma. A autenticação baseada em certificado usa um certificado digital para identificar uma entidade (agente, máquina, 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 no cluster. Esses agentes incluem:

Agente de nuvem: um serviço responsável pela orquestração da 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 do Sistema de Gerenciamento de Chaves (KMS): 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 (criar, ler, atualizar e excluir) de componentes de infraestrutura, como VMs (Máquinas Virtuais), VNICs (Interfaces de 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 ele, o que define as regras de RBAC (Controle de Acesso Baseado 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 é de 90 dias), ao 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 habilitado 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 CA 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 para se manter 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 de 90 dias a partir da data em que o cluster é atualizado.

Comunicação segura com certificados no AKS habilitados pelo Arc

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

Certificados e CAs

O AKS gera e usa as seguintes autoridades de certificação (CAs) e certificados.

Cluster CA

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

etcd CA

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

CA 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 é feito usando a kubelet inicialização TLS. Para todos os outros certificados, use a criação de chave e certificado 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 válidos por quatro dias.

Renovação e gerenciamento de certificados

Os certificados não raiz são renovados automaticamente. Todos os certificados do plano de controle do 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 obter o número de série do certificado que deseja revogar, use o Recurso Personalizado do Kubernetes para definir e persistir as 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 um dos seguintes procedimentos:

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

Um notBefore horário 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 que corresponderem à revogação serão revogados.

Observação

A revogação de certificados de kubelet servidor não está disponível no momento.

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 funcionamento. Se você usar qualquer um dos outros campos listados anteriormente, certifique-se de especificar 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

Compartilhar via