Visão geral do gerenciamento de certificados no AKS no Windows Server

Aplica-se a: AKS no Windows Server

O AKS no Windows Server 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 operações diferentes 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 de nuvem

Quando você implanta o AKS no Windows Server, 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 da plataforma subjacente.
• Agente de nó: um serviço que reside em cada nó que faz o trabalho real de criação, exclusão e outras operações de máquinas virtuais.
• Sistema de Gerenciamento de Chaves (KMS) pod: 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 no Windows Server:

• 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 rotaciona todos os tokens que não podem ser auto-rotacionados 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.

Proteger a comunicação com certificados no AKS no Windows Server

Os certificados são usados para criar uma comunicação segura entre os componentes no cluster. O AKS oferece provisionamento e gerenciamento automáticos e prontos para uso de certificados para componentes internos incorporados do Kubernetes. Neste artigo, você aprenderá a provisionar e gerenciar certificados no AKS no Windows Server.

Certificados e CAs

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

Cluster CA

• O servidor de API tem um Cluster AC, que assina certificados para uma comunicação unidirecional do servidor de API para kubelet.
• Cada kubelet também cria uma Solicitação de Assinatura de Certificado (CSR), que é assinada pela CA do Cluster, para comunicação do kubelet para o servidor da 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.

Autoridade Certificadora de Proxy Frontal

A CA do 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 chave e certificado baseada em YAML.

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

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 ponto no tempo. Se um notBefore tempo não for especificado, todos os certificados existentes e futuros que corresponderem à revogação serão revogados.

Se você usar um número de série ao executar uma revogação, poderá usar o comando do Repair-AksHciClusterCerts PowerShell, descrito da seguinte maneira, para colocar o cluster em um estado de trabalho. 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 

Próximas etapas

• Atualizar certificados
• Implantar aplicativos Linux em um cluster do Kubernetes
• Implantar um aplicativo do Windows Server em um cluster do Kubernetes