Partilhar via

Implementação da PKI do Azure Operator Nexus

Azure Operator Nexus implanta uma infraestrutura de chave pública (PKI) em todos os clusters. Cada cluster mantém uma hierarquia de autoridade de certificação (CA) autoassinada que nunca deixa o local, garantindo que a confiança criptográfica é mantida isolada por implantação. Esse isolamento minimiza o impacto de qualquer comprometimento.

Visão geral da arquitetura PKI

  • Limite de confiança por cluster: cada instância do Azure Operator Nexus provisiona uma CA raiz independente. Não há CA compartilhada entre clusters e os certificados nunca são reutilizados entre sites.
  • Emissão independente: a emissão e a renovação do certificado são realizadas localmente dentro do plano de controle do Kubernetes. Os certificados não são solicitados de serviços PKI externos ou centralizados.
  • Emissores específicos para uma finalidade: emissores intermediários dedicados assinam certificados para diferentes cargas de trabalho (consoles operados por humanos versus serviços internos) a fim de minimizar o escopo de privilégios.

Essa arquitetura permite que os clientes operem em ambientes desconectados ou semiconectados, mantendo os benefícios da autenticação TLS, criptografia em trânsito e auditabilidade criptográfica.

Gestão de certificados com cert-manager

O Azure Operator Nexus depende do cert-manager para automatizar os ciclos de vida do certificado:

  • Os objetos do emissor são definidos para cada finalidade do certificado (acesso à interface, serviços internos e outras cargas de trabalho especializadas).
  • Os recursos de certificado solicitam certificados de folha do emissor apropriado, incluindo Nomes Alternativos de Entidade (SANs) necessários para os componentes da plataforma.
  • A automação da renovação é conduzida pelo cert-manager, que renova automaticamente os certificados de folha antes da expiração e os distribui de forma transparente por toda a plataforma.
  • A distribuição secreta para pods e serviços é tratada por meio de segredos do Kubernetes e volumes projetados, garantindo que as cargas de trabalho sempre apresentem certificados válidos.

Como toda a emissão está em cluster, os operadores mantêm controle total sobre a malha de confiança sem depender de conectividade ou serviços externos.

Hierarquia do emissor

Dois emissores principais são implantados por cluster, para se alinharem com os diferentes requisitos de confiança de interfaces operadas por humanos e cargas de trabalho de serviço.

Emissor de interface

  • Finalidade: Assina certificados TLS usados por interfaces de recursos, incluindo BMC/iDRAC de máquina física e pontos de gestão de dispositivos de armazenamento.
  • Escopo: somente certificados para pontos de gestão.
  • Rotação: o cert-manager renova os certificados de interface antes da expiração, garantindo que o acesso permaneça criptografado sem intervenção manual.

Emissor de infraestruturas

  • Finalidade: Emite certificados para microsserviços de plataforma e APIs de serviço a serviço.
  • Escopo: Serviços de webhook interno e outras cargas de trabalho da plataforma.
  • Rotação: os certificados são alternados automaticamente em coordenação com as atualizações contínuas da carga de trabalho para manter a disponibilidade ininterrupta do serviço.

Cenários de uso de certificados

Scenario Issuer Exemplos de consumidores Objetivo de confiança
Acesso de gestão fora de banda Interfaz Consolas iDRAC, painéis de instrumentos de armazenamento, interfaces de quebra-vidros Fornecer caminhos de acesso humano criptografados e autenticados
Tráfego do plano de controlo da plataforma Infraestrutura webhooks de admissão, plataforma de microsserviços Garantir a comunicação criptografada serviço a serviço e autenticação mútua

Exibindo certificados e hashes de CA

Os operadores geralmente precisam verificar se os pontos de extremidade TLS apresentam o certificado de CA e a impressão digital esperados. O Azure Operator Nexus expõe essas informações por meio do portal do Azure e da CLI do Azure.

Observação

A exibição de metadados de certificado de CA requer a versão da API do Azure Operator Nexus 2025-09-01 ou posterior.

Recursos de máquinas bare metal

  1. Portal do Azure:

    1. Navegue até Máquinas bare metal do Azure Operator Nexus>.
    2. Abra o recurso de máquina "bare metal" de destino.
    3. Selecione Visualização JSON.
    4. Selecione 2025-09-01 ou versão posterior da API/
    5. Analise o valor do certificado da autoridade de certificação e o hash SHA-256 do emissor que assinou o certificado TLS ativo.

  2. CLI do Azure:

    az networkcloud baremetalmachine show \
  --subscription <subscription>
  --resource-group <cluster-managed-resource-group> \
  --name <bareMetalMachineName> \
  --query "caCertificate" \
  --output tsv

    Este comando retorna o certificado de CA codificado em PEM que emitiu o certificado TLS atual e seu hash SHA-256 (impressão digital) para comparação rápida com valores confiáveis.

Recursos do dispositivo de armazenamento

  1. Portal do Azure:

    1. Navegue até Dispositivos de armazenamento do Azure Operator Nexus>.
    2. Abra o recurso do dispositivo de armazenamento de destino.
    3. Selecione Visualização JSON.
    4. Selecione 2025-09-01 ou versão posterior da API/
    5. Analise o valor do certificado da autoridade de certificação e o hash SHA-256 do emissor que assinou o certificado TLS ativo.

  2. CLI do Azure:

    az networkcloud storageappliance show \
  --subscription <subscription>
  --resource-group <cluster-managed-resource-group> \
  --name <storageApplianceName> \
  --query "caCertificate" \
  --output tsv
  • Last updated on