Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Seguridad de la red

La seguridad de la red tiene varias facetas. La primera implica la aplicación de reglas que restringen el flujo del tráfico de red entre los servicios. El segundo implica el cifrado del tráfico mientras está en tránsito. Los mecanismos para implementar estas medidas de seguridad en EKS son variados, pero suelen incluir los siguientes elementos:

Control de tráfico

Network encryption

Política de red

En un clúster de Kubernetes, todas las comunicaciones de un pod a otro están permitidas de forma predeterminada. Si bien esta flexibilidad puede ayudar a promover la experimentación, no se considera segura. Las políticas de red de Kubernetes ofrecen un mecanismo para restringir el tráfico de red entre los Pods (lo que suele denominarse East/West tráfico), así como entre los Pods y los servicios externos. Las políticas de red de Kubernetes funcionan en las capas 3 y 4 del modelo OSI. Las políticas de red utilizan pods, selectores de espacios de nombres y etiquetas para identificar los pods de origen y destino, pero también pueden incluir direcciones IP, números de puerto, protocolos o una combinación de estos. Las políticas de red se pueden aplicar tanto a las conexiones entrantes como salientes al pod, lo que suele denominarse reglas de entrada y salida.

Gracias a la compatibilidad nativa con las políticas de red del complemento CNI de Amazon VPC, puede implementar políticas de red para proteger el tráfico de red en los clústeres de Kubernetes. Esto se integra con la API de políticas de red de Kubernetes original, lo que garantiza la compatibilidad y el cumplimiento de los estándares de Kubernetes. Puedes definir políticas usando diferentes identificadores compatibles con la API principal. https://kubernetes.io/docs/concepts/services-networking/network-policies/ De forma predeterminada, todo el tráfico de entrada y salida está permitido a un pod. Cuando se especifica una política de red con un valor de entrada de tipo político, solo se permiten las conexiones al pod desde el nodo del pod y las que permiten las reglas de entrada. Lo mismo se aplica a las reglas de salida. Si se definen varias reglas, se tendrá en cuenta la unión de todas las reglas al tomar la decisión. Por lo tanto, el orden de evaluación no afecta al resultado de la política.

Recomendaciones

Introducción a las políticas de red: siga el principio del mínimo privilegio

Crear una política de denegación predeterminada

Al igual que con las políticas de RBAC, se recomienda seguir los principios de acceso con menos privilegios junto con las políticas de red. Comience por crear una política de denegación total que restrinja todo el tráfico entrante y saliente dentro de un espacio de nombres.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

default-deny

Cree una regla para permitir las consultas de DNS

Una vez que hayas establecido la regla predeterminada de denegar todo, puedes empezar a agregar reglas adicionales, como una regla que permita a los pods consultar CoreDNS para la resolución de nombres.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-access
  namespace: default
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53

permitir el acceso al DNS

Agregue reglas de forma incremental para permitir de forma selectiva el flujo de tráfico entre namespaces/pods

Comprenda los requisitos de la aplicación y cree reglas de entrada y salida detalladas, según sea necesario. El siguiente ejemplo muestra cómo restringir el tráfico de entrada desde el puerto 80. app-one client-one Esto ayuda a minimizar la superficie de ataque y reduce el riesgo de acceso no autorizado.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-app-one
  namespace: default
spec:
  podSelector:
    matchLabels:
      k8s-app: app-one
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          k8s-app: client-one
    ports:
    - protocol: TCP
      port: 80

allow-ingress-app-one

Supervisar la aplicación de políticas de red

package kubernetes.admission
import data.kubernetes.networkpolicies

deny[msg] {
    input.request.kind.kind == "Pod"
    pod_label_value := {v["k8s-app"] | v := input.request.object.metadata.labels}
    contains_label(pod_label_value, "sample-app")
    np_label_value := {v["k8s-app"] | v := networkpolicies[_].spec.podSelector.matchLabels}
    not contains_label(np_label_value, "sample-app")
    msg:= sprintf("The Pod %v could not be created because it is missing an associated Network Policy.", [input.request.object.metadata.name])
}
contains_label(arr, val) {
    arr[_] == val
}

Resolución de problemas

Supervise los registros de vpc-network-policy-controller y node-agent

Habilite los registros del administrador de controladores del plano de control del EKS para diagnosticar la funcionalidad de la política de red. Puede transmitir los registros del plano de control a un CloudWatch grupo de registros y utilizar la información de los CloudWatch registros para realizar consultas avanzadas. En los registros, puede ver qué objetos de punto final del pod están resueltos en una política de red, el estado de conciliación de las políticas y depurar si la política funciona según lo esperado.

Además, el CNI de Amazon VPC le permite habilitar la recopilación y exportación de registros de cumplimiento de políticas a Amazon Cloudwatch desde los nodos de trabajo de EKS. Una vez habilitada, puede aprovechar CloudWatch Container Insights para obtener información sobre su uso en relación con las políticas de red.

Amazon VPC CNI también incluye un SDK que proporciona una interfaz para interactuar con los programas de eBPF del nodo. El SDK se instala cuando se implementa en los nodosaws-node. Puede encontrar el binario del SDK instalado en el /opt/cni/bin directorio del nodo. En el momento del lanzamiento, el SDK proporciona soporte para funcionalidades fundamentales, como la inspección de los programas y mapas del eBPF.

sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Registra los metadatos del tráfico de red

Los registros de flujo de la VPC de AWS capturan los metadatos sobre el tráfico que fluye a través de una VPC, como la dirección IP y el puerto de origen y destino, junto con accepted/dropped los paquetes. Esta información podría analizarse para detectar actividades sospechosas o inusuales entre los recursos de la VPC, incluidos los pods. Sin embargo, dado que las direcciones IP de los pods cambian con frecuencia a medida que se sustituyen, es posible que los registros de flujo no sean suficientes por sí solos. Calico Enterprise amplía los registros de flujo con etiquetas de los pods y otros metadatos, lo que facilita el descifrado de los flujos de tráfico entre los pods.

Grupos de seguridad

EKS usa los grupos de seguridad (SG) de VPC de AWS para controlar el tráfico entre el plano de control de Kubernetes y los nodos de trabajo del clúster. Los grupos de seguridad también se utilizan para controlar el tráfico entre los nodos de trabajo y otros recursos de la VPC, así como las direcciones IP externas. Cuando aprovisionas un clúster de EKS (con la versión 1.14-eks.3 o superior de Kubernetes), se crea automáticamente un grupo de seguridad de clúster para ti. Este grupo de seguridad permite una comunicación sin restricciones entre el plano de control de EKS y los nodos de los grupos de nodos gestionados. Para simplificar, se recomienda agregar el SG del clúster a todos los grupos de nodos, incluidos los grupos de nodos no administrados.

Antes de la versión 1.14 de Kubernetes y la versión eks.3 de EKS, había grupos de seguridad independientes configurados para el plano de control y los grupos de nodos de EKS. Las reglas mínimas y sugeridas para los grupos de seguridad del plano de control y del grupo de nodos se encuentran en Las reglas mínimas para https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html. el grupo de seguridad del plano de control permiten la entrada del puerto 443 desde el nodo de trabajo SG. Esta regla es la que permite a los kubelets comunicarse con el servidor API de Kubernetes. También incluye el puerto 10250 para el tráfico saliente al nodo de trabajo SG; el 10250 es el puerto en el que escuchan los kubelets. Del mismo modo, las reglas de grupos de nodos mínimos permiten que el puerto 10250 entre desde el plano de control SG y el 443 salga desde el plano de control SG. Por último, existe una regla que permite la comunicación sin restricciones entre los nodos de un grupo de nodos.

Si necesitas controlar la comunicación entre los servicios que se ejecutan dentro del clúster y los que se ejecutan fuera del clúster, como una base de datos de RDS, considera la posibilidad de usar grupos de seguridad para los pods. Con los grupos de seguridad para pods, puede asignar un grupo de seguridad existente a una colección de pods.

Para controlar qué pods se asignan a un grupo de seguridad, cree un SecurityGroupPolicy objeto y especifique a PodSelector o aServiceAccountSelector. Si se configuran los selectores en, {} se asignarán los SGs a los que se hace referencia en ellos SecurityGroupPolicy a todos los pods de un espacio de nombres o a todas las cuentas de servicio de un espacio de nombres. Asegúrese de familiarizarse con todas las consideraciones antes de implementar grupos de seguridad para los pods.

Si bien los grupos de seguridad para pods ofrecen una AWS-native forma de controlar el tráfico de red dentro y fuera del clúster sin la sobrecarga de un demonio de políticas, hay otras opciones disponibles. Por ejemplo, el motor de políticas de Cilium permite hacer referencia a un nombre DNS en una política de red. Calico Enterprise incluye una opción para asignar las políticas de red a los grupos de seguridad de AWS. Si ha implementado una red de servicios como Istio, puede usar una puerta de enlace de salida para restringir la salida de la red a dominios o direcciones IP específicos y totalmente calificados. Para obtener más información sobre esta opción, lee la serie de tres partes sobre el control del tráfico de salida en Istio.

¿Cuándo usar la política de red o el grupo de seguridad para pods?

¿Cuándo usar la política de red de Kubernetes?

Cuándo usar los grupos de seguridad de AWS para pods (SGP)

Prácticas recomendadas para usar los grupos de seguridad para los pods y la política de red

En lo que respecta a la seguridad de la red, la solución más eficaz suele ser un enfoque por capas. El uso combinado de la política de red de Kubernetes y el SGP puede proporcionar una estrategia sólida de defensa en profundidad para las aplicaciones que se ejecutan en EKS.

Aplicación de políticas de Service Mesh o política de red de Kubernetes

A service mesh es una capa de infraestructura dedicada que puede agregar a sus aplicaciones. Le permite agregar de manera transparente capacidades como la observabilidad, la administración del tráfico y la seguridad, sin agregarlas a su propio código.

La malla de servicios aplica las políticas en la capa 7 (aplicación) del modelo OSI, mientras que las políticas de red de Kubernetes funcionan en la capa 3 (red) y la capa 4 (transporte). Hay muchas ofertas en este ámbito, como AWSAppMesh, Istio, Linkerd, etc.

¿Cuándo usar Service mesh para la aplicación de políticas

Elige la política de red de Kubernetes para casos de uso más sencillos

ThirdParty Motores de políticas de red

Considere la posibilidad de utilizar un motor de políticas de red de terceros si tiene requisitos de política avanzados, como políticas de red globales, compatibilidad con reglas basadas en nombres de host de DNS, reglas de capa 7, reglas ServiceAccount basadas y deny/log acciones explícitas, etc. Calico es un motor de políticas de código abierto de Tigera que funciona bien con EKS. Además de implementar el conjunto completo de funciones de políticas de red de Kubernetes, Calico admite políticas de red ampliadas con un conjunto más completo de funciones, incluida la compatibilidad con reglas de capa 7, por ejemplo, HTTP, cuando se integra con Istio. Las políticas de Calico se pueden aplicar a los espacios de nombres, los pods, las cuentas de servicio o a nivel mundial. Cuando las políticas se aplican a una cuenta de servicio, se asocia un conjunto de ingress/egress reglas a esa cuenta de servicio. Con las reglas de RBAC adecuadas, puede evitar que los equipos las anulen, lo que permite a los profesionales de seguridad de TI delegar de forma segura la administración de los espacios de nombres. Isovalent, la empresa que mantiene Cilium, también ha ampliado las políticas de red para incluir la compatibilidad parcial con las reglas de la capa 7, por ejemplo, HTTP. Cilium también admite nombres de host DNS, lo que puede resultar útil para restringir el tráfico entre Kubernetes Services/Pods y los recursos que se ejecutan dentro o fuera de tu VPC. Por el contrario, Calico Enterprise incluye una función que permite asignar una política de red de Kubernetes a un grupo de seguridad de AWS, así como a los nombres de host de DNS.

Puedes encontrar una lista de políticas de red comunes de Kubernetes en. https://github.com/ahmetb/kubernetes-network-policy-recipes. Un conjunto similar de reglas para Calico está disponible en https://docs.projectcalico.org/security/calico-network-policy.

Migración al motor de políticas de red CNI de Amazon VPC

Para mantener la coherencia y evitar un comportamiento inesperado de comunicación entre los pods, se recomienda implementar solo un motor de políticas de red en el clúster. Si quieres migrar de 3P a VPC CNI Network Policy Engine, te recomendamos que conviertas tus NetworkPolicy CRD de 3P existentes en NetworkPolicy recursos de Kubernetes antes de habilitar la compatibilidad con las políticas de red CNI de VPC. Además, prueba las políticas migradas en un clúster de prueba independiente antes de aplicarlas en tu entorno de producción. Esto le permite identificar y abordar cualquier posible problema o incoherencia en el comportamiento de comunicación del pod.

Herramienta de migración

Para ayudarlo en su proceso de migración, hemos desarrollado una herramienta llamada K8s Network Policy Migrator que convierte sus CRD de políticas de Calico/Cilium red existentes en políticas de red nativas de Kubernetes. Tras la conversión, puede probar directamente las políticas de red convertidas en sus nuevos clústeres que ejecuten el controlador de políticas de red CNI de VPC. La herramienta está diseñada para ayudarlo a agilizar el proceso de migración y garantizar una transición sin problemas.

Tenga en cuenta que, por el momento, el equipo de ingeniería de políticas de la red CNI de AWS VPC no admite la herramienta de migración; por el contrario, se pone a disposición de los clientes en la medida de lo posible. Le recomendamos que utilice esta herramienta para facilitar el proceso de migración. En caso de que encuentre algún problema o error con la herramienta, le rogamos que cree un GitHub problema. Sus comentarios son de un valor incalculable para nosotros y nos ayudarán a mejorar continuamente nuestros servicios.

Recursos adicionales

Cifrado en tránsito

Es posible que las aplicaciones que deben cumplir las normativas PCI, HIPAA u otras normativas tengan que cifrar los datos mientras están en tránsito. Hoy en día, TLS es la opción de facto para cifrar el tráfico en la red. TLS, al igual que su predecesor SSL, proporciona comunicaciones seguras a través de una red mediante protocolos criptográficos. El TLS utiliza un cifrado simétrico, en el que las claves para cifrar los datos se generan en función de un secreto compartido que se negocia al principio de la sesión. A continuación se muestran algunas maneras de cifrar los datos en un entorno de Kubernetes.

Instancias Nitro

El tráfico que se intercambia entre los siguientes tipos de instancias de Nitro, por ejemplo, C5n, G4, I3en, M5dn, M5n, P3dn, R5dn y R5n, se cifra automáticamente de forma predeterminada. Cuando hay un salto intermedio, como una pasarela de tránsito o un balanceador de cargas, el tráfico no se cifra. Consulta el cifrado en tránsito para obtener más información sobre el cifrado en tránsito, así como la lista completa de los tipos de instancias que admiten el cifrado de red de forma predeterminada.

Service Mesh

El cifrado en tránsito también se puede implementar con una malla de servicios como App Mesh, Linkerd v2 e Istio. AppMesh admite mTLS con X.509 certificados o con el Servicio Secreto de Descubrimiento (SDS) de Envoy. Tanto Linkerd como Istio son compatibles con los mTLS.

El GitHub repositorio aws-app-mesh-examples proporciona tutoriales para configurar los mTLS con certificados y SPIRE como proveedor de SDS con tu contenedor Envoy: X.509

App Mesh también admite el cifrado TLS con un certificado privado emitido por AWS Certificate Manager (ACM) o un certificado almacenado en el sistema de archivos local del nodo virtual.

El GitHub repositorio aws-app-mesh-examples proporciona tutoriales para configurar el TLS mediante los certificados emitidos por ACM y los certificados que vienen empaquetados con su contenedor Envoy:

Controladores de ingreso y balanceadores de carga

Los controladores de ingreso permiten enrutar de manera inteligente el HTTP/S tráfico que proviene del exterior del clúster a los servicios que se ejecutan dentro del clúster. Con frecuencia, estos ingresos están dirigidos por un balanceador de cargas de nivel 4, como el balanceador de cargas clásico o el balanceador de cargas de red (NLB). El tráfico cifrado puede terminar en diferentes lugares de la red, por ejemplo, en el balanceador de cargas, en el recurso de entrada o en el pod. En última instancia, la política de seguridad de red de la organización determinará cómo y dónde se interrumpa la conexión SSL. Por ejemplo, si tienes una política que exige el cifrado de extremo a extremo, tendrás que descifrar el tráfico del Pod. Esto supondrá una carga adicional para tu Pod, ya que tendrá que dedicar varios ciclos a establecer el apretón de manos inicial. En general, el SSL/TLS procesamiento consume mucha CPU. Por lo tanto, si tienes la flexibilidad necesaria, prueba a realizar la descarga de SSL en el Ingress o en el balanceador de cargas.

Utilice el cifrado con los balanceadores de cargas de AWS Elastic

Tanto el balanceador de carga de aplicaciones (ALB) como el balanceador de carga de red (NLB) de AWS admiten el cifrado del transporte (SSL y TLS). La alb.ingress.kubernetes.io/certificate-arn anotación de la ALB le permite especificar qué certificados desea agregar a la ALB. Si omite la anotación, el controlador intentará agregar certificados a los oyentes que lo requieran haciendo coincidir los certificados de AWS Certificate Manager (ACM) disponibles mediante el campo de host. A partir de la versión 1.15 de EKS, puede usar la service.beta.kubernetes.io/aws-load-balancer-ssl-cert anotación con el NLB, tal y como se muestra en el ejemplo siguiente.

apiVersion: v1
kind: Service
metadata:
  name: demo-app
  namespace: default
  labels:
    app: demo-app
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "<certificate ARN>"
     service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 80
    protocol: TCP
  selector:
    app: demo-app
//---
kind: Deployment
apiVersion: apps/v1
metadata:
  name: nginx
  namespace: default
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 443
              protocol: TCP
            - containerPort: 80
              protocol: TCP

A continuación se muestran ejemplos adicionales de terminación. SSL/TLS

ACM Private CA con cert-manager

Puede habilitar TLS y mTLS para proteger las cargas de trabajo de las aplicaciones de EKS en el momento de la entrada, en el pod y entre los pods mediante ACM Private Certificate Authority (CA) y cert-manager, un popular complemento de Kubernetes para distribuir, renovar y revocar certificados. ACM Private CA es una CA gestionada, segura y de alta disponibilidad, sin los costes iniciales y de mantenimiento que supone gestionar su propia CA. Si utilizas la entidad emisora de certificados predeterminada de Kubernetes, tienes la oportunidad de mejorar tu seguridad y cumplir los requisitos de cumplimiento de ACM Private CA. ACM Private CA protege las claves privadas en los módulos de seguridad de hardware FIPS 140-2 de nivel 3 (muy seguros), en comparación con la CA predeterminada que almacena las claves codificadas en la memoria (menos seguras). Una CA centralizada también ofrece más control y una auditabilidad mejorada para los certificados privados, tanto dentro como fuera de un entorno de Kubernetes.

Short-Lived Modo CA para TLS mutuo entre cargas de trabajo

Cuando utilice ACM Private CA para mTLS en EKS, se recomienda utilizar certificados de corta duración en modo CA de corta duración. Si bien es posible emitir certificados de corta duración en el modo CA de uso general, utilizar el modo de CA de corta duración resulta más rentable (aproximadamente un 75% más barato que el modo general) en los casos en los que es necesario emitir nuevos certificados con frecuencia. Además, debes intentar alinear el período de validez de los certificados privados con la vida útil de los pods de tu clúster de EKS. Obtenga más información sobre ACM Private CA y sus ventajas aquí.

Instrucciones de configuración de ACM

Comience por crear una CA privada siguiendo los procedimientos que se proporcionan en la documentación técnica de ACM Private CA. Una vez que tenga una CA privada, instale cert-manager siguiendo las instrucciones de instalación habituales. Tras instalar cert-manager, instale el complemento de gestión de certificados de Kubernetes de Private CA siguiendo las instrucciones de configuración que aparecen en. GitHub El complemento permite al administrador de certificados solicitar certificados privados de ACM Private CA.

Ahora que tiene una CA privada y un clúster de EKS con el administrador de certificados y el complemento instalados, es el momento de establecer los permisos y crear el emisor. Actualice los permisos de IAM del rol de nodo de EKS para permitir el acceso a la CA privada de ACM. Sustituya el <CA_ARN> por el valor de su CA privada:

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "awspcaissuer",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:GetCertificate",
                "acm-pca:IssueCertificate"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:acm-pca:us-west-2:123456789012:certificate-authority/12345678-1234-1234-1234-123456789012"
        }
    ]
}

También se pueden usar las funciones de servicio para las cuentas de IAM o IRSA. Consulte la sección de recursos adicionales que aparece a continuación para ver ejemplos completos.

Cree un emisor en Amazon EKS creando un archivo de definición de recursos personalizado denominado cluster-issuer.yaml con el texto siguiente y sustituyendo <CA_ARN> la información por su CA privada. <Region>

apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
          name: demo-test-root-ca
spec:
          arn: <CA_ARN>
          region: <Region>

Implemente el emisor que creó.

kubectl apply -f cluster-issuer.yaml

Su clúster de EKS está configurado para solicitar certificados de una CA privada. Ahora puede usar el Certificate recurso de cert-manager para emitir certificados cambiando los valores del issuerRef campo por los del emisor de CA privado que creó anteriormente. Para obtener más información sobre cómo especificar y solicitar los recursos de certificación, consulte la guía de recursos de certificación de cert-manager. https://cert-manager.io/docs/usage/certificate/ Consulta los ejemplos aquí.

ACM Private CA con Istio y cert-manager

Si ejecuta Istio en su clúster de EKS, puede deshabilitar el plano de control de Istio (específicamenteistiod) para que no funcione como la autoridad de certificación (CA) raíz y configurar ACM Private CA como la CA raíz para los mTLS entre cargas de trabajo. Si opta por este enfoque, considere la posibilidad de utilizar el modo CA de corta duración en ACM Private CA. Consulte la sección anterior y esta entrada de blog para obtener más información.

Cómo funciona la firma de certificados en Istio (predeterminado)

Las cargas de trabajo en Kubernetes se identifican mediante cuentas de servicio. Si no especificas una cuenta de servicio, Kubernetes la asignará automáticamente a tu carga de trabajo. Además, las cuentas de servicio montan automáticamente un token asociado. La cuenta de servicio utiliza este token para que las cargas de trabajo se autentiquen en la API de Kubernetes. La cuenta de servicio puede ser suficiente como identidad para Kubernetes, pero Istio tiene su propio sistema de administración de identidades y CA. Cuando se inicia una carga de trabajo con su proxy sidecar Envoy, es necesario que Istio le asigne una identidad para que se considere fiable y se le permita comunicarse con otros servicios de la red.

Para obtener esta identidad de Istio, istio-agent envía una solicitud conocida como solicitud de firma de certificados (o CSR) al plano de control de Istio. Esta CSR contiene el token de la cuenta de servicio para poder verificar la identidad de la carga de trabajo antes de procesarla. Este proceso de verificación lo gestiona istiod la entidad que actúa como autoridad de registro (o RA) y como entidad emisora de certificados. La RA actúa como un guardián que se asegura de que solo una CSR verificada llegue a la CA. Una vez verificada la CSR, se reenviará a la CA, que emitirá un certificado con una identidad de SPIFFE junto con la cuenta de servicio. Este certificado se denomina documento de identidad verificable de SPIFFE (o SVID). El SVID se asigna al servicio solicitante con fines de identificación y para cifrar el tráfico en tránsito entre los servicios de comunicación.

Flujo predeterminado para las solicitudes de firma de certificados de Istio:

Cómo funciona la firma de certificados en Istio con ACM Private CA

Puede usar un complemento de gestión de certificados denominado agente de solicitud de firma de certificados de Istio (https://cert-manager.io/docs/projects/istio-csr/istio-csr) para integrar Istio con ACM Private CA. Este agente permite proteger las cargas de trabajo y los componentes del plano de control de Istio con emisores de gestores de certificados, en este caso ACM Private CA. El agente istio-csr expone el mismo servicio que ofrece istiod en la configuración predeterminada de validación de las CSR entrantes. Salvo que, tras la verificación, convertirá las solicitudes en recursos compatibles con el administrador de certificados (es decir, integraciones con emisores de CA externos).

Siempre que haya una CSR de una carga de trabajo, se reenviará a istio-csr, que solicitará los certificados de ACM Private CA. Esta comunicación entre istio-csr y ACM Private CA se habilita mediante el complemento emisor de AWS Private CA. https://github.com/cert-manager/aws-privateca-issuer El administrador de certificados usa este complemento para solicitar certificados TLS a ACM Private CA. El complemento emisor se comunicará con el servicio ACM Private CA para solicitar un certificado firmado para la carga de trabajo. Una vez que se haya firmado el certificado, se devolverá a istio-csr, que leerá la solicitud firmada y la devolverá a la carga de trabajo que inició la CSR.

Flujo de solicitudes de firma de certificados de Istio con istio-csr

image: :istio-csr-with-acm-private-ca.png [Flujo de solicitudes de firma de certificados de Istio con istio-csr]

Instrucciones de configuración de Istio con CA privada

Solicitudes de firma de certificados de Istio

image: :istio-csr-requests.png [Solicitudes de firma de certificados de Istio]

Herramientas y recursos