Seguridad de los contenedores

Capítulo 1. Amenazas a la seguridad de los contenedores

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

En los últimos años, el uso de contenedores se ha disparado. Los conceptos en torno a los contenedores existían desde varios años antes de Docker, pero la mayoría de los observadores coinciden en que fueron las herramientas de línea de comandos fáciles de usar de Docker las que empezaron a popularizar los contenedores entre la comunidad de desarrolladores desde su lanzamiento en 2013.

Los contenedores aportan muchas ventajas : como se describe en el eslogan original de Docker, te permiten "construir una vez, ejecutar en cualquier lugar". Lo hacen agrupando una aplicación y todas sus dependencias y aislando la aplicación del resto de la máquina en la que se ejecuta. La aplicación en contenedores tiene todo lo que necesita, y es fácil empaquetarla como una imagen de contenedor que se ejecutará igual en mi portátil y en el tuyo, o en un servidor de un centro de datos.

Un efecto secundario de este aislamiento de es que puedes ejecutar varios contenedores diferentes uno al lado del otro sin que interfieran entre sí. Antes de los contenedores, podías acabar fácilmente con una pesadilla de dependencias en la que dos aplicaciones necesitaban versiones diferentes de los mismos paquetes. La solución más fácil a este problema era simplemente ejecutar las aplicaciones en máquinas separadas. Con los contenedores, las dependencias están aisladas unas de otras, por lo que resulta sencillo ejecutar varias aplicaciones en el mismo servidor. La gente se dio cuenta rápidamente de que podía aprovechar la contenedorización para ejecutar varias aplicaciones en el mismo host (ya sea una máquina virtual o un servidor bare-metal) sin tener que preocuparse por las dependencias.

El siguiente paso lógico era distribuir las aplicaciones en contenedores por un clúster de servidores. Los orquestadores como Kubernetes automatizan este proceso, de modo que ya no tienes que instalar manualmente una aplicación en una máquina concreta; le dices al orquestador qué contenedores quieres ejecutar, y él encuentra una ubicación adecuada para cada uno.

Desde el punto de vista de la seguridad, muchas cosas son iguales en un entorno en contenedores que en una implementación tradicional. Hay atacantes en el mundo que quieren robar datos, o modificar el modo en que se comporta un sistema, o utilizar los recursos informáticos de otras personas para minar sus propias criptomonedas. Esto no cambia cuando te pasas a los contenedores. Sin embargo, los contenedores cambian mucho la forma en que se ejecutan las aplicaciones, y como resultado hay un conjunto diferente de riesgos.

Riesgos, amenazas y mitigaciones

Un riesgo es un problema potencial, y los efectos de ese problema si llegara a producirse.

Una amenaza es una vía para que se produzca ese riesgo.

Una mitigación es una contramedida contra una amenaza: algo que puedes hacer para evitar la amenaza o al menos reducir la probabilidad de que tenga éxito.

Por ejemplo, existe el riesgo de que alguien te robe las llaves del coche de tu casa y se marche en él. Las amenazas serían las distintas formas en que podrían robar las llaves: romper una ventana para meter la mano y cogerlas; introducir una caña de pescar en el buzón; llamar a tu puerta y distraerte mientras un cómplice entra rápidamente para coger las llaves. Una forma de mitigar todas estas amenazas podría ser mantener las llaves del coche fuera de la vista.

Los riesgos varían mucho de una organización a otra. Para un banco que guarda dinero en nombre de sus clientes, el mayor riesgo es casi seguro que ese dinero sea robado. Una organización de comercio electrónico se preocupará por los riesgos de transacciones fraudulentas. Una persona que dirige un blog personal puede temer que alguien entre para hacerse pasar por ella y publicar comentarios inapropiados. Dado que las normativas sobre privacidad difieren entre países, el riesgo de filtrar los datos personales de los clientes varía con la geografía: en muchos países el riesgo es "sólo" de reputación, mientras que en Europa el Reglamento General de Protección de Datos (RGPD ) permite imponer multas de hasta el 4% de los ingresos totales de una empresa.

Como los riesgos varían mucho, la importancia relativa de las distintas amenazas también variará, al igual que el conjunto adecuado de mitigaciones. Un marco de gestión de riesgos es un proceso para pensar en los riesgos de forma sistemática, enumerar las posibles amenazas, priorizar su importancia y definir un enfoque para mitigarlas.

El modelado de amenazas es un proceso de identificación y enumeración de las amenazas potenciales a un sistema. Al examinar sistemáticamente los componentes del sistema y los posibles modos de ataque, un modelo de amenazas puede ayudarte a identificar dónde es más vulnerable tu sistema a los ataques.

No existe un modelo único y exhaustivo de amenazas, ya que depende de tus riesgos, de tu entorno concreto, de tu organización y de las aplicaciones que estés ejecutando, pero es posible enumerar algunas amenazas potenciales que son comunes a la mayoría, si no a todas, las Implementaciones de contenedores.

Modelo de amenaza de los contenedores

Una forma de empezar a pensar en el modelo de amenaza es considerar a los actores implicados. Estos podrían ser

• Atacantes externos que intentan acceder a una Implementación desde el exterior

• Atacantes internos que han conseguido acceder a alguna parte de la implementación

• Agentes internos malintencionados, como desarrolladores y administradores que tienen algún nivel de privilegio para acceder a la implementación

• Actores internos involuntarios que pueden causar problemas accidentalmente

• Procesos de aplicación que, aunque no sean seres sensibles que pretendan comprometer tu sistema, podrían tener acceso programático al sistema

Cada actor tiene una serie de permisos que debes tener en cuenta:

• ¿Qué acceso tienen mediante credenciales? Por ejemplo, ¿tienen acceso a cuentas de usuario en las máquinas host en las que se ejecuta tu implementación?

• ¿Qué permisos tienen en el sistema? En Kubernetes, esto podría referirse a la configuración del control de acceso basado en roles para cada usuario, así como a los usuarios anónimos.

• ¿Qué acceso a la red tienen? Por ejemplo, ¿qué partes del sistema están incluidas en una Nube Privada Virtual (VPC)?

Hay varias rutas posibles para atacar una implementación en contenedores, y una forma de mapearlas es pensar en los posibles vectores de ataque en cada etapa del ciclo de vida de un contenedor. Éstos se resumen en la Figura 1-1.

Figura 1-1. Vectores de ataque a contenedores

Código de aplicación vulnerable

El ciclo de vida comienza con el código de la aplicación que escribe un desarrollador. Este código, y las dependencias de terceros de las que depende, pueden incluir fallos conocidos como vulnerabilidades, y hay miles de vulnerabilidades publicadas que un atacante puede explotar si están presentes en una aplicación. La mejor forma de evitar ejecutar contenedores con vulnerabilidades conocidas es escanear las imágenes, como verás en el Capítulo 7. No se trata de una actividad puntual, porque continuamente se descubren nuevas vulnerabilidades en el código existente. El proceso de escaneado también debe identificar cuándo se están ejecutando contenedores con paquetes desactualizados que necesitan actualizarse para recibir parches de seguridad. Algunos escáneres también pueden identificar el malware que se ha incorporado a una imagen.

Imágenes de contenedor mal configuradas

Una vez escrito el código, se construye en una imagen de contenedor. Cuando configuras cómo se va a construir una imagen de contenedor, hay muchas oportunidades de introducir puntos débiles que luego se pueden utilizar para atacar al contenedor en ejecución. Por ejemplo, configurando el contenedor para que se ejecute como usuario root, dándole más privilegios en el host de los que realmente necesita. Leerás más sobre esto en el Capítulo 6.

Construye ataques de máquina

Si un atacante puede modificar o influir en la forma en que se construye una imagen de contenedor, podría insertar código malicioso que posteriormente se ejecutaría en el entorno de producción. Además, encontrar un punto de apoyo en el entorno de construcción podría ser un trampolín para penetrar en el entorno de producción. Esto también se trata en el Capítulo 6.

