A medida de que las organizaciones adoptan cada vez más un enfoque “cloud-native” (nativo en la nube) para desarrollar y escalar aplicaciones, los contenedores y Kubernetes desempeñan un papel fundamental en la gestión de las crecientes complejidades, mientras permiten desplegar cargas de trabajo en entornos multicloud.
Sin embargo, una encuesta reciente a profesionales de DevOps encontró que el 94% había experimentado al menos un incidente de seguridad de Kubernetes en el último año y que el 59% considera que la seguridad es su mayor preocupación cuando se trata de usar Kubernetes y contenedores. Mientras que cada vez más equipos de DevOps recurren a Kubernetes para satisfacer las demandas de escalabilidad de su organización, no se deben pasar por alto principios básicos como la seguridad y la protección de datos.
Desplegando Kubernetes
A los desarrolladores se les pide que creen aplicaciones más grandes y escalables en entornos más dinámicos. Por lo tanto, para el equipo de operaciones o de infraestructura, puede parecer un trabajo a tiempo completo mantenerse al día con las cambiantes prácticas de desarrollo de software. Kubernetes es sólo el último desafío (y posiblemente más complejo), pero su objetivo sigue siendo el mismo: ¿cómo podemos reducir el riesgo, minimizar costos y tener un mejor resultado para el negocio?
Los equipos de desarrollo son los «pioneros»: exploran nuevos terrenos y construyen algo donde antes no existía nada. Los equipos de operaciones e infraestructura, por su parte, son los «colonos», que llegan en una segunda oleada para consolidar los nuevos desarrollos y asegurarse de que sobreviven a largo plazo. Este es exactamente el caso de Kubernetes. Cuando Kubernetes se encuentra en la fase de virtualización o adopción, normalmente depende de los equipos de operaciones: la responsabilidad del resultado real del negocio recae en ellos.
Sin embargo, es mucho pedir que estos equipos entiendan las complejidades de Kubernetes y los contenedores. Incluso con las nuevas tecnologías, es necesario respetar los principios básicos: la seguridad, el backup y la recuperación siguen siendo necesarias. Pero son los requisitos técnicos únicos los que pueden suponer un reto.
Seguridad en Kubernetes y “zero trust”
Como programa nativo de la nube, muchos de los desafíos de seguridad para Kubernetes provienen de la naturaleza dispersa de la arquitectura de la nube. Las diferentes cargas de trabajo pueden ejecutarse en varias ubicaciones diferentes, incluyendo múltiples nubes, así como servidores locales y externos. Esto no solo aumenta enormemente el «panorama de amenazas» en el que puede producirse un ataque o un error, sino que también puede suponer retos de visibilidad, lo que dificulta la supervisión de los contenedores y la detección de problemas. Aunque Kubernetes está diseñado para ser seguro, ya que solo responde a las solicitudes que puede autenticar y autorizar, también ofrece a los desarrolladores opciones de configuración a medida, lo que significa que solo es realmente tan seguro como las políticas RBAC (control de acceso basado en roles) que configuran los desarrolladores.
Kubernetes también utiliza lo que se conoce como una «red plana» que permite a los grupos de contenedores (o pods) comunicarse con otros contenedores por defecto. Esto plantea problemas de seguridad ya que, en teoría, los atacantes que comprometen un pod pueden acceder a otros recursos en el mismo clúster.
A pesar de esta complejidad, la solución para eliminar este riesgo es bastante sencilla: una estrategia “zero trust”. Con una superficie de ataque tan grande, un diseño de red bastante abierto y cargas de trabajo ubicadas en diferentes entornos, una arquitectura de confianza cero, que nunca confía y siempre verifica, es crucial cuando se construye con Kubernetes.
El principio de la arquitectura de confianza cero consiste en alejar el foco de la seguridad del perímetro de una aplicación, aplicando esos principios en todo el entorno. Todas las solicitudes internas se consideran sospechosas y se exige la autenticación de arriba a abajo. Esta estrategia ayuda a mitigar el riesgo al suponer que las amenazas existen en la red en todo momento, por lo que mantiene constantemente procedimientos de seguridad estrictos en torno a cada usuario, dispositivo y conexión. Para la arquitectura fluida y descentralizada de Kubernetes, esto es imprescindible.
Backup y recuperación
Otro principio básico que se necesita para mitigar los riesgos de las aplicaciones Kubernetes es el backup y la recuperación. Este es un concepto bien conocido, pero hay muchas consideraciones particulares a la hora de hacer backup de Kubernetes y contenedores. Estos requisitos diferentes se deben a que Kubernetes es fundamentalmente diferente de otras arquitecturas, por ejemplo, no tiene aplicaciones de mapeo a los servidores o máquinas virtuales.
Los sistemas de backup de Kubernetes también tienen que estar centrados en las aplicaciones en lugar de centrarse en la infraestructura. Esto se debe a la filosofía DevOps y a los principios de «shift left», que esencialmente significan que el desarrollador tiene más control sobre la infraestructura y las implementaciones. Otros requisitos son la escala de la aplicación, las lagunas de protección y la integración del ecosistema.
Cuando se recuperan entornos Kubernetes, se necesita un plan de ejecución detallado que identifique las dependencias del clúster, actualice las aplicaciones para reflejar los nuevos componentes de almacenamiento y traduzca el plan en las interfaces de programación de aplicaciones (API) de Kubernetes pertinentes. Aunque las copias requieren una solución nativa de Kubernetes más a medida, estos procesos de recuperación siguen siendo fundamentales para la salud de la empresa a largo plazo.
Sin embargo, más allá de esto, el backup tiene un enorme valor en términos de pruebas y desarrollo y para permitir la movilidad de las aplicaciones. Esta se refiere a la capacidad de migrar una aplicación a un entorno diferente, ya sea en las instalaciones, las nubes, los clústeres o las distribuciones de Kubernetes. Esto es cada vez más importante a medida que los entornos de IT se vuelven más complejos y las empresas necesitan responder a nuevos requisitos empresariales, adoptar nuevas plataformas tecnológicas u optimizar costos.
Preparándonos para el cambio
A pesar de que Kubernetes presenta nuevos retos técnicos, en última instancia, cuanto más cambian las cosas, más permanecen igual. Los equipos de operaciones e infraestructura están acostumbrados a incorporar nuevas herramientas en las tecnologías disponibles, que están en constante expansión, y los principios básicos, como la mitigación de riesgos a través de la protección de datos moderna, siguen cumpliendo su propósito.
Una vez que se han establecido estas capacidades, los equipos de operaciones pueden empezar a mirar más allá y explorar el aprovechamiento del valor de sus datos a través de actividades como las pruebas y la optimización. A través de un backup sólido que admita la movilidad de las aplicaciones, los equipos también pueden recorrer un largo camino para prepararlas para el futuro, garantizando que los servicios puedan remontar fácilmente la próxima ola de cambios. Aunque Kubernetes es la herramienta actual que está cambiando el panorama del desarrollo, seguramente no será la última.
