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 dentro da 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 na 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. Estes agentes incluem:

Cloud agent: um serviço que é 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 de máquina virtual, exclusão, etc.
Key Management System (KMS) pod: um serviço responsável pela gestão de chaves.
Outros serviços: operador de nuvem, gestor de certificados, etc.

O serviço de agente de nuvem no AKS é responsável por orquestrar as operações de criação, leitura, atualização e exclusão (CRUD) de componentes de infraestrutura, como máquinas virtuais (VMs), interfaces de rede virtual (VNICs) e redes virtuais (VNETs) 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 uma identidade para ser associada a ele, que define as regras de controle de acesso baseado em função (RBAC) associadas ao cliente. Cada identidade consiste em duas entidades:

Um token, usado para autenticação inicial, que retorna um certificado e
Um certificado, obtido a partir 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), no final do qual expira. Para acesso contínuo ao agente de nuvem, cada cliente exige que o certificado seja renovado e o token alternado.

Tipos de certificado

Existem dois tipos de certificados usados no AKS habilitado pelo Arc:

Certificado de CA do agente de nuvem: o certificado usado para assinar/validar certificados de cliente. Este certificado é válido durante 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. Estes certificados são geralmente 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 os 90 dias padrão a partir da data em que o cluster é atualizado.

Comunicação segura com certificados em AKS habilitados pela Arc

Os certificados são usados para criar comunicação segura entre componentes no cluster. O AKS fornece provisionamento zero-touch, pronto para uso e gerenciamento de certificados para componentes Kubernetes integrados. Neste artigo, você aprenderá como provisionar e gerenciar certificados no AKS habilitado pelo Arc.

Certificados e autoridades de certificação

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

AC de cluster

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

etcd CA

O armazenamento de valor de chave etcd tem uma CA etcd que assina certificados para autenticar e autorizar a replicação de dados entre réplicas etcd no cluster.

CA de proxy frontal

A autoridade de certificação do Front Proxy protege a comunicação entre o servidor de API e o servidor de API de extensão.

Provisionamento de certificados

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

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

Nota

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 gestão de certificados

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

Certificado do servidor Kubelet
Certificado de cliente Kubeconfig

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

Revogação do 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 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 uma das seguintes opções:

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

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

Nota

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 Repair-AksHciClusterCerts comando 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

Partilhar via