Ataques a la cadena de suministro

Una vez construida la imagen del contenedor, se almacena en un registro, y se recupera o "extrae" del registro en el momento en que se va a ejecutar. ¿Cómo sabes que la imagen que sacas es exactamente la misma que la que empujaste antes? ¿Podría haber sido manipulada? Un actor que pueda sustituir una imagen o modificarla entre la compilación y la implementación tiene la capacidad de ejecutar código arbitrario en tu implementación. Éste es otro tema que trataré en el Capítulo 6.

Contenedores mal configurados

Como discutiremos en el Capítulo 9, es posible ejecutar contenedores con configuraciones que le otorguen privilegios innecesarios, y quizás imprevistos. Si descargas archivos de configuración YAML de Internet, ¡no los ejecutes sin comprobar cuidadosamente que no incluyen configuraciones inseguras!

Anfitriones vulnerables

Los contenedores se ejecutan en máquinas anfitrionas, y tienes que asegurarte de que esos anfitriones no ejecutan código vulnerable (por ejemplo, versiones antiguas de componentes de orquestación con vulnerabilidades conocidas). Es una buena idea minimizar la cantidad de software instalado en cada host para reducir la superficie de ataque, y los hosts también deben configurarse correctamente según las buenas prácticas de seguridad. Esto se trata en el Capítulo 4.

Secretos al descubierto

El código de las aplicaciones a menudo necesita credenciales, tokens o contraseñas para comunicarse con otros componentes de un sistema. En una implementación en contenedor, necesitas poder pasar estos valores secretos al código en contenedor. Como verás en el Capítulo 12, hay diferentes enfoques para esto, con distintos niveles de seguridad.

Redes inseguras

Los contenedores suelen necesitar comunicarse con otros contenedores o con el mundo exterior. El Capítulo 10 trata de cómo funciona la red en los contenedores, y el Capítulo 11 trata de cómo establecer conexiones seguras entre los componentes.

Vulnerabilidades de escape de contenedores

Los tiempos de ejecución de contenedores más utilizados, como containerd y CRI-O, ya están bastante reforzados, pero aún es posible que se encuentren fallos que permitan que el código malicioso que se ejecuta dentro de un contenedor escape al host. Uno de estos problemas, conocido a veces como Runcescape, salió a la luz en 2019. Leerás sobre el aislamiento que se supone que mantiene limitado el código de la aplicación dentro de un contenedor en el Capítulo 4. Para algunas aplicaciones, las consecuencias de una fuga podrían ser lo suficientemente perjudiciales como para que merezca la pena considerar mecanismos de aislamiento más fuertes, como los que se tratan en el Capítulo 8.

También hay algunos vectores de ataque que quedan fuera del alcance de este libro.

• Por lo general, el código fuente se guarda en repositorios, que podrían ser atacados para envenenar la aplicación. Tendrás que asegurarte de que el acceso de los usuarios al repositorio se controla adecuadamente.

• Los hosts están conectados en red juntos, a menudo utilizando una VPC para la seguridad, y normalmente conectados a Internet. Exactamente igual que en una implementación tradicional, tienes que proteger las máquinas anfitrionas (o máquinas virtuales) del acceso de los actores de amenazas. La configuración segura de la red, el cortafuegos y la gestión de identidades y accesos siguen siendo aplicables en una implementación nativa en la nube, igual que en una implementación tradicional.

• Los contenedores suelen ejecutarse bajo un orquestador, normalmente Kubernetes en las implementaciones actuales, aunque hay otras opciones como Docker Swarm o Hashicorp Nomad. Si el orquestador está configurado de forma insegura o si el acceso administrativo no se controla eficazmente, esto proporciona a los atacantes vectores adicionales para afectar a la implementación.

Nota

