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. La segunda implica el cifrado del tráfico mientras está en tránsito. Los mecanismos para implementar estas medidas de seguridad en el EKS son variados, pero a menudo incluyen los siguientes elementos:

Control de tráfico

Network encryption

Política de red

Dentro de 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 fomentar la experimentación, no se considera segura. Las políticas de red de Kubernetes te proporcionan un mecanismo para restringir el tráfico de red entre los Pods (a menudo denominado tráfico Este/Oeste), 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 etiquetas y selectores de espacios de nombres 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 ambos. Las políticas de red se pueden aplicar a las conexiones entrantes o salientes del pod, lo que suele denominarse reglas de entrada y salida.

Con el soporte nativo de 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 básica de políticas de red de Kubernetes, lo que garantiza la compatibilidad y el cumplimiento de los estándares de Kubernetes. Puede definir políticas mediante distintos identificadores compatibles con la API upstream. De forma predeterminada, todo el tráfico de entrada y salida está permitido en un pod. Cuando se especifica una política de red con un tipo de política de entrada, solo se permiten las conexiones al pod desde el nodo del pod y las permitidas por las reglas de entrada. Lo mismo se aplica a las reglas de salida. Si se definen varias reglas, se tiene 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

Cómo empezar con las políticas de red: siga el principio del mínimo privilegio

Cree una política de denegación predeterminada

Al igual que con las políticas RBAC, se recomienda seguir los principios de acceso con menos privilegios en 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 de denegación de todo predeterminada, puedes empezar a añadir 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

allow-dns-access

Agrega reglas de forma incremental para permitir de forma selectiva el flujo de tráfico entre espacios de nombres o 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 del puerto 80 al puerto de origen. 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

Supervisión del cumplimiento de las 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
}

Solución de problemas

Supervise los registros del agente de nodo vpc-network-policy-controller

Habilite los registros del administrador del controlador del plano de control EKS para diagnosticar la funcionalidad de la política de red. Puede transmitir los registros del plano de control a un grupo de CloudWatch registros y utilizar CloudWatchLog Insights para realizar consultas avanzadas. En los registros, puede ver qué objetos de punto final del pod se han resuelto según una política de red, el estado de conciliación de las políticas y depurar si la política funciona según lo previsto.

Además, Amazon VPC CNI le permite habilitar la recopilación y exportación de registros de aplicación de políticas a Amazon Cloudwatch desde los nodos de trabajo de EKS. Una vez activado, puede utilizar CloudWatchContainer 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 eBPF del nodo. El SDK se instala cuando aws-node se implementa en los nodos. 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 programas y mapas de eBPF.

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

Registra los metadatos del tráfico de red

Los registros de flujo de VPC de AWS recopilan 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 los paquetes aceptados o descartados. 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 desciframiento de los flujos de tráfico entre los pods.

Grupos de seguridad

EKS utiliza los grupos de seguridad de VPC de AWS (SGs) 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 VPC y las direcciones IP externas. Al aprovisionar 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. 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 añadir el clúster SG a todos los grupos de nodos, incluidos los grupos de nodos no gestionados.

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 los grupos de nodos se encuentran en -group-reqs.html. https://docs.aws.amazon.com/eks/ latest/userguide/sec Las reglas mínimas para el grupo de seguridad del plano de control permiten que el puerto 443 entre 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; 10250 es el puerto en el que escuchan los kubelets. Del mismo modo, las reglas mínimas del grupo de nodos permiten que el puerto 10250 entre desde el plano de control SG y el 443 que salga desde el plano de control SG. Por último, hay una regla que permite la comunicación sin restricciones entre los nodos de un grupo de nodos.

Si necesita 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, considere la posibilidad de utilizar grupos de seguridad para los pods. Con los grupos de seguridad para los pods, puede asignar un grupo de seguridad existente a un conjunto de pods.

Puedes controlar qué pods se asignan a un grupo de seguridad creando un SecurityGroupPolicy objeto y especificando un PodSelector o unServiceAccountSelector. Si se configuran los selectores en, {} se asignará lo SGs referenciado 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 forma nativa de AWS de controlar el tráfico de red dentro y fuera del clúster sin la sobrecarga de un daemon de políticas, hay otras opciones disponibles. Por ejemplo, el motor de políticas de Cilium le permite hacer referencia a un nombre de DNS en una política de red. Calico Enterprise incluye una opción para asignar políticas de red a los grupos de seguridad de AWS. Si ha implementado una red de servicios como Istio, puede utilizar una pasarela de salida para restringir la salida de la red a dominios o direcciones IP específicos y totalmente cualificados. Para obtener más información sobre esta opción, lea 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 los pods?

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

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

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

Cuando se trata de la seguridad de la red, un enfoque por capas suele ser la solución más eficaz. El uso combinado de la política de red de Kubernetes y el SGP puede proporcionar una defense-in-depth estrategia sólida 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 añadir a sus aplicaciones. Le permite añadir de forma transparente funciones como la observabilidad, la gestión del tráfico y la seguridad, sin necesidad de añadirlas a su propio código.

Service Mesh 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 espacio, como AWSAppMesh, Istio, Linkerd, etc.

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

Elija 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 servidor 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ítica de red de Kubernetes, Calico admite políticas de red ampliadas con un conjunto más amplio 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 RBAC adecuadas, puede evitar que los equipos las invaliden, lo que permite a los profesionales de la seguridad de TI delegar de forma segura la administración de los espacios de nombres. Isovalent, empresa encargada del mantenimiento de Cilium, también ha ampliado las políticas de red para incluir una 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 la VPC. Por el contrario, Calico Enterprise incluye una función que le 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.

Puede encontrar una lista de las políticas de red habituales de Kubernetes en. https://github.com/ahmetb/kubernetes-network-policy-recipes Encontrarás un conjunto similar de reglas para Calico en https://docs.projectcalico. org/security/calico-política de red.

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 del motor de políticas de red CNI de 3P a VPC, te recomendamos convertir tu NetworkPolicy CRDs 3P existente a los recursos de NetworkPolicy Kubernetes antes de habilitar el soporte de políticas de red CNI de VPC. Además, pruebe las políticas migradas en un clúster de prueba independiente antes de aplicarlas en su entorno de producción. Esto le permite identificar y abordar cualquier posible problema o incoherencia en el comportamiento de comunicación de los módulos.

Herramienta de migración

Para ayudarte en el proceso de migración, hemos desarrollado una herramienta llamada K8s Network Policy Migrator que convierte tu política de red existente en políticas CRDs de Calico/Cilium red nativas de Kubernetes. Tras la conversión, puede probar directamente las políticas de red convertidas en los nuevos clústeres que ejecutan el controlador de políticas de red CNI de VPC. La herramienta está diseñada para ayudarte a agilizar el proceso de migración y garantizar una transición fluida.

Tenga en cuenta que, actualmente, el equipo de ingeniería de políticas de red CNI de AWS VPC no admite la herramienta de migración, sino que se pone a disposición de los clientes haciendo todo 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 GitHubproblema. Sus comentarios son muy valiosos para nosotros y nos ayudarán a mejorar continuamente nuestros servicios.

Recursos adicionales

Cifrado en tránsito

Es posible que las aplicaciones que deban cumplir con la PCI, la HIPAA u otras normativas necesiten cifrar los datos mientras están en tránsito. Hoy en día, el TLS es la opción de facto para cifrar el tráfico en línea. El TLS, al igual que su predecesor, el 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 formas de cifrar 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 carga, el tráfico no se cifra. Consulta Cifrado en tránsito para obtener más información sobre el cifrado en tránsito, así como la lista completa de tipos de instancias que admiten el cifrado de red de forma predeterminada.

Interfaces de red de contenedores (CNIs)

WeaveNetse puede configurar para cifrar automáticamente todo el tráfico mediante el NaCl cifrado para el tráfico intermedio y el IPsec ESP para el tráfico de rutas de datos rápidas.

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 certificados X.509 o el Servicio de Descubrimiento Secreto (SDS) de Envoy. Tanto Linkerd como Istio admiten mTLS.

El aws-app-mesh-examplesGitHub repositorio proporciona instrucciones para configurar los mTLs mediante certificados X.509 y SPIRE como proveedor de SDS con su contenedor Envoy:

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 aws-app-mesh-examplesGitHub repositorio proporciona instrucciones para configurar el TLS mediante certificados emitidos por ACM y certificados incluidos en el contenedor de Envoy:

Controladores de entrada y balanceadores de carga

Los controladores de ingreso son una forma de enrutar de forma inteligente el HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, e.g. at the load balancer, at the ingress resource, or the Pod. How and where you terminate your SSL connection will ultimately be dictated by your organization’s network security policy. For instance, if you have a policy that requires end-to-end encryption, you will have to decrypt the traffic at the Pod. This will place additional burden on your Pod as it will have to spend cycles establishing the initial handshake. Overall SSL/TLS procesamiento que consume mucha CPU. Por lo tanto, si tiene la flexibilidad necesaria, intente realizar la descarga de SSL en la entrada o en el balanceador de carga.

Utilice el cifrado con los balanceadores de carga elásticos de AWS

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

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

Los siguientes son ejemplos adicionales de terminación. SSL/TLS

ACM Private CA con administrador de certificados

Puede habilitar TLS y mTLS para proteger las cargas de trabajo de las aplicaciones de EKS en 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 entidad de certificación gestionada, segura y de alta disponibilidad, sin los costes iniciales y de mantenimiento que supone gestionar una entidad de certificación propia. Si utiliza la autoridad de certificación predeterminada de Kubernetes, existe la oportunidad de mejorar su seguridad y cumplir los requisitos de conformidad con ACM Private CA. ACM Private CA protege las claves privadas en 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 segura). Una CA centralizada también le brinda más control y mejora la auditabilidad de los certificados privados, tanto dentro como fuera de un entorno de Kubernetes.

Modo CA de corta duración para un TLS mutuo entre cargas de trabajo

Cuando utilice ACM Private CA para mTLS en EKS, se recomienda utilizar certificados de corta duración con el modo CA de corta duración. Si bien es posible emitir certificados de corta duración en el modo de 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 de uso en los que es necesario emitir nuevos certificados con frecuencia. Además, debería intentar ajustar el período de validez de los certificados privados a la vida útil de los módulos de su 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 los documentos técnicos de ACM Private CA. Una vez que tenga una CA privada, instale cert-manager siguiendo las instrucciones de instalación habituales. Tras instalar el administrador de certificados, instale el complemento Private CA Kubernetes cert-manager siguiendo las instrucciones de configuración que se indican 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 EKS para permitir el acceso a ACM Private CA. <CA_ARN>Sustitúyalo 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": "<CA_ARN>"
        }
    ]
}

También se pueden utilizar 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.

Para crear un emisor en Amazon EKS, cree un archivo de definición de recursos personalizado denominado cluster-issuer.yaml con el siguiente texto y <CA_ARN> sustituya 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 a Private CA. Ahora puede usar el Certificate recurso de cert-manager para emitir certificados cambiando los valores del issuerRef campo por el emisor de CA privado que creó anteriormente. Para obtener más información sobre cómo especificar y solicitar los recursos de certificados, consulte la guía de recursos de certificados de cert-manager. Consulte algunos 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 autoridad de certificación (CA) raíz y configurar ACM Private CA como 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 del 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 asignará una 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 gestión de identidades y CA. Cuando una carga de trabajo se inicia con su proxy sidecar, necesita que Istio le asigne una identidad para que se la considere fiable y pueda 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 que se pueda verificar la identidad de la carga de trabajo antes de procesarla. De este proceso de verificación se encarga la autoridad de registro (o RA) y la CAistiod, que actúa como autoridad de registro (o RA). La RA actúa como un guardián que se asegura de que solo los CSR verificados lleguen a la CA. Una vez verificada la CSR, se reenviará a la CA, que emitirá un certificado con la identidad de la SPIFFE con la cuenta de servicio. Este certificado se denomina documento de identidad verificable del 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 utilizar un complemento de gestión de certificados denominado agente de solicitud de firma de certificados de Istio (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 sirve istiod en la configuración predeterminada de validación de los datos entrantes. CSRs Excepto 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 derivada 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 de emisión de AWS Private CA. 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 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

imagen: 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

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

Herramientas y recursos