Diseño e implementación de una arquitectura Zero Trust para Elastic Container Service

Infraestructura como Código (IaC) para la arquitectura Zero Trust

En el repositorio de GitHub del proyecto, encontrarás todo el código necesario para implementar la arquitectura Zero Trust descrita arriba. En este repositorio está la Infraestructura como Código (IaC) necesaria para desplegar la infraestructura en AWS, como el servidor web y los ficheros necesarios para crear la imagen de contenedor Docker usada en este ejemplo. La IaC está organizada en seis Stacks de AWS CloudFormation (Networking, Permissions, Security, Endpoints, Balancer y Containers), junto con un Stack maestro que automatiza el despliegue de los otros seis.

Decidir el Classless Inter-Domain Routing

Al crear una VPC nueva, hay que indicar el Classless Inter-Domain Routing (CIDR) que usará la red. CIDR es un estándar usado en redes para la asignación de direcciones IP, representado en forma de longitud de prefijo/máscara de subred. El prefijo es la dirección IP de la red, y la longitud de la máscara de subred indica cuántos bits de la dirección IP se usan para identificar hosts en la red.

El estándar Request for Comments (RFC) 1918 define un conjunto de direcciones IP reservadas para uso privado en redes locales. El objetivo principal es evitar conflictos de direcciones IP y permitir que las organizaciones implementen redes privadas sin necesidad de solicitar direcciones IP públicas únicas a los registradores de Internet. Los rangos definidos en este estándar son 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16.

En AWS, el tamaño de bloque permitido va de /16 a /28. Aunque es posible elegir un rango fuera del RFC 1918, no se considera una buena práctica. Es fundamental tener en cuenta que, una vez creada la VPC, no se puede modificar su CIDR. Para el diseño de red de este artículo, uso el rango 10.0.0.0/16, que ofrece un rango amplio para la segmentación de subredes dentro de la VPC.

Segmentación de red

Una subred es una subdivisión de una VPC a la que se le asigna un rango de red más pequeño dentro del rango de red de la VPC. Las subredes se ubican dentro de una zona de disponibilidad concreta de la región de la VPC y me permiten desplegar servicios de AWS dentro de ellas.

Para diseñar la segmentación de subredes de mi VPC, es una buena práctica aislar cada capa de mi infraestructura en una subred separada. Este enfoque permite aplicar medidas de seguridad de red específicas para cada capa, ofrece un control más preciso sobre el acceso a los servicios, y facilita la gestión del entorno.

Las subredes públicas son aquellas con acceso a Internet y accesibles desde Internet. En estas subredes despliego los elementos de red necesarios para establecer un punto de entrada para mi aplicación. Por otro lado, las subredes privadas no pueden establecer una conexión a Internet por sí mismas, y no son accesibles desde Internet sin un intermediario en una subred pública. Uso subredes privadas para desplegar los contenedores de la aplicación.

Como se ve en el diagrama, estas subredes residen dentro de una zona de disponibilidad. Esto significa que, si esta AZ tiene problemas, mi aplicación es susceptible de sufrir downtime. Todo falla todo el tiempo, hay que estar preparado para el fallo, y nada fallará. Por eso es necesario replicar mis subredes en otra AZ distinta, creando así la base para desplegar mi aplicación con alta disponibilidad.

Internet Gateway

Una vez segmentada y definida la red, añado los servicios necesarios para que la aplicación sea accesible desde Internet para los usuarios. Lo primero que hace falta es una Internet Gateway (IG), un componente de la VPC horizontalmente escalable, redundante y de alta disponibilidad que permite la comunicación entre la VPC e Internet. La IG permite que los recursos en subredes públicas se conecten a Internet si el recurso tiene una dirección IPv4 pública. Del mismo modo, los recursos de Internet pueden iniciar una conexión con recursos de la subred usando la dirección IPv4 pública.

Application Load Balancer

Como los contenedores están desplegados en subredes privadas y, por tanto, no son accesibles desde Internet, hace falta usar un elemento intermedio en mis subredes públicas que sí tenga acceso a Internet. Además, necesito repartir las peticiones que recibe mi aplicación entre los contenedores existentes, sobre todo si son redundantes, o enrutar las peticiones según el destino deseado.

El Application Load Balancer (ALB) es un servicio de balanceo de carga de nivel 7 que distribuye el tráfico de red entre aplicaciones específicas. El ALB opera en la capa de aplicación y puede enrutar peticiones según el contenido, como rutas de URL o cabeceras HTTP. Ofrece alta disponibilidad, escalabilidad, y permite una distribución eficiente del tráfico entre múltiples destinos, mejorando así el rendimiento y la fiabilidad de las aplicaciones en la nube.

Al crear un ALB, hace falta indicar dos o más subredes públicas a las que asociarlo. Estas subredes deben tener una máscara de red mínima /27 y disponer de 8 direcciones IP disponibles por subred. En estas subredes se desplegará una Elastic Network Interface (ENI), que permite al ALB enrutar tráfico hacia Internet y hacia mis recursos en subredes privadas.

Tráfico privado con VPC Endpoint

Tener un ALB permite dirigir el tráfico entrante hacia los contenedores de ECS. Sin embargo, los contenedores desplegados en subredes privadas no pueden establecer conexiones con el exterior, ni siquiera con servicios de AWS como S3 o ECR. Estos servicios requieren conexiones a endpoints fuera de la VPC. Aunque desplegar una NAT Gateway en las subredes públicas resuelve este problema, si solo necesitas conectividad a las APIs de servicios de AWS y no necesitas conexiones adicionales a Internet, una alternativa más eficiente es usar VPC Endpoints.

Los VPC Endpoints son una tecnología de alta disponibilidad y escalable que permite conectividad privada entre una VPC y los servicios de AWS, como si estuvieran en tu propia red. Esta opción es más económica, tanto en implementación como en coste por GB procesado, comparada con una NAT Gateway. Dentro de los VPC Endpoints se distinguen dos tipos: Interface Endpoint y Gateway Endpoint.

Interface Endpoint

Los Interface Endpoints funcionan añadiendo una Elastic Network Interface a las subredes especificadas dentro de tu VPC. Una vez desplegadas, estas subredes tendrán una dirección IP privada dentro del CIDR de la subred a la que se pueden lanzar peticiones HTTPS, conectándote al endpoint del servicio de AWS.

En el caso de esta arquitectura, necesito que los contenedores que corren en ambas subredes privadas puedan acceder a ECR para descargar imágenes Docker. ECR tiene dos endpoints igualmente necesarios para usar el servicio correctamente:

• com.amazonaws.{REGION}.ecr.api: este endpoint se usa para las llamadas a la API de Amazon ECR. Llamadas como BatchGetImage o GetDownloadUrlForLayer usan este endpoint.
• com.amazonaws.{REGION}.ecr.dkr: este endpoint se usa para operaciones del cliente Docker. Comandos como Docker Pull o Docker Push usan este endpoint.

Una buena práctica es desplegar Interface Endpoints en ambas subredes privadas en vez de solo en una. Esto consigue alta disponibilidad, ya que el Endpoint es accesible de forma independiente desde cada AZ. Además, evito tráfico entre AZs, lo que supone un ahorro en el coste de transferencia de datos.

Para gestionar el acceso a los endpoints, puedo asignarles una política basada en recursos. Esto me permite, por ejemplo, limitar qué roles pueden hacer llamadas a través de ellos o restringir acciones concretas dentro de la API. Para limitar el acceso a ECR solo al Task Execution Role, un rol de IAM que usan los agentes de ECS para hacer llamadas a la API de AWS en nombre del usuario, aplico la siguiente política:

{
  "Statement": [{
    "Sid": "AllowPull",
    "Principal": {
      "AWS": "arn:aws:iam::{ACCOUNT_ID}:role/TaskExecutionRole"
    },
    "Action": [
      "ecr:BatchGetImage",
      "ecr:GetDownloadUrlForLayer",
      "ecr:GetAuthorizationToken"
    ],
    "Effect": "Allow",
    "Resource": "*"
  }]
}

Además de estos, hace falta un tercer endpoint para establecer una conexión con Amazon CloudWatch: com.amazonaws.{REGION}.logs. Los contenedores usarán este servicio para almacenar los logs generados por las aplicaciones. Para restringir quién puede escribir logs en CloudWatch a través del endpoint y determinar en qué grupo de logs concreto, aplico al endpoint la siguiente política:

{
  "Statement": [{
    "Sid": "PutOnly",
    "Principal": {
      "AWS": "arn:aws:iam::{ACCOUNT_ID}:role/TaskExecutionRole"
    },
    "Action": [
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Effect": "Allow",
    "Resource": [
      "arn:aws:logs:{REGION}:{ACCOUNT_ID}:log-group:{GROUP_NAME}:*"
    ],
  }]
}

Gateway Endpoint

A diferencia de los Interface Endpoints, los Gateway Endpoints no añaden ninguna ENI a las subredes. En su lugar, añaden una regla a la tabla de rutas de las subredes especificadas. Como no hay ENI, la comunicación con el servicio de AWS no se hace apuntando a una IP privada dentro del CIDR de la subred, sino llamando a las IPs de los servicios de AWS. La regla añadida a la tabla de rutas de la subred es una prefix-list gestionada por AWS. Esta lista contiene todos los rangos CIDR en los que S3 da servicio en la región donde está desplegado.

Una sorpresa que me encontré al implementar la infraestructura es que ECR usa S3 por debajo para almacenar las capas de las imágenes Docker. Por eso, para que descargar una imagen de ECR desde ECS funcione, las subredes privadas necesitan acceso al bucket: prod-{REGION}-starport-layer-bucket. Este bucket es transparente para mí, y ni tengo acceso a él ni puedo verlo en la lista de buckets de mi cuenta.

Para conectar con S3, puedo hacerlo con un Interface Endpoint o con un Gateway Endpoint. Hay algunas diferencias sutiles, pero la más importante es que los Gateway Endpoints no tienen coste. Configuro el endpoint para conectar con com.amazonaws.{REGION}.s3 y aplico la siguiente Document Policy para restringir el acceso al bucket específico que usa ECR.

{
  "Statement": [
    {
    "Sid": "Access-to-specific-bucket-only",
    "Principal": "*",
    "Action": [
      "s3:GetObject"
    ],
    "Effect": "Allow",
    "Resource": ["arn:aws:s3:::prod-{REGION}-starport-layer-bucket/*"]
    }
  ]
}

La política actual impone restricciones al acceso al prod-{REGION}-starport-layer-bucket, permitiendo solo la acción GetObject. En un esfuerzo por limitar aún más el acceso, intenté especificar el Principal para permitir el acceso al endpoint exclusivamente a ECS. Probé opciones como indicar TaskExecutionRole o TaskRole como Principal, pero esta configuración impedía que los contenedores descargaran las imágenes Docker.

En mi intento de identificar las llamadas a S3, revisé los logs de AWS CloudTrail, pero las llamadas relevantes no quedaban registradas. La opción de habilitar S3 Access Logs no está disponible, ya que AWS no me da acceso a este bucket concreto. Al final concluí que AWS realiza estas llamadas de forma transparente para el usuario, lo que me impide aplicar restricciones adicionales a la política.

A pesar de la ausencia de un Principal específico, verifiqué que otros recursos de las subredes, salvo los contenedores de ECS, no pueden acceder al bucket. Esto se debe a que AWS implementa una Bucket Policy que restringe el acceso únicamente a las llamadas que se originan en operaciones de ECR.

Gestión del tráfico con Route Tables

Las route tables tienen un papel crucial en el control de cómo fluyen los datos dentro de una VPC. Es fundamental establecer reglas que dicten la ruta que deben seguir los paquetes de red, especificando destinos y su enrutamiento.

Para las dos subredes públicas, hace falta configurar dos rutas. La primera debe dirigir todo el tráfico con destino 0.0.0.0/0 hacia la Internet Gateway creada en la VPC. Esta configuración habilita el acceso a Internet para mis subredes públicas. La segunda regla asegura que todo el tráfico con destino 10.0.0.0/16 (el rango de la VPC) se enrute internamente dentro de la VPC.

En cuanto a las subredes privadas donde se despliegan los contenedores, además de la ruta para el tráfico local dentro de la VPC, se añade una regla para enviar tráfico a S3 a través del Endpoint durante la creación del Gateway Endpoint. El destino de esta regla es una AWS Managed Prefix List que contiene todos los rangos IP donde se puede acceder al servicio S3 de forma privada.

Security Groups

Un Security Group es un mecanismo de seguridad a nivel de ENI (Elastic Network Interface). Funciona como un firewall virtual que controla el tráfico de red permitido hacia y desde las ENIs asociadas a él. Estos grupos contienen reglas que especifican los tipos de tráfico permitidos según direcciones IP, puertos y protocolos. Es fundamental entender que son Stateful (con estado): si configuro una regla para permitir tráfico saliente, autorizo automáticamente el tráfico entrante asociado a esa conexión ya establecida. Del mismo modo, si permito tráfico entrante, permito implícitamente el tráfico saliente que mi instancia genera como respuesta.

En mi arquitectura he identificado tres Security Groups distintos. El primero se asociará con las ENIs de las subredes públicas que pertenecen al Application Load Balancer. Este Security Group se encarga de bloquear todo el tráfico excepto el tráfico entrante por el puerto 443 desde cualquier origen. Esta configuración permite que cualquier usuario acceda a mi servidor web. En cuanto al tráfico saliente, debe permitir el acceso al puerto 3000 en las subredes privadas donde están desplegados los contenedores.

El segundo security group está pensado para las tasks de ECS. Estas deben permitir tráfico entrante desde el security group del load balancer en el puerto donde el contenedor expone el servidor web, en este caso el puerto 3000. Además, debe permitir tráfico saliente por el puerto 443 hacia el rango de red de las subredes privadas. Esta configuración se implementa para que las tasks puedan hacer llamadas a través de las ENIs de los endpoints.

Por último, tengo el security group de los endpoints. Estos deben simplemente permitir tráfico por el puerto 443 desde las subredes privadas donde se han desplegado. Esto permite que las tasks hagan llamadas a través de ellos, estableciendo una comunicación efectiva en la arquitectura.

Network ACLs

Una Network ACL es un firewall que opera a nivel de subred. Usa reglas para especificar qué tipo de tráfico se permite o se bloquea según direcciones IP, rangos de puertos y protocolos específicos. A diferencia de los Security Groups, las Network ACLs son stateless (sin estado), lo que significa que no mantienen información sobre el estado de las conexiones. Cada regla de una Network ACL se aplica de forma independiente, sin tener en cuenta el estado de conexiones anteriores. Es fundamental entender que la configuración de reglas en una Network ACL afecta al tráfico entrante y saliente por separado, sin establecer automáticamente permisos mutuos como en el caso de los Security Groups.

Establecer una política de Network ACL para restringir tráfico no es redundante, aunque ya se haya hecho mediante Security Groups. Implementar medidas de seguridad en distintas capas de una arquitectura ofrece una protección más robusta frente a posibles ataques. Al aplicar Network ACLs a nivel de subred, el tráfico no deseado se bloquea antes de llegar a ENIs concretas, evitando así ataques a nivel de red como port scanning o DDoS antes de que lleguen a elementos individuales de la arquitectura. En situaciones donde las reglas de los Security Groups fallan o se modifican por accidente, las ACLs evitan accesos no autorizados y ofrecen una gestión centralizada del tráfico a nivel de subred, facilitando la aplicación consistente de las políticas de seguridad en toda la red.

Como las Network ACLs no tienen estado, sé qué puertos de mis subredes recibirán tráfico, pero no sé desde qué puertos voy a responder. Los puertos efímeros (1024-65535) son temporales y los asigna dinámicamente el sistema operativo para las conexiones de red salientes. No me queda más remedio que habilitar puertos efímeros desde los orígenes deseados o hacia los destinos deseados.

Como mencioné antes, al implementar un Gateway Endpoint se añade una ruta a la tabla de direcciones de la subred correspondiente. Esta ruta tiene como destino una Managed Prefix List que cubre todos los rangos de red del servicio, en este caso S3. Sin embargo, en las Network ACLs no puedo usar directamente una Managed Prefix List como origen o destino. Por eso hace falta revisar las direcciones presentes en la lista y establecer una regla para cada una de ellas.

En las subredes públicas hay que permitir tráfico entrante por el puerto 443 desde cualquier origen, así como puertos efímeros desde las subredes privadas. Además, hay que permitir tráfico saliente por puertos efímeros hacia Internet y desde el puerto 3000 hacia las subredes privadas.

Por otro lado, las subredes privadas deben permitir tráfico entrante por el puerto 3000 desde las subredes públicas y por puertos efímeros desde todos los rangos de direcciones del servicio S3 en la región concreta. También deben permitir tráfico saliente por puertos efímeros hacia la subred pública y por el puerto 443 hacia los rangos de S3.