Introducción a la seguridad de Azure Kubernetes Application Network (versión preliminar)

Importante

Las características en versión preliminar de AKS están disponibles a elección del usuario y en régimen de autoservicio. Las versiones preliminares se proporcionan "tal cual" y "como están disponibles", y están excluidas de los Acuerdos de nivel de servicio y garantía limitada. Las versiones preliminares de AKS cuentan con soporte parcial por parte del servicio al cliente en la medida de lo posible. Por lo tanto, estas características no están diseñadas para su uso en producción. Para más información, consulte los siguientes artículos de soporte:

Azure Kubernetes Application Network protege la comunicación entre los servicios de los clústeres de Azure Kubernetes Service (AKS) conectados a través de TLS mutua automática (mTLS) y la autorización basada en identidades. Emite identidades de carga de trabajo y administra la emisión, rotación y validación de certificados para habilitar la comunicación cifrada, autenticada y explícitamente autorizada entre servicios sin configuración manual, con cifrado compatible con FIPS en tránsito.

En este artículo se proporciona información general sobre las características de seguridad de Azure Kubernetes Application Network, como mTLS, identidades de carga de trabajo, administración de certificados y directivas de autorización. También se describen las limitaciones y los pasos siguientes para implementar la comunicación segura en el entorno de Azure Kubernetes Application Network.

Limitaciones

  • Actualmente, una entidad de certificación administrada por Azure Kubernetes Application Network emite certificados y no están encadenados a una entidad de certificación pública.

mTLS

Application Network usa mTLS para proporcionar comunicación cifrada basada en identidades entre cargas de trabajo. Cada servicio de un clúster conectado a Application Network recibe automáticamente un certificado que le permite demostrar su identidad y establecer conexiones cifradas de confianza con otros servicios en la misma red de aplicaciones. El cifrado en tránsito usa criptografía compatible con FIPS.

Estrategia de migración de mTLS

La red de aplicaciones permite actualmente el tráfico cifrado y sin cifrar. Este enfoque garantiza que las cargas de trabajo existentes sigan funcionando normalmente mientras las cargas de trabajo nuevas o actualizadas usan automáticamente mTLS para una comunicación segura. Esto significa que puede adoptar mTLS para una comunicación segura entre las cargas de trabajo sin tiempo de inactividad. Una vez completada la migración, puede cambiar al modo estricto para que se aplique la autenticación.

Ventajas de mTLS en Azure Kubernetes Application Network

mTLS en Azure Kubernetes Application Network le ayuda a:

  • Proteger datos en tránsito: todo el tráfico de servicio a servicio se puede cifrar automáticamente (compatible con FIPS).
  • Comprobación de la identidad del servicio: cada carga de trabajo tiene un certificado raíz administrado por la red de aplicaciones único y un certificado intermedio.
  • Simplificar las operaciones: Application Network controla la emisión, la rotación y la revocación de certificados para los usuarios.

Administración de certificados

Azure Kubernetes Application Network proporciona administración de certificados respaldada por Azure Key Vault que emite y mantiene los certificados usados para mTLS. Este servicio establece un límite de confianza compartido en todos los clústeres de AKS conectados al mismo recurso de Application Network.

Application Network administra automáticamente todo el ciclo de vida del certificado para los certificados raíz e intermedio, incluido el aprovisionamiento, la renovación y la rotación. Esto garantiza que las identidades de carga de trabajo permanezcan válidas y la comunicación permanezca segura con el tiempo. No es necesario crear, almacenar ni rotar certificados manualmente.

En el diagrama siguiente se muestra la jerarquía de certificados en Application Network, en la que se muestra cómo se estructuran la entidad de certificación raíz, las CA intermedias y los certificados de carga de trabajo para establecer la confianza en los clústeres conectados:

Captura de pantalla de un diagrama que muestra la jerarquía de certificados en Azure Kubernetes Application Network, en la que se muestra cómo se estructuran la entidad de certificación raíz, las CA intermedias y los certificados de carga de trabajo para establecer la confianza en los clústeres conectados.

Jerarquía y ciclo de vida de los certificados

Cuando se crea un recurso de Application Network, se aprovisiona una CA raíz para servir como autoridad de confianza para la Application Network. Cuando un clúster de AKS se une a Application Network como miembro, Application Network emite un certificado intermedio para ese miembro firmado por la entidad de certificación raíz de Application Network. Cada clúster de AKS conectado usa su certificado intermedio administrado por Application Network para emitir certificados de carga de trabajo de corta duración a las cargas de trabajo de ese clúster.

Todos los certificados de carga de trabajo heredan la confianza de la entidad de certificación raíz de la red de aplicaciones, manteniendo un límite de confianza unificado a través del recurso. La rotación de certificados raíz e intermedio se controla de forma transparente para los usuarios sin causar tiempo de inactividad ni interrupciones del tráfico. Esta jerarquía administrada garantiza una confianza coherente y verificable en todos los clústeres de una red de aplicaciones, a la vez que mantiene automáticamente la validez de cada certificado.

Desde cualquier clúster miembro, puede obtener el certificado de CA raíz del mapa de configuración istio-root-cert en el espacio de nombres applink-system.

Tipos de certificado y períodos de rotación

Tipo de certificado Ámbito Período de validez Período de rotación propósito
Root CA Red de aplicaciones de Azure Kubernetes 12 meses 6 meses Establece el límite de confianza para todos los clústeres conectados a la red de aplicaciones de Azure Kubernetes.
Autoridad de Certificación Intermedia Clúster 90 días 45 días Emite certificados de carga de trabajo para cargas de trabajo dentro de ese clúster
Certificado de carga de trabajo Carga de trabajo 24 horas 12 horas Autentica las cargas de trabajo y protege la comunicación entre servicios.

Autorización e identidad de cargas de trabajo

A medida que crecen las aplicaciones, los servicios suelen necesitar comunicarse de forma segura entre distintos espacios de nombres y entornos dentro de la misma implementación. Administrar certificados y asegurarse de que cada servicio puede comprobar a quién está hablando puede convertirse rápidamente en complejo y propenso a errores. Azure Kubernetes Application Network elimina esta sobrecarga mediante la asignación y administración automática de identidades de carga de trabajo.

Dentro de un entorno conectado a la red de aplicaciones, las cargas de trabajo se comunican de forma segura dentro y entre espacios de nombres. Para asegurarse de que cada servicio puede ser de confianza y autenticarse, Application Network asigna a cada carga de trabajo una identidad verificable que representa su espacio de nombres y su cuenta de servicio.

Cada carga de trabajo de Application Network recibe automáticamente una identidad única en el formato SPIFFE , que incluye su espacio de nombres y su cuenta de servicio. La identidad tiene el formato siguiente:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Esta identidad se inserta en el certificado de carga de trabajo y se usa para demostrar la identidad del servicio al comunicarse con otras cargas de trabajo. Azure Kubernetes Application Network usa este modelo de identidad basado en SPIFFE con directivas de autorización de Istio para que pueda definir reglas claras y coherentes para las que los servicios puedan comunicarse.

Definición de directivas de acceso

Puede usar Istio AuthorizationPolicies para controlar qué cargas de trabajo pueden comunicarse dentro de su entorno. Estas directivas permiten definir el acceso basado en identidades de carga de trabajo verificadas en lugar de en ubicaciones de red o direcciones IP. Este enfoque le ayuda a aplicar controles de acceso coherentes, incluso a medida que los servicios se escalan y se mueven entre nodos. Por ejemplo, puede permitir que solo pasarelas específicas o cargas de trabajo de espacios de nombres de confianza llamen a un servicio mediante la referencia a sus identidades SPIFFE en la lista de principales de la directiva, tal y como se muestra en el ejemplo siguiente.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Guía de diseño de directivas

Al diseñar directivas de autorización, tenga en cuenta los siguientes procedimientos recomendados:

  • Especifique siempre tanto el espacio de nombres como la cuenta de servicio para evitar accesos no intencionados entre distintos espacios de nombres.
  • Utilice principales para definir identidades de carga de trabajo explícitas para un acceso específico.
  • Use espacios de nombres para definir límites de confianza más amplios cuando corresponda.
  • Evite reglas que coincidan solo con nombres de cuenta de servicio sin espacios de nombres, ya que así podría otorgar acceso a todos los clústeres o entornos.
  • Combine AuthorizationPolicies con Kubernetes NetworkPolicies para aplicar el aislamiento basado en identidad y basado en red.

Nota:

La autorización de Azure Kubernetes Application Network se basa en la identidad de carga de trabajo comprobada en lugar de en la dirección IP. Esto garantiza una aplicación coherente incluso a medida que las cargas de trabajo se escalan o se mueven entre nodos.

Mediante la combinación de identidades, certificados y controles de directivas administrados por azure Kubernetes Application Network, puede implementar la comunicación de servicio basada en identidades y con privilegios mínimos, lo que garantiza el tráfico autenticado, cifrado y autorizado explícitamente entre cargas de trabajo entre clústeres.

Contenido relacionado

Para más información sobre Azure Kubernetes Application Network, consulte los artículos siguientes:

  • Se actualizó por última vez el