Descrição geral da gestão de certificados no AKS ativado pelo Azure Arc
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 akubelet
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
Passos seguintes
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários