¿Es seguro correr contenedores sobre Kubernetes? Sí, si sigues estos consejos.

Cuando hablamos de mover cargas a la nube, Kubernetes es posiblemente el orquestador más común para hacerlo. Es tan popular debido a su naturaleza declarativa, la cual permite abstraer los detalles de la infraestructura y permite a los desarrolladores especificar las cargas de trabajo que desean ejecutar y los resultados deseados, por lo que no necesitan tener que gestionar la infraestructura.

Pero es su propio diseño, que invita a “olvidarse” de la infraestructura y el uso que se hace de ella, lo que nos lleva a poder decir, que Kubernetes no es seguro por naturaleza.

Esto es algo que no preocupa de inicio, cuando haces pruebas de concepto o estás en entornos no críticos o no productivos. Sin embargo, cuando se llevan cargas a entornos productivos del tipo que sea, aprovechando las ventajas de Kubernetes, se deben tener planes detallados de seguridad, de solución de problemas y de observabilidad para mover de manera segura y eficiente las aplicaciones a este tipo de entornos y así poder obtener todos los beneficios de Kubernetes (con los menores dolores de cabeza posibles).

Para evitar estos problemas, resumimos, en una serie de puntos, aquellas áreas donde hay que poner el foco, y vamos a ver cómo mitigar posibles quebraderos de cabeza o incluso adelantarnos a ellos.

El objetivo de este post es el de poder conformar una checklist que revisar cuando vayamos a usar Kubernetes y poder hacerlo por lo tanto de manera totalmente confiable.

Definir una política de seguridad y observabilidad

Cuando hablamos de mover cargas a un entorno productivo, utilizando Kubernetes, hay diferentes aspectos a considerar dentro del ámbito de la seguridad y la observabilidad. Se pueden agrupar en tres grandes bloques:

1. Tiempo de construcción de nuestras aplicaciones, donde hay que poner foco en lo construido, dependencias de código o librerías.

• Realizar escaneos de imágenes a nuestros contenedores para asegurar que no hay vulnerabilidades.
• Poner foco en la seguridad de pipeline de CI / CD, ya que sobre él recae toda la responsabilidad de la construcción de los diferentes artefactos.
• Asegurar que la aplicación construida tiene solo los permisos que necesita a nivel de llamadas al sistema o interacciones con el mismo.
• Asegurarse de que la composición del contenedor es lo mínimo e indispensable, minimizando el número de paquetes que no se necesitan.

2. Tiempo de despliegue, momento en el cual hay que centrarse en la propia securización del cluster, servicios que vamos a exponer, firewalls o definición de perímetros de seguridad

• Hay que definir lo que nuestra aplicación va a necesitar a nivel de recursos de infraestructura, y hacerlo patente sobre nuestro cluster de despliegue eliminando lo que no sea necesario.

3. Tiempo de ejecución, que será cuando las aplicaciones utilizarán la infraestructura y la red del cluster de Kubernetes. Aquí tenemos que tener en cuenta las prácticas recomendadas de seguridad cuando se instala un clúster de Kubernetes.

• Definición de políticas de red y de administradores del cluster utilizado
• Herramientas de observabilidad y/o detección de amenazas

En la siguiente tabla podemos observar todo de forma más resumida:

A continuación, os contamos unos consejos para cubrir estos bloques.

Hacer más segura tu infraestructura

Para lograr que la infraestructura donde correrán nuestros servicios sea segura, centraremos el “hardening” (asegurarnos de que todo es seguro y estable) en tres puntos bien diferenciados.

1. Host, donde nos centraremos en el sistema operativo escogido, evitando principalmente procesos no necesarios y configuraciones no deseadas.

• Escoger un sistema operativo que encaje en nuestras necesidades, a poder ser, en su última versión estable.
• Aplicar los últimos parches de seguridad.
• Eliminar todo lo que no sea necesario para que la imagen sea lo más liviana posible.
• Intentar escoger distribuciones de sistema operativos diseñadas para correr contenedores, que ya cumplen lo anterior, como pueden ser Flatcar Container Linux (CoreOS Linux) o Bottlerocket.

2. Cluster, aquí hay que poner atención a las diferentes posibles configuraciones y políticas de seguridad que conforman el plano de control, a la configuración de certificados, rotación de credenciales y almacenamiento del propio Kubernetes.

• Kubernetes almacena toda su configuración y el estado del cluster en una base de datos de clave-valor distribuida llamada etcd. Quién pueda acceder a esta base de datos, tiene acceso “root” a todos tus nodos, por lo que hay que asegurar que únicamente puede acceder quien debe.
• Por encima de etcd tenemos el API server que Kubernetes crea, y es también crucial asegurarse que el acceso a este API está controlado, sea a través de certificados o del modo que consideremos.
• Como consejo extra, Kubernetes puede ser configurado para que encripte toda la información sensitiva o relevante, para que en caso de acceso no deseado haya una complicación adicional para el atacante.
• Define una política de rotación de claves del cluster para hacer más difícil cualquier intento de acceso no deseado.
• Habita los procesos de auditoría que Kubernetes provee para facilitar la visión de lo que está ocurriendo en el cluster.
• Para facilitar y reducir todos los puntos anteriores, si vamos a la nube, utiliza un servicio gestionado de Kubernetes (como puede ser GKE en el caso de Google Cloud), que se encargará de gestionar de forma sencilla y transparente para los usuarios algunos de los puntos anteriores.

