hardening-kubernetes-pautas-basicas-de-seguridad-1

Hardening Kubernetes: Pautas básicas de seguridad

Raul Unzue Pulido 21 junio, 2020 Ciberseguridad, Kubernetes, Linux, Virtualizacion Deja un comentario 2,649 Vistas

Hardening Kubernetes: Pautas básicas de seguridad

Hardening en informática, es el proceso de asegurar un sistema mediante la reducción de vulnerabilidades.

Esas vulnerabilidades, pueden ser usuarios, servicios, configuraciones o software innecesarios en el sistema, para el objetivo que ha sido generado, es decir, que no aportan realmente nada a la experiencia de usuario.

El objetivo principal del hardening, es el de entorpecer la labor del atacante y ganar tiempo para poder minimizar los problemas ante un incidente de seguridad.

Realmente, los que vivimos de la informática, tenemos claro que ningún sistema es invulnerable, pero trabajar el Hardening aportará capas adicionales de seguridad sobre vuestras aplicaciones e infraestructuras IT, que complementando a dispositivos como firewalls y sistemas SEM/SIEM o de monitorización de la plataforma, dificultan enormemente la labor de los atacantes.

Por suerte, también podemos trabajar en Kubernetes el Hardening para lograr una infraestructura segura.

Os vamos a dar, en los siguientes apartados, unas pocas pautas que podéis utilizar:

Secretos: Si queremos empezar a securizar nuestros proyectos de Kubernetes, podemos empezar con buenas prácticas no almacenando en claro objetos con datos sensibles, como contraseñas, llaves SSH o tokens de OAuth. El uso de Secretos te permite controlar la manera en que se usan los datos sensibles, y reduce notablemente el riesgo de exposición de esos datos sensibles a usuarios no autorizados. Lo veremos con más detalle en otra entrada.
Puertos privilegiados: Hay que evitar asignar puertos privilegiados en Pods en todo lo posible. Los puertos TCP/IP privilegiados son los menores a 1024 y son especiales en cualquier sistema operativo. Una de sus características, es que normalmente un usuario básico, no tiene privilegios para correr servicios que escuchen en ellos. Esto cambia un poco cuando trabajas con contenedores, ya que sí somos capaces de publicarlos. Por lo que sería conveniente dejar estos puertos para excepciones, como balanceadores de carga, que gestionen las conexiones.
SSH en contenedores: Podemos tener la costumbre de querer implementar un server SSH en contenedores Linux. Esto no debería realizarse, ya que todas las conexiones a la infraestructura debería realizarse a través del host. Levantar SSH en contenedores, hace más compleja la plataforma, complica la gestión de políticas de acceso y actualizaciones.
Chequear infraestructura periódicamente: Existen herramientas (EJ: Kube Bench, https://github.com/aquasecurity/kube-bench) que nos permiten de una forma rápida chequear a nivel de seguridad nuestra infraestructura. Una buena práctica, es realizar este tipo de chequeos periódicamente.
Capabilities Linux: Las capabilities son una herramienta útil para asegurar sistemas Linux. Son atributos especiales en el kernel, que otorgan privilegios específicos a procesos y ejecutables binarios. Lo que nos permite dar a un proceso algunos privilegios, pero no todos los privilegios, por ejemplo, del usuario root.
Evitar contenedores privilegiados: si ejecutamos contenedores con privilegios, permitiría al contenedor hacer casi las mismas cosas que el host puede hacer.
Uso de Selinux o AppArmor: Estas dos herramientas permiten aislar aplicaciones dentro de otras dentro de un sistema. Aunque son herramientas muy complejas de implementar, según la criticidad de nuestra infraestructura, deberíamos plantear su uso. Por una parte, SELinux, se basa en añadir etiquetas de seguridad a los objetos y AppArmor usa perfiles de programas para restringir de forma individual capacidades de ciertos programas. El uso de una u otra, dependerá del host y la distribución linux que se use en el host.
RBAC: Cuando hablamos de dar permisos en un clúster de Kubernetes, tendremos que hablar del control de acceso basado en Roles. O lo que se denomina Role Based Access Control o RBAC, el cual maneja políticas de seguridad para usuarios, grupos o Pods, y que está implementado de una forma estable desde la versión 1.8 de Kubernetes. Lo veremos con más detalle en otra entrada.
Gestión de recursos y límites: Cuando creas contenedor en una infraestructura Kubernetes, sobre todo en Producción, es importante gestionar los recursos y límites que vamos a asignar a nuestras aplicaciones. A nivel de seguridad es importante, porque un solo contenedor, al compartir un host con otros contenedores, podría generar una denegación de servicio. En la generación del Pod lo podemos controlar fácilmente mediante las secciones Requests y Limits en el fichero de ejecución YML o YAML. Lo veremos con más detalle en otra entrada
Actualizaciones: revisaremos periódicamente bugs que se puedan corregir mediante actualizaciones tanto de nuestro Cluster como de nuestras apps publicadas.