Para saber más sobre los modelos de amenazas en las Implementaciones de Kubernetes, puede que te interese leer el Modelo de Amenazas de Kubernetes encargado por el CNCF.

Además, el Grupo de Usuarios Financieros del CNCF ha publicado un Árbol de Ataques a Kubernetes creado utilizando la metodología STRIDE.

Límites de seguridad

Un límite de seguridad (a veces llamado límite de confianza) aparece entre partes del sistema, de forma que necesitarías algún conjunto diferente de permisos para moverte entre esas partes. A veces, estos límites se establecen administrativamente: por ejemplo, en un sistema Linux, el administrador del sistema puede modificar el límite de seguridad que define a qué archivos puede acceder un usuario cambiando los grupos a los que pertenece. Si estás oxidado con los permisos de archivos de Linux, en el Capítulo 2 encontrarás un repaso.

Un contenedor es un límite de seguridad. Se supone que el código de la aplicación se ejecuta dentro de ese contenedor, y no debe poder acceder a código o datos fuera del contenedor, salvo que se le haya dado permiso explícito para hacerlo (por ejemplo, a través de un volumen montado en el contenedor).

Cuantos más límites de seguridad haya entre un atacante y su objetivo (los datos de tus clientes, por ejemplo), más difícil le resultará alcanzarlo.

Los vectores de ataque descritos en el "Modelo de Amenaza de Contenedores" pueden encadenarse para traspasar varios límites de seguridad. Por ejemplo:

• Un atacante puede descubrir que, debido a una vulnerabilidad en una dependencia de la aplicación, es capaz de ejecutar código de forma remota dentro de un contenedor.

• Supongamos que el contenedor violado no tiene acceso directo a ningún dato de valor. El atacante necesita encontrar una forma de salir del contenedor, ya sea a otro contenedor o al host. Una vulnerabilidad de escape del contenedor sería una ruta de salida del contenedor; la configuración insegura de ese contenedor podría proporcionar otra. Si el atacante encuentra cualquiera de estas rutas disponibles, ya puede acceder al host.

• El siguiente paso sería buscar formas de obtener privilegios de root en el host. Este paso puede ser trivial si el código de tu aplicación se ejecuta como root dentro del contenedor, como verás en el Capítulo 4.

• Con privilegios de root en la máquina anfitriona, el atacante puede acceder a cualquier cosa a la que pueda acceder el anfitrión o cualquiera de los contenedores que se ejecuten en ese anfitrión.

Añadir y reforzar los límites de seguridad en tu implementación hará la vida más difícil al atacante.

Un aspecto importante del modelo de amenazas es considerar la posibilidad de ataques desde dentro del entorno en el que se ejecutan tus aplicaciones. En las Implementaciones en la nube, puedes estar compartiendo algunos recursos con otros usuarios y sus aplicaciones. Compartir recursos de máquinas se denomina multiarrendamiento, y tiene una influencia significativa en el modelo de amenazas.

Multiarrendamiento

En un entorno multiarrendamiento, distintos usuarios, o arrendatarios, ejecutan sus cargas de trabajo en un hardware compartido. (Puede que también te encuentres con el término "multiarrendamiento" en el contexto de una aplicación de software, donde se refiere a varios usuarios que comparten la misma instancia de software, pero a efectos de este debate, sólo se comparte el hardware). Dependiendo de a quién pertenezcan esas diferentes cargas de trabajo y de cuánto confíen entre sí los diferentes inquilinos, puede que necesites límites más fuertes entre ellos para evitar que interfieran entre sí.

El multiarrendamiento es un concepto que existe desde los tiempos del mainframe en los años 60, cuando los clientes alquilaban tiempo de CPU, memoria y almacenamiento en una máquina compartida. Esto no es muy diferente de las nubes públicas actuales, como Amazon AWS, Microsoft Azure y Google Cloud Platform, donde los clientes alquilan tiempo de CPU, memoria y almacenamiento, junto con otras funciones y servicios gestionados. Desde que Amazon AWS lanzó EC2 allá por 2006, podemos alquilar instancias de máquinas virtuales que se ejecutan en bastidores de servidores en centros de datos de todo el mundo. Puede haber muchas máquinas virtuales (VM) ejecutándose en una máquina física, y como cliente de la nube que opera un conjunto de VM no tienes ni idea de quién está operando las VM vecinas a la tuya.

Máquinas compartidas

Hay situaciones en las que una única máquina Linux (o máquina virtual) puede ser compartida por muchos usuarios. Esto es muy habitual en entornos universitarios, por ejemplo, y es un buen ejemplo de verdadera multitenencia, en la que los usuarios no confían los unos en los otros y, francamente, los administradores del sistema no confían en los usuarios. En este entorno se utilizan controles de acceso Linux para limitar estrictamente el acceso de los usuarios. Cada usuario tiene su propio identificador de inicio de sesión, y los controles de acceso de Linux se utilizan para limitar el acceso y garantizar, por ejemplo, que los usuarios sólo puedan modificar los archivos de sus propios directorios. ¿Te imaginas el caos que se produciría si los estudiantes universitarios pudieran leer o -peor aún- modificar los archivos de sus compañeros?

Como verás en el Capítulo 4, todos los contenedores que se ejecutan en el mismo host comparten el mismo kernel. Si la máquina está ejecutando el demonio Docker, cualquier usuario que pueda emitir comandos docker tiene efectivamente acceso root, por lo que un administrador del sistema no querrá concederlo a usuarios que no sean de confianza.

En situaciones empresariales, y más concretamente en entornos nativos de la nube, es menos probable que veas este tipo de máquina compartida. En su lugar, los usuarios (o equipos de usuarios que confían los unos en los otros) suelen utilizar sus propios recursos asignados en forma de máquinas virtuales.

Virtualización

En general, se considera que las máquinas virtuales están bastante aisladas unas de otras, con lo que queremos decir que es poco probable que tus vecinos puedan observar o interferir en las actividades de tus máquinas virtuales. Puedes leer más sobre cómo se consigue este aislamiento en el Capítulo 5. De hecho, según la definición aceptada, la virtualización no cuenta en absoluto como multitenencia: la multitenencia es cuando diferentes grupos de personas comparten una única instancia del mismo software, y en la virtualización los usuarios no tienen acceso al hipervisor que gestiona sus máquinas virtuales, por lo que no comparten ningún software.

Eso no quiere decir que el aislamiento entre máquinas virtuales sea perfecto, e históricamente los usuarios se han quejado de problemas de "vecinos ruidosos", en los que el hecho de compartir una máquina física con otros usuarios puede provocar variaciones inesperadas en el rendimiento. Netflix fue uno de los primeros en adoptar la nube pública, y en la sección "Co-tenancy is hard" de una entrada de blog de 2010, reconoció que construyó sistemas que podían abandonar deliberadamente una subtarea si resultaba que funcionaba con demasiada lentitud. Más recientemente, otros han afirmado que el problema del vecino ruidoso no es un problema real.

También ha habido casos de vulnerabilidades de software que podrían comprometer el límite entre máquinas virtuales.

Para algunas aplicaciones y algunas organizaciones (especialmente gubernamentales, financieras o sanitarias), las consecuencias de un fallo de seguridad son lo suficientemente graves como para justificar una separación física total. Puedes utilizar una nube privada, que funcione en tu propio centro de datos o gestionada por un proveedor de servicios en tu nombre, para garantizar el aislamiento total de tus cargas de trabajo. Las nubes privadas a veces vienen con características de seguridad adicionales, como la comprobación de los antecedentes del personal que tiene acceso al centro de datos.

Muchos proveedores de la nube tienen opciones de máquinas virtuales en las que se garantiza que eres el único cliente en una máquina física. También es posible alquilar máquinas bare-metal operadas por proveedores de nube. En estos dos casos, evitarás por completo el problema del vecino ruidoso, y también tendrás la ventaja de un mayor aislamiento de seguridad entre máquinas físicas.

Tanto si alquilas máquinas físicas o virtuales en la nube como si utilizas tus propios servidores, si estás ejecutando contenedores, puede que tengas que considerar los límites de seguridad entre varios grupos de usuarios.

Multiarrendamiento de contenedores

Como verás en el Capítulo 4, el aislamiento entre contenedores no es tan fuerte como el que existe entre máquinas virtuales. Aunque depende de tu perfil de riesgo, es poco probable que quieras utilizar contenedores en la misma máquina que una parte en la que no confíes.

Incluso si todos los contenedores que se ejecutan en tus máquinas están dirigidos por ti o por personas en las que confías plenamente, es posible que quieras mitigar la falibilidad de los humanos asegurándote de que tus contenedores no puedan interferir entre sí.

En Kubernetes, puedes utilizar espacios de nombres para subdividir un clúster de máquinas para que lo utilicen distintas personas, equipos o aplicaciones.

Nota

La palabra "espacio de nombres" es un término sobrecargado. En Kubernetes, un espacio de nombres es una abstracción de alto nivel que subdivide los recursos del clúster a los que se pueden aplicar distintos controles de acceso de Kubernetes. En Linux, un espacio de nombres es un mecanismo de bajo nivel para aislar los recursos de la máquina que conoce un proceso. Aprenderás sobre este tipo de espacio de nombres en detalle en el Capítulo 4.

Utiliza el control de acceso basado en roles (RBAC) para limitar las personas y componentes que pueden acceder a estos diferentes espacios de nombres de Kubernetes. Los detalles sobre cómo hacerlo quedan fuera del alcance de este libro, pero me gustaría mencionar que el RBAC de Kubernetes sólo controla las acciones que puedes realizar a través de la API de Kubernetes. Los contenedores de aplicaciones en pods de Kubernetes que se ejecutan en el mismo host sólo están protegidos entre sí por el aislamiento de contenedores, como se describe en este libro, aunque estén en espacios de nombres diferentes. Si un atacante puede escapar de un contenedor al host, el límite del espacio de nombres de Kubernetes no supone ni una pizca de diferencia en su capacidad para afectar a otros contenedores.

Instancias del contenedor

Los servicios en la nube como Amazon AWS, Microsoft Azure o Google Cloud Platform ofrecen muchos servicios gestionados, mediante los cuales el usuario puede alquilar software, almacenamiento y otros componentes sin tener que instalarlos ni gestionarlos. Un ejemplo clásico es el Servicio de Bases de Datos Relacionales (RDS) de Amazon; con RDS, puedes aprovisionar fácilmente bases de datos que utilicen software conocido como PostgreSQL, y obtener copias de seguridad de tus datos es tan sencillo como marcar una casilla (y pagar una factura, por supuesto).

Los servicios gestionados también se han extendido al mundo de los contenedores. Azure Container Instances y AWS Fargate son servicios que te permiten ejecutar contenedores sin tener que preocuparte de la máquina subyacente (o máquina virtual) en la que se ejecutan.

Esto puede ahorrarte una importante carga de gestión y te permite escalar fácilmente la implementación a voluntad. Sin embargo, al menos en teoría, tus instancias de contenedor podrían colocarse en la misma máquina virtual que las de otros clientes. Consulta con tu proveedor de la nube en caso de duda.

Ahora ya conoces un buen número de amenazas potenciales para tu implementación. Antes de sumergirnos en el resto del libro, me gustaría introducir algunos principios básicos de seguridad que deberían guiar tu pensamiento a la hora de evaluar qué herramientas y procesos de seguridad necesitas introducir en tu implementación.

Principios de seguridad

Se trata de directrices generales que suelen considerarse un enfoque sensato, independientemente de los detalles de lo que intentes conseguir.

Mínimo privilegio

El principio del menor privilegio establece que debes limitar el acceso al mínimo indispensable que una persona o componente necesita para hacer su trabajo. Por ejemplo, si tienes un microservicio que realiza la búsqueda de productos en una aplicación de comercio electrónico, el principio del menor privilegio sugiere que el microservicio sólo debe tener credenciales que le den acceso de sólo lectura a la base de datos de productos. No necesita acceder, por ejemplo, a la información de usuario o de pago, ni escribir información sobre productos.

Defensa en profundidad

Como verás en este libro, hay muchas formas distintas de mejorar la seguridad de tu implementación y de las aplicaciones que se ejecutan en ella. El principio de defensa en profundidad nos dice que debes aplicar capas de protección. Si un atacante es capaz de violar una defensa, otra capa debería impedirle dañar tu implementación o filtrar tus datos.

Reducir la superficie de ataque

Por regla general, cuanto más complejo es un sistema, más probable es que exista una forma de atacarlo. Eliminar la complejidad puede hacer que el sistema sea más difícil de atacar. Esto incluye

• Reducir los puntos de acceso manteniendo las interfaces pequeñas y sencillas siempre que sea posible

• Limitar los usuarios y componentes que pueden acceder a un servicio

• Minimizar la cantidad de código

Limitación del radio de explosión

El concepto de segmentar los controles de seguridad en subcomponentes más pequeños o "células" significa que, si ocurre lo peor, el impacto es limitado. Los contenedores se adaptan bien a este principio, porque al dividir una arquitectura en muchas instancias de un microservicio, el propio contenedor puede actuar como frontera de seguridad.

Segregación de funciones

Relacionada tanto con el privilegio mínimo como con la limitación del radio de explosión está la idea de segregar las funciones de modo que, en la medida de lo posible, a los distintos componentes o personas sólo se les dé autoridad sobre el subconjunto más pequeño del sistema global que necesiten. Este enfoque limita el daño que podría infligir un único usuario con privilegios, asegurándose de que determinadas operaciones requieran más autoridad que la de un solo usuario.

Aplicar principios de seguridad con contenedores

Como verás en secciones posteriores de este libro, la granularidad de los contenedores puede ayudarnos en la aplicación de todos estos principios de seguridad.

Menor privilegio

Puedes dar a distintos contenedores diferentes conjuntos de privilegios, cada uno minimizado al menor conjunto de permisos que necesite para cumplir su función.

Defensa en profundidad

Los contenedores proporcionan otro límite en el que se pueden aplicar las protecciones de seguridad.

Reducir la superficie de ataque

Dividir un monolito en microservicios sencillos puede crear interfaces limpias entre ellos que, si se diseñan con cuidado, pueden reducir la complejidad y, por tanto, limitar la superficie de ataque. Existe el contraargumento de que añadir una compleja capa de orquestación para coordinar los contenedores introduce otra superficie de ataque.

Limitar el radio de la explosión

Si una aplicación en contenedor se ve comprometida, los controles de seguridad pueden ayudar a restringir el ataque dentro del contenedor y evitar que afecte al resto del sistema.

Segregación de funciones

Los permisos y credenciales sólo se pueden pasar a los contenedores que los necesitan, de modo que el compromiso de un conjunto de secretos no significa necesariamente que se pierdan todos los secretos.

Estas ventajas suenan bien, pero son algo teóricas. En la práctica, pueden verse fácilmente contrarrestadas por una mala configuración del sistema, una mala higiene de la imagen del contenedor o prácticas inseguras. Al final de este libro, deberías estar bien armado para evitar las trampas de seguridad que pueden aparecer en una implementación en contenedores y aprovechar las ventajas.

Resumen

Ahora tienes una visión de alto nivel de los tipos de ataques que pueden afectar a una implementación basada en contenedores, y una introducción a los principios de seguridad que puedes aplicar para defenderte de esos ataques. En el resto del libro profundizarás en los mecanismos que sustentan los contenedores, de modo que puedas comprender cómo se combinan las herramientas de seguridad y los procesos de buenas prácticas para aplicar esos principios de seguridad.