Descrição geral da gestão de certificados no AKS ativado pelo Azure Arc

Artigo
01/11/2024

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

O AKS ativado pelo Azure Arc utiliza uma combinação de autenticação baseada em certificados e tokens para proteger a comunicação entre serviços (ou agentes) responsáveis por diferentes operações na plataforma. A autenticação baseada em certificados utiliza um certificado digital para identificar uma entidade (agente, computador, utilizador ou dispositivo) antes de conceder acesso a um recurso.

Agente da cloud

Quando implementa o AKS ativado pelo Arc, o AKS instala agentes que são utilizados para executar várias funções no cluster. Estes agentes incluem:

Agente da cloud: 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, eliminação, etc. da máquina virtual.
Pod do Sistema de Gestão de Chaves (KMS): um serviço responsável pela gestão de chaves.
Outros serviços: operador cloud, gestor de certificados, etc.

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

Para comunicar com o agente da cloud, os clientes necessitam que os certificados sejam aprovisionados para proteger esta comunicação. Cada cliente requer que uma identidade seja associada à mesma, o que define as regras de Controlo de Acesso Baseada em Funções (RBAC) associadas ao cliente. Cada identidade consiste em duas entidades:

Um token, utilizado para autenticação inicial, que devolve um certificado e
Um certificado, obtido a partir do processo de início de sessão acima e utilizado para autenticação em qualquer comunicação.

Cada entidade é válida por um período específico (a predefinição é 90 dias), no final da qual expira. Para continuar o acesso ao agente da cloud, cada cliente requer que o certificado seja renovado e o token rodado.

Tipos de certificado

Existem dois tipos de certificados utilizados no AKS ativados pelo Arc:

Certificado de AC do agente da cloud: o certificado utilizado para assinar/validar certificados de cliente. Este certificado é válido durante 365 dias (1 ano).
Certificados de cliente: certificados emitidos pelo certificado de AC do agente da cloud para que os clientes se autentiquem no agente da cloud. Normalmente, estes certificados são válidos durante 90 dias.

A Microsoft recomenda que atualize clusters no prazo de 60 dias após uma nova versão, não só para garantir que os certificados e tokens internos são mantidos atualizados, mas também para garantir que obtém acesso a novas funcionalidades, correções de erros e para se manter atualizado com patches de segurança críticos. Durante estas atualizações mensais, o processo de atualização roda todos os tokens que não podem ser rodados automaticamente durante as operações normais do cluster. A validade do certificado e do token é reposta para os 90 dias predefinidos a partir da data em que o cluster é atualizado.

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

Os certificados são utilizados para criar uma comunicação segura entre componentes no cluster. O AKS fornece aprovisionamento sem toque, fora da caixa e gestão de certificados para componentes incorporados do Kubernetes. Neste artigo, irá aprender a aprovisionar e gerir certificados no AKS ativado pelo Arc.

Certificados e ACs

O AKS gera e utiliza as seguintes Autoridades de Certificação (ACs) 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 um Pedido de Assinatura de Certificados (CSR), assinado pela AC de Cluster, para comunicação a kubelet partir do servidor de API.
O arquivo de valores de chave etcd tem um certificado assinado pela AC de Cluster para comunicação do etcd para o servidor de API.

AC etcd

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

AC de Proxy Frontal

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

Aprovisionamento de certificados

O aprovisionamento de certificados para um kubelet é feito com o bootstrapping TLS. Para todos os outros certificados, utilize 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 de raiz são válidos durante 10 anos. Todos os outros certificados não raiz são de curta duração e são válidos durante quatro dias.

Renovação e gestão de certificados

Os certificados não raiz são renovados automaticamente. Todos os certificados do plano de controlo do Kubernetes, exceto os seguintes certificados, são geridos:

Certificado do servidor kubelet
Certificado de cliente do Kubeconfig

Como melhor prática de segurança, deve utilizar o início de sessão único do Active Directory para autenticação de utilizador.

Revogação de certificados

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

Assim que tiver o número de série do certificado que pretende revogar, utilize o Recurso Personalizado do Kubernetes para definir e manter as informações de revogação. Cada objeto de revogação pode consistir numa ou mais entradas de revogação.

Para efetuar uma revogação, utilize um dos seguintes procedimentos:

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

Pode notBefore especificar uma hora para revogar apenas os 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á atualmente disponível.

Se utilizar um número de série quando efetua uma revogação, pode utilizar o comando do Repair-AksHciClusterCerts PowerShell, descrito abaixo, para colocar o cluster num estado de trabalho. Se utilizar qualquer um dos outros campos listados anteriormente, certifique-se de que especifica 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