Compartir a través de

Implementación de PKI del operador de Azure Nexus

El operador de Azure Nexus implementa una infraestructura de clave pública en clúster (PKI) en cada clúster. Cada clúster mantiene una jerarquía de entidad de certificación (CA) que está autofirmada y nunca sale del sitio, lo que garantiza que la confianza criptográfica esté aislada por cada implementación. Este aislamiento minimiza el impacto de cualquier riesgo.

Introducción a la arquitectura PKI

  • Límite de confianza por clúster: cada instancia de Nexus del operador de Azure aprovisiona una entidad de certificación raíz independiente. No hay ninguna entidad de certificación compartida entre clústeres y los certificados nunca se reutilizan entre sitios.
  • Emisión independiente: la emisión y renovación de certificados se realizan localmente dentro del plano de control de Kubernetes. Los certificados no se solicitan desde servicios PKI externos ni centralizados.
  • Emisores específicos de propósito: emisores intermedios dedicados firman certificados para cargas de trabajo distintas (consolas operadas por humanos frente a servicios internos) para minimizar el ámbito de privilegios.

Esta arquitectura permite a los clientes operar en entornos desconectados o semiconectados, a la vez que se conservan las ventajas de la autenticación TLS, el cifrado en tránsito y la auditabilidad criptográfica.

Administración de certificados con cert-manager

El operador de Azure Nexus se basa en cert-manager para automatizar los ciclos de vida de los certificados:

  • Los objetos emisores se definen para cada propósito de certificado (acceso de interfaz, servicios internos y otras cargas de trabajo especializadas).
  • Los recursos de certificado solicitan certificados de hoja del emisor adecuado, incluidos los nombres alternativos del sujeto (SAN) requeridos por los componentes de la plataforma.
  • La automatización de la renovación está controlada por cert-manager, que renueva los certificados hoja antes de la expiración y los rota de forma transparente en toda la plataforma.
  • La distribución secreta a pods y servicios se controla a través de secretos de Kubernetes y volúmenes proyectados, lo que garantiza que las cargas de trabajo siempre presentan certificados válidos.

Rotación y duración de certificados

  • Rotación automática: cert-manager renueva los certificados antes de que expiren en función de la Certificate configuración de recursos (como duration y renewBefore).
  • Vigencia predeterminada del certificado: la mayoría de los certificados TLS hoja del Operador de Azure Nexus se emiten durante 70 días.
  • Excepciones: algunos componentes usan diferentes duraciones.
    • Snapshotter de Etcd: emite certificados de servidor y cliente con una duración de 1 año .
    • Servicio de Token: emite certificados de CA y de servidor con una validez de 3 años.
  • Ventana de renovación: los certificados normalmente se renuevan aproximadamente 23 días antes de la expiración.

Importante

Si expira un certificado TLS, los clientes que validan TLS rechazan la conexión. Algunas herramientas orientadas al usuario le permiten omitir la validación (por ejemplo, un clic en el explorador), pero los servicios de plataforma requieren validación para mantenerse activado. Renueve el certificado para que las cargas de trabajo recojan el secreto actualizado.

Advertencia

iDRAC espera una vigencia de certificado de 60 días y genera alertas a medida que se acerca la expiración. Esto difiere de la duración de la plataforma de 70 días y está en revisión. La renovación de certificados se inicia actualmente aproximadamente 13 días antes de la expiración esperada de iDRAC.

Dado que toda la emisión está en clúster, los operadores conservan el control total sobre el tejido de confianza sin depender de la conectividad o los servicios externos.

Jerarquía del emisor

Se implementan dos emisores principales por clúster para cumplir con los diferentes requisitos de confianza de las interfaces operadas por humanos y las cargas de trabajo de servicios.

Emisor de interfaz

  • Propósito: firma los certificados TLS utilizados por las interfaces de recursos, incluidos BMC/iDRAC de la máquina bare metal y los puntos de conexión de administración de dispositivos de almacenamiento.
  • Ámbito: solo certificados para extremos de administración.
  • Rotación: cert-manager renueva los certificados de interfaz antes del vencimiento. Normalmente, estos certificados se emiten durante 70 días y se renuevan antes de la expiración.

Emisor de infraestructura

  • Propósito: emite certificados para microservicios de plataforma y API de servicio a servicio.
  • Ámbito: servicios de webhook internos y otras cargas de trabajo de plataforma.
  • Rotación: los certificados se rotan automáticamente. Normalmente, estos certificados se emiten durante 70 días y se renuevan antes de la expiración.

Escenarios de uso de certificados

Scenario Emisor Consumidores de ejemplo Objetivo de confianza
Acceso de administración fuera de banda Interfaz Consolas de iDRAC, paneles del dispositivo de almacenamiento, interfaces de cristal Proporcionar rutas de acceso humana cifradas y autenticadas
Tráfico del plano de control de la plataforma Infraestructura webhooks de admisión, microservicios de plataforma Garantizar la comunicación de servicio a servicio cifrada y la autenticación mutua

Visualización de certificados de autoridad de certificación y hashes

A menudo, los operadores necesitan comprobar que los endpoints TLS presentan el certificado de Autoridad de Certificación esperado y la huella digital. El Operador de Azure Nexus expone esta información a través de Azure Portal y la CLI de Azure.

Nota:

La visualización de los metadatos del certificado CA requiere la versión 2025-09-01 de la API de Azure Operator Nexus o posterior.

Recursos de máquina sin sistema operativo

  1. Portal de Azure:

    1. Vaya a Azure Operator Nexus Bare metal machines (Máquinas sin sistema operativo de Nexus > de Azure Operador).
    2. Abra el recurso de máquina física de destino.
    3. Seleccione Vista JSON.
    4. Seleccione 2025-09-01 o una versión posterior de la API.
    5. Revise el certificado de CA valor y el hash SHA-256 de la autoridad emisora que firmó el certificado TLS activo.

  2. CLI de Azure:

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

    Este comando devuelve el certificado de CA codificado en PEM que emitió el certificado TLS actual y su hash SHA-256 (huella digital) para realizar una comparación rápida con los valores de confianza.

Recursos del dispositivo de almacenamiento

  1. Portal de Azure:

    1. Vaya a los dispositivos de almacenamiento de Azure Operator Nexus.
    2. Abra el recurso del dispositivo de almacenamiento de destino.
    3. Seleccione Vista JSON.
    4. Seleccione 2025-09-01 o una versión posterior de la API.
    5. Revise el certificado de CA valor y el hash SHA-256 de la autoridad emisora que firmó el certificado TLS activo.

  2. CLI de Azure:

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

Contenido relacionado

PKI es un componente de la seguridad de Azure Operator Nexus. El sistema PKI funciona con estos mecanismos de rotación de credenciales para proporcionar autenticación y cifrado completos en toda la plataforma.

  • Last updated on