Activación de mTLS en AWS App Mesh con AWS Private CA en Amazon EKS - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaHerramientasEpicsRecursos relacionadosInformación adicional

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.

Activación de mTLS en AWS App Mesh con AWS Private CA en Amazon EKS

Omar Kahil, Emmanuel Saliu, Muhammad Shahzad y Andy Wong, Amazon Web Services

Resumen

Este patrón muestra cómo implementar Mutual Transport Layer Security (mTLS) en Amazon Web Services (AWS) mediante certificados de AWS Private Certificate Authority (AWS Private CA) en AWS App Mesh. Utiliza la API del servicio de descubrimiento secreto (SDS) de Envoy a través del marco de identidad de producción seguro para todos (SPIFFE). SPIFFE es un proyecto de código abierto de Cloud Native Computing Foundation (CNCF) que cuenta con un amplio apoyo de la comunidad y que proporciona una gestión de identidades de la carga de trabajo detallada y dinámica. Para implementar los estándares de SPIFFE, utilice el entorno de tiempo de ejecución de SPIRE SPIFFE.

El uso de mTLS en App Mesh ofrece una autenticación entre pares bidireccional, ya que añade una capa de seguridad sobre TLS y permite que los servicios de la malla verifiquen el cliente que realiza la conexión. El cliente en la relación cliente-servidor también proporciona un certificado X.509 durante el proceso de negociación de la sesión. El servidor utiliza este certificado para identificar y autenticar al cliente. Esto ayuda a verificar si el certificado lo ha emitido una entidad de certificación (CA) de confianza y si el certificado es válido.

Requisitos previos y limitaciones

Requisitos previos 

  • Un clúster de Amazon Elastic Kubernetes Service (Amazon EKS) con grupos de nodos autogestionados o gestionados

  • Controlador App Mesh implementado en el clúster con el SDS activado

  • Un certificado privado de AWS Certificate Manager (ACM) emitido por AWS Private CA

Limitaciones

  • SPIRE no se puede instalar en AWS Fargate porque el agente de SPIRE debe ejecutarse como Kubernetes. DaemonSet

Versiones de producto

  • Gráfico del controlador AWS App Mesh 1.3.0 o posterior

Arquitectura

El siguiente diagrama muestra el clúster de EKS con App Mesh en la VPC. El servidor SPIRE de un nodo de trabajo se comunica con los agentes de SPIRE de otros nodos de trabajo y con AWS Private CA. Envoy se utiliza para la comunicación mTLS entre los nodos de trabajo del agente SPIRE.

EKS agrupa los nodos de trabajo con SPIRE Agents and Server, App Mesh y Envoys for mTLS.

El siguiente diagrama muestra los siguientes pasos:

  1. Se emite el certificado.

  2. Solicite la firma y el certificado.

Herramientas

Servicios de AWS

  • CA privada de AWS: la autoridad de certificación privada de AWS (CA privada de AWS) permite la creación de jerarquías de autoridades de certificación (CA) privadas, incluidas las principales y las subordinadas CAs, sin los costos de inversión y mantenimiento que implica operar una CA local.

  • AWS App Mesh: AWS App Mesh es una malla de servicios que facilita el monitoreo y el control de los servicios. App Mesh estandariza la forma en que se comunican sus servicios, ofreciendo visibilidad y controles de tráfico de red coherentes para cada microservicio en una aplicación.

  • Amazon EKS: Amazon Elastic Kubernetes Service (Amazon EKS) es un servicio administrado que puede utilizar para ejecutar Kubernetes en AWS sin necesidad de instalar, operar ni mantener su propio plano de control o nodos de Kubernetes.

Otras herramientas

  • Helm: Helm es un administrador de paquetes para Kubernetes que le ayuda a instalar y administrar aplicaciones en su clúster de Kubernetes. Este patrón usa Helm para implementar el controlador AWS App Mesh.

  • Gráfico del controlador AWS App Mesh – Este patrón utiliza el gráfico del controlador AWS App Mesh para habilitar AWS App Mesh en Amazon EKS.

Epics

TareaDescripciónHabilidades requeridas

Configure App Mesh con Amazon EKS.

Siga los pasos básicos de implementación que se proporcionan en el repositorio.

DevOps ingeniero

Instale SPIRE.

Instale SPIRE en el clúster EKS mediante spire_setup.yaml.

DevOps ingeniero

Instale el certificado de AWS Private CA.

Cree e instale un certificado para su raíz privada CA siguiendo las instrucciones de la documentación de AWS.

DevOps ingeniero

Conceda permisos al rol de instancia del nodo del clúster.

Para adjuntar políticas al rol de instancia del nodo del clúster, use el código que se encuentra en la sección de Información adicional.

DevOps ingeniero

Añada el complemento SPIRE para AWS Private CA.

Para añadir el complemento a la configuración del servidor SPIRE, utilice el código que se encuentra en la sección de Información adicional. Sustituya el nombre de recursos de Amazon (ARN) certificate_authority_arn por su ARN de CA privado. El algoritmo de firma utilizado debe ser el mismo que el algoritmo de firma de la CA privada. Reemplace your_region por su región de AWS.

Para obtener más información sobre el complemento, consulte el complemento del servidor: UpstreamAuthority «aws_pca».

DevOps ingeniero

Actualice bundle.cert.

Tras crear el servidor SPIRE, se creará un archivo spire-bundle.yaml. Cambie el valor bundle.crt del archivo spire-bundle.yaml de la CA privada al certificado público.

DevOps ingeniero
TareaDescripciónHabilidades requeridas

Registre las entradas de nodos y cargas de trabajo con SPIRE.

Para registrar el nodo y la carga de trabajo (servicios) en el servidor SPIRE, utilice el código del repositorio.

DevOps ingeniero

Cree una malla en App Mesh con los mTLS activados.

Cree una nueva malla en App Mesh con todos los componentes de su aplicación de microservicios (por ejemplo, servicio virtual, router virtual y nodos virtuales).

DevOps ingeniero

Inspeccione las entradas registradas.

Puede inspeccionar las entradas registradas de sus nodos y cargas de trabajo ejecutando el siguiente comando.

kubectl exec -n spire spire-server-0 -- /opt/spire/bin/spire-server entry show

Esto mostrará las entradas de los agentes de SPIRE.

DevOps ingeniero
TareaDescripciónHabilidades requeridas

Verifique el tráfico de mTLS.

  1. Desde el servicio frontend, envíe un encabezado HTTP al servicio backend y verifique que la respuesta es correcta con los servicios registrados en SPIRE.

  2. Para la autenticación TLS mutua, puede inspeccionar la estadística ssl.handshake ejecutando el siguiente comando.

    kubectl exec -it $POD -n $NAMESPACE -c envoy -- curl http://localhost:9901/stats | grep ssl.handshake

    Tras ejecutar el comando anterior, debería ver el recuento ssl.handshake de oyentes, que tendrá un aspecto similar al del siguiente ejemplo:

    listener.0.0.0.0_15000.ssl.handshake: 2
DevOps ingeniero

Verifique que los certificados se emitan desde AWS Private CA.

Puede comprobar que los complementos se hayan configurado correctamente y que los certificados se están emitiendo desde su CA privada principal consultando los registros de su servidor SPIRE. Ejecute el siguiente comando.

kubectl logs spire-server-0 -n spire

A continuación, consulte los registros que se generan. Este código asume que su servidor se llama spire-server-0 y está alojado en su espacio de nombres SPIRE. Debería comprobar que los complementos se hayan cargado correctamente y que se haya establecido una conexión con su CA privada de origen.

DevOps ingeniero

Recursos relacionados

Información adicional

Adjuntar permisos al rol de instancia del nodo del clúster

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ACMPCASigning",
            "Effect": "Allow",
            "Action": [
                "acm-pca:DescribeCertificateAuthority",
                "acm-pca:IssueCertificate",
                "acm-pca:GetCertificate",
                "acm:ExportCertificate"
            ],
            "Resource": "*"
        }
    ]
}
AWS Managed Policy: "AWSAppMeshEnvoyAccess"

Cómo añadir el complemento SPIRE para ACM

Add the SPIRE plugin for ACM
Change certificate_authority_arn to your PCA ARN. The signing algorithm used must be the same as the signing algorithm on the PCA. Change your_region to the appropriate AWS Region.
UpstreamAuthority "aws_pca" {
    plugin_data {
        region = "your_region"
        certificate_authority_arn = "arn:aws:acm-pca:...."
        signing_algorithm = "your_signing_algorithm"
    }
}