3. Redes, donde tendremos que trabajar en hacer más seguro el perímetro de nuestro cluster y controlar la comunicación desde dentro y fuera.

• Considera quién debe acceder al cluster, y a dónde se tiene que poder acceder desde el cluster.
• Define políticas de red en el interior del propio cluster.
• Crea firewalls, grupos de políticas de seguridad que te ayuden a delimitar el perímetro del cluster y la comunicación que se produce en él.
• De nuevo, apóyate en servicios gestionados de Kubernetes que te ayuden a definir y aplicar estos puntos anteriores de forma sencilla y eficiente.

Despliegues más seguros

A la hora de hacer los despliegues, hay que crear pipelines de CI/CD o modificar los existentes para que nos permitan poner foco en que lo que se despliega cumple ciertos parámetros de seguridad.

Para ello, nuestro flujo debe examinar las imágenes de los contenedores que se van a desplegar, crear un informe que en el caso de que se detecten amenazas, se auditará de forma manual y se decidirá si aceptar o no el despliegue.

Para lograr esto, de nuevo, no reinventemos la rueda, sino que podemos apoyarnos en cualquiera de las diferentes soluciones de mercado de análisis de imágenes que hay y que se integren con nuestro actual pipeline.

Tener todo bajo control en tiempo de ejecución

Y después del despliegue, ¿ya podemos relajarnos o podemos prestar atención a algo más? Pues hay algunos puntos que deberíamos revisar.

PSPs, Kubernetes trae una forma segura de gestionar los pods y contenedores utilizando lo que llama Pod Security Policies. Es recomendable valorar si debemos utilizarlas o no.

Estas políticas definen y acotan acciones a nivel de seguridad y contexto dentro del cluster de Kubernetes.

Aunque no es el objetivo del post, de forma resumida, diremos que estas políticas se definen en 3 simples pasos:

• Creación de la política en sí, definición del PSP que engloba lo que se puede o no se puede hacer.
• Creación de un rol dentro del cluster que usará está política y por lo tanto tendrá la autorización para realizar las tareas definidas.
• Crear el enlace que unirá el rol creado a los diferentes grupos o cuentas de servicio.

Una vez activadas las PSPs en Kubernetes, se abre la posibilidad de crear estas políticas que nos permiten de una forma mucho más detallada aplicar reglas de seguridad extra. ¡OJO!, asegúrate antes de que tu distribución de Kubernetes soporta PSPs.

Observabilidad y seguridad

Siguiendo esta checklist, podemos poner ya a funcionar nuestros servicios en producción, de manera mucho más segura y confiable, y ahora sólo nos queda monitorizar nuestro sistema, aplicando conceptos de observabilidad.

Apóyate en las capacidades nativas de Kubernetes para la recopilación y explotación de métricas con el objetivo de conocer el estado de salud de tus pods y, en general, de tu cluster.

Utiliza estas métricas para poder crear alarmas que de forma proactiva nos avisen de errores o incluso nos permitan adelantarnos a posibles problemas.

De nuevo, insisto, aprovecha la capacidad de los servicios gestionados que algunas nubes ofrecen, como GKE de Google Cloud, para poder ver de forma sencilla lo que ocurre en nuestro cluster gracias a las herramientas que ya ofrecen.

Conclusiones

Kubernetes es el motor de orquestación más adoptado para implementar aplicaciones modernas y se utiliza tanto en la nube pública como en CPDs privados. Debido a esto, aprovecha que hay ya soluciones muy maduras para hacer uso de Kubernetes como servicio gestionado como solución.

Es declarativo por naturaleza y por lo tanto nos permite especificar los resultados que esperamos obtener una vez desplegados nuestros servicios (por ejemplo, el escalado, seguridad, acceso, etc.).

Además, monitoriza de forma continua el estado del cluster, lo que facilita la implementación y toma de medidas correctivas que nos garanticen que todo está funcionando según lo especificado.

Kubernetes nos abstrae los detalles de la red, las direcciones IP, etc., pero eso no quiere decir que no tengamos que prestar atención en la configuración de todos estos aspectos, sobre todo cuando vamos a entornos productivos.

Por estas características, a la hora de implementar observabilidad y seguridad para Kubernetes, se necesita un enfoque diferente.

Y para finalizar una píldora extra (roja en este caso)

Aquí podéis ver un enlace con un montón de artículos basados en experiencias reales fallidas del uso de Kubernetes. Son de estas experiencias de lo que más se aprende y, sin duda, nos da una visión de que utilizar Kubernetes no debería tomarse a la ligera.