Proporcionando acceso a Internet controlado a través de servidores proxy centralizados utilizando AWS Fargate y PrivateLink

Permitir el acceso a URLs de Internet desde su Amazon VPC es un requisito común. Es posible que necesite acceder a repositorios de software, comunicarse con APIs de socios o descargar paquetes de proveedores de confianza. Esto es relativamente sencillo cuando sus recursos se encuentran en subredes públicas, pero las subredes privadas requieren el uso de una puerta de enlace de traducción de direcciones de red (NAT gateway) o un servidor proxy para proporcionar acceso saliente a Internet.

Proporcionar acceso a Internet a recursos en sus subredes privadas se puede lograr a través de varios enfoques. Un enfoque común es una puerta de enlace de Internet con una subred pública y una puerta de enlace NAT para cada Amazon VPC. En entornos altamente regulados, este enfoque puede causar desafíos porque a medida que crece la presencia de AWS, también crece el número de puntos de entrada/salida a Internet.

Los clientes que elijan adoptar un modelo de Internet centralizado para superar este problema pueden utilizar AWS Network Firewall, que se puede implementar usando un modelo centralizado o descentralizado para controlar el tráfico de Internet a través de una VPC de inspección. Aunque AWS Network Firewall proporciona un servicio completamente gestionado para controlar el acceso a dominios aprobados, actúa como un proxy ‘transparente’ para enrutar el tráfico a Internet. Esto significa que las instancias que acceden a Internet no son conscientes de que están detrás de un proxy.

Un proxy explícito requiere ‘conciencia’ de un servidor proxy y las instancias deben configurarse para usar un servidor proxy para conectarse a Internet. También se puede añadir autenticación de proxy para proporcionar un control más granular y restringir el acceso a instancias o recursos específicos en una VPC. La solución en este blog utiliza una flota de proxies Squid que funcionan en modo explícito, requiriendo que las instancias se configuren para usar su proxy para conectarse a Internet.

La Arquitectura de la Solución

Esta solución se basa en una flota de proxies Squid de código abierto que se ejecutan en  Amazon Elastic Container Service (ECS) con AWS Fargate. El acceso a Internet se proporciona centralmente a través de una puerta de enlace NAT (NAT gateway) y una puerta de enlace de Internet (Internet gateway) desplegadas en la VPC central. Amazon ECS utiliza un Network Load Balancer (NLB) configurado como un servicio de endpoint para hacer que la solución esté disponible para las VPCs ‘spoke’ (radiales). Los endpoints de interfaz se implementan en las VPCs ‘spoke’ (de aplicación) para permitir que los recursos dentro de estas VPCs utilicen el endpoint desplegado como su servidor proxy. Algunos puntos clave a tener en cuenta sobre esta solución son:

• La conectividad de red L3 NO es necesaria entre el hub central y las VPCs de la cuenta ‘spoke’ (radial), ya que utiliza AWS PrivateLink.
• La lista de permitidos (allowlist) se gestiona centralmente y puede ser controlada por versiones en su repositorio basado en git.
• La solución solo utiliza servicios gestionados por AWS, por lo que no hay instancias de Amazon Elastic Compute Cloud (EC2) o nodos de clúster para gestionar.
• La solución puede escalar a miles de VPCs y ‘puntos finales de proxy’ (proxy endpoints).
• El servicio ECS escala automáticamente el número requerido de tareas según la carga de CPU del servicio proxy.
• El proxy Squid está configurado para actuar como un proxy explícito, por

lo que las instancias deben estar configuradas para ser ‘conscientes del proxy’ para acceder a Internet.

Figura 1: Descripción General de la Solución

El servicio de endpoint puede configurarse para permitir que cuentas individuales de AWS utilicen el servicio de proxy central. También se puede configurar un nombre de DNS privado opcional para el servicio del endpoint, permitiendo que las cuentas ‘spoke’ (radiales) utilicen un nombre de host común como su proxy. Esto permite que los hosts o aplicaciones en diferentes cuentas y VPCs ‘spoke’ se configuren para utilizar un nombre de host de proxy común, que se resuelve en el endpoint local único dentro de cada VPC.

ECS en Fargate ejecutando el Servicio de Proxy Squid

El servicio de proxy Squid utiliza AWS Fargate con Amazon ECS para ejecutar una flota escalable de servidores proxy detrás de un Balanceador de Carga de Red. La imagen del contenedor que ejecuta el proxy Squid contiene el archivo de configuración squid.conf y el archivo asociado allowlist.txt, que mantiene la lista de los dominios permitidos por el servicio de proxy. Ambos archivos pueden ser actualizados en el repositorio basado en git para activar los canales de despliegue (deployment pipelines) descrita a continuación.

El balanceador de carga de red utilizado por ECS está configurado como un servicio de endpoint soportado por AWS PrivateLink. Con AWS PrivateLink, los consumidores del servicio crean endpoints de VPC de interfaz para conectarse a los servicios de endpoint que son alojados por los proveedores de servicios. La cuenta principal para nuestra solución es el ‘Proveedor de Servicio’ y la cuenta de AWS donde se despliega el endpoint del proxy es el ‘Consumidor de Servicio’.

El canal de despliegue

En el despliegue inicial de la solución, AWS CodePipeline utiliza  AWS CodeBuild para construir el contenedor de proxy Squid utilizando el Dockerfile y los archivos de configuración del repositorio AWS CodeCommit . La imagen del contenedor se envía luego al repositorio Amazon Elastic Container Registry (ECR) , y AWS CodeDeploy se utiliza para desplegar la imagen del contenedor en ECS. Cualquier actualización posterior a los archivos squid.conf o allowlist.txt en CodeCommit activará el despliegue de los canales (pipelines) para reconstruir una nueva imagen del contenedor y desplegarla en ECS usando una actualización continua para reemplazar los contenedores en ejecución uno a uno. El despliegue de los canales se completará una vez que todos los contenedores en ejecución hayan sido reemplazados con una nueva imagen.

El Consumidor del Servicio (Cuentas Spoke)

AWS PrivateLink permite la conectividad privada entre VPCs. El consumidor del servicio (las cuentas de aplicación ‘spoke’) para esta solución tendrá un ‘endpoint de proxy’ desplegado dentro de la VPC que permite el acceso a Internet a la lista de dominios permitidos en la cuenta central.

El endpoint del proxy puede ser desplegado en miles de VPCs (dentro de la misma región) en cualquier cuenta de AWS que haya sido autorizada a utilizar el servicio de endpoint en la lista de principales. Los Principales permitidos pueden ser un usuario o rol específico, pero para nuestra solución utilizaremos el Nombre de Recurso de Amazon (ARN) para permitir que cualquier Principal en nuestra cuenta de consumidor cree un endpoint de interfaz. Para más información, revise el documento  Configure an endpoint service.

Desplegando la Solución

La solución se puede desplegar en 4 pasos para que esté en funcionamiento:

• Paso 1: Cree un repositorio CodeCommit y prepara el Dockerfile y los archivos de configuración asociados.
• Paso 2:Cree un rol vinculado al servicio de Amazon ECS.
• Paso 3: Despliegue la solución a través de la plantilla de CloudFormation proporcionada. Esta solución despliega todo lo necesario para la cuenta central en la descripción general de la solución.
• Paso 4: Cree su endpoint de VPC en su cuenta spoke junto con una instancia EC2 para pruebas.

Paso 1: Cree su repositorio CodeCommit

Cree su repositorio CodeCommit y prepare los archivos de configuración necesarios para construir la solución. Los archivos de configuración se pueden encontrar en el siguiente Github Repository.

1. Navegue hasta la consola de AWS CodeCommit Console, luego elija Crear repositorio.
2. Ingrese un nombre, una descripción opcional y luego elige Crear. Será llevado a su repositorio después de la creación.

Figura 2: Configuración del Repositorio AWS CodeCommit

3. Agregue los 4 archivos de configuración desde el Repositorio de Github directamente desde la consola o clonando el repositorio en su computadora local, creando commits y subiendo el contenido al nuevo repositorio.

Figura 3: Repositorio AWS CodeCommit

 

Paso 2: Crear el Rol Vinculado al Servicio de ECS

Si su cuenta de AWS no tiene el rol vinculado al servicio de ECS: AWSServiceRoleForECS, necesitará crear el rol utilizando el siguiente comando CLI:

aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

Para información adicional, consulte la guía de Uso de roles vinculados al servicio para Amazon ECS.

Paso 3: Implemente la solución Proxy usando Cloudformation

Utilice AWS CloudFormation para aprovisionar los recursos requeridos para la cuenta central. Seleccione el botón desplegar la plantilla (Launch stack) a continuación para abrir la consola de CloudFormation y crear una pila (create stack) a partir de la plantilla. Luego, siga las instrucciones en pantalla.

CloudFormation creará los siguientes recursos en su cuenta de AWS:

1. Una Virtual Private Cloud (VPC) con un Internet Gateway
2. Subredes públicas y privadas en la VPC
3. Dos tablas de rutas, una para las subredes privadas y otra para las subredes públicas
4. Un servicio ECS utilizando AWS Fargate
5. Una línea de despliegue compuesta por:

• CodeBuild para construir el contenedor Docker
• CodeDeploy para desplegar la imagen del contenedor en ECS
• CodePipeline para orquestar la construcción y el despliegue de extremo a extremo

6. Un Repositorio ECR para la imagen del contenedor
7. Los roles y políticas IAM requeridos
8. Eventos CloudWatch y Grupos de Registro

Los siguientes parámetros son necesarios para desplegar la pila de CloudFormation:

1. Nombre del repositorio y rama de CodeCommit del Paso 1
2. El número de Zonas de Disponibilidad para desplegar la solución
3. Principios Permitidos para el Servicio de Endpoint (esto será el ARN de la cuenta de AWS para tu cuenta de consumidor de servicio (es decir, donde desplegarás el endpoint del proxy), por ejemplo:

arn:aws:iam::<aws-account-id>:root

Usar DNS privador (paso opcional)

Cuando crea un VPC endpoint, AWS genera un nombre de host DNS específico del endpoint que puede utilizar para comunicarte con el servicio endpoint. Por ejemplo:

vpce-xxxxxxxxxxxxxxxx.vpce-svc-yyyyyyyyyyyyyyy.eu-west-2.vpce.amazonaws.com.

Por defecto, este es el nombre de host que sus aplicaciones pueden utilizar para canalizar el tráfico de internet a través del proxy. Como este nombre de host es único para cada endpoint de VPC desplegado, usar el nombre de host generado por AWS puede no ser preferible, ya que el servidor proxy al que dirige las aplicaciones será diferente para cada VPC.

Una opción alternativa es habilitar DNS privado para su servicio de endpoint y utilizar este nombre de DNS privado como el nombre de host del servidor proxy en cada cuenta de «spoke». Habilitar DNS privado crea un registro administrado de AWS Route53 para su VPC que resuelve el nombre de DNS privado a las direcciones IP del punto final dentro de su VPC.

Para utilizar la función de DNS privado, debe tener un nombre de dominio registrado para verificar la propiedad del dominio antes de que pueda permitir que sus cuentas de «spoke» utilicen este nombre de host. Una vez que se completa la verificación de la propiedad del dominio, los consumidores pueden acceder al punto final utilizando el nombre de DNS privado.

Dado que el DNS privado se puede habilitar opcionalmente para servicios de endpoint nuevos o existentes, las siguientes instrucciones proporcionan una guía para agregar DNS privado al servicio de endpoint después de que haya sido desplegado a través de la plantilla de CloudFormation en la sección anterior:

1. Seleccione tu Servicio de Endpoint en la consola VPC
2. Seleccione Acciones → Modificar nombre de DNS privado
3. Habilite «Asociar un nombre de DNS privado con el servicio»
4. Introduzca su nombre de DNS privado, por ejemplo: aws.ssproxy.co.uk

Figura 4: Detalles del punto final VPC – verificación pendiente

 

El estado de verificación del dominio se mostrará como «verificación pendiente» y se requerirá utilizar el nombre y valor de verificación de dominio que se muestra en la captura de pantalla anterior para crear un registro TXT con tu proveedor de DNS para verificar la propiedad del registro. Para aprender más, consulte la documentación de AWS PrivateLink.

Después de crear el registro TXT de verificación, deberá esperar hasta 10 minutos antes de realizar las siguientes acciones:

1. Seleccione su Servicio de Endpoint en la consola VPC
2. Seleccione Acciones → Verificar la propiedad del dominio para el nombre de DNS privado
3. Confirme la verificación

Figura 5: Verificación de la propiedad del dominio del endpoint VPC

 

Una vez que se haya completado la verificación, el estado de verificación de su dominio debería cambiar a «Verificado».

Figura 6: Detalles del endpoint VPC – dominio verificado

 

Paso 4: Implementar el endpoint del proxy en su cuenta de aplicación (spoke)

El endpoint del proxy se implementa en cada VPC privada donde quiera utilizar el servicio de proxy. Necesitará una VPC existente con una instancia EC2 para las pruebas. Para implementar el endpoint, siga estos pasos:

1. Inicie sesión en la cuenta AWS del consumidor donde implementará su endpoint del proxy. El ARN de la cuenta debería haber sido permitido cuando desplegó la plantilla de CloudFormation. Si no fue así, puede volver a desplegar la plantilla, agregando el ARN de la cuenta en el parámetro AllowedPrincipalsList.
2. En la consola de VPC, vaya a los endpoints y haga clic en «Crear endpoint».
3. Seleccione «Otros servicios de endpoint» e ingrese el Nombre del servicio para el servicio de endpoint proporcionado en las salidas de CloudFormation, por ejemplo, com.amazonaws.vpce.eu-west-2.vpce-svc-xxxxxxxxxxxxxxxx y haz clic en verificar.

Figura 7: Creación del endpoint VPC – Verificación del Nombre del Servicio

 

4. Seleccione su VPC y subredes donde se implementará el endpoint. Consulte la sección de Consideraciones Adicionales para obtener más información sobre los requisitos de alineación de AZ entre las cuentas del proveedor y del consumidor.

Figura 8: Creación del endpoint VPC – Selección de subred

 

5. Sí habilitó DNS privado para tu servicio de endpoint en la cuenta del proveedor, puede habilitar el nombre DNS en la sección de Configuración adicional.

Figura 9: Creación del endpoint VPC – Habilitar nombre DNS

6. 6. Añada un grupo de seguridad al endpoint que permita que tu CIDR VPC o la instancia EC2 de prueba se comuniquen con el endpoint a través del protocolo TCP en el puerto 3128.
   7. Haga clic en Crear Endpoint.

    

   Prueba del Proxy

   Despliegue una instancia EC2 de prueba (Linux) en la VPC donde se desplegó su endpoint proxy en el Paso 4. Necesita usar Session Manager para conectarse a la instancia, ya que la VPC del consumidor es privada y por lo tanto no tiene una ruta de entrada para SSH. Siga la guía del usuario aquí para usar Session Manager.

   Desde la terminal EC2, configure la instancia para usar tu proxy utilizando los siguientes comandos de exportación de variables:

$ export http_proxy=http://<Proxy-DOMAIN>:<Proxy-Port>

$ export https_proxy=http://<Proxy-DOMAIN>:<Proxy-Port>

por ejemplo, sin DNS privado:

$ export http_proxy=http://vpce-0e92264eb3c2d222d-166ar2fp.vpce-svc-0407aa3b85114a062.eu-west-2.vpce.amazonaws.com:3128

$ export https_proxy=http://vpce-0e92264eb3c2d222d-166ar2fp.vpce-svc-0407aa3b85114a062.eu-west-2.vpce.amazonaws.com:3128

por ejemplo, con DNS privado:

$ export http_proxy=http://aws.ssproxy.uk:3128

$ export https_proxy=http://aws.ssproxy.uk:3128

Puede utilizar curl para probar que puedes conectarte a las URL’s permitidas por tu lista de permitidos, pero no a otras URL’s. Por ejemplo:

curl https://thinkwithwp.com  loads page.

curl https://www.microsoft.com returns 403 error or <!-- ERR_ACCESS_DENIED

Limpieza

No olvide limpiar los recursos para evitar cargos no deseados. Para eliminar los recursos desplegados en este blog, puede seguir estos pasos:

1. Navegue a la sección de endpoints de VPC en la cuenta de «spoke» y «elimina» el endpoint del proxy.
2. Elimine la stack de CloudFormation en la cuenta central.
3. Elimine los archivos y el repositorio de CodeCommit en la cuenta central.

Conclusión

En esta publicación, hemos mostrado una de las opciones disponibles en AWS para construir una solución de salida a Internet centralizada en un entorno de múltiples cuentas. La solución se basa en una infraestructura totalmente «sin servidor» (serverless) y gestionada utilizando AWS Fargate y una canal de despliegue para gestionar su lista de permitidos de URL. La solución es escalable en miles de cuentas de AWS y ofrece un control granular y controles de seguridad adicionales, como la autenticación basada en proxy.