¿Cuáles son las recomendaciones básicas para operar de forma segura con GKE? En este artículo compartimos con vosotros algunas recomendaciones de seguridad y buenas prácticas para asegurar un poco más tu cluster de Google Kubernetes Engine (GKE) y su seguridad.
No uses la cuenta de servicio por defecto
Puede sonar básico para algunas personas, pero no todo el mundo sabe acerca de los problemas de seguridad de la utilización de la cuenta de servicio por defecto. Esta cuenta por defecto tiene un rol de editor adjunto, por lo que su acceso es casi ilimitado y una cuenta de carácter peligroso. Si alguien es capaz de comprometer un nodo de tu cluster, será capaz de hacer cosas como crear o/y borrar instancias, robar credenciales, datos, entre otros.
Desde Making Science te aconsejamos evitar el uso de esa cuenta en todas partes, y es por esto que tendrás que crear una nueva cuenta de servicio para el cluster GKE. Esta cuenta se configura a nivel de pool, por lo que podemos crear un nuevo pool en cualquier momento y migrar nuestros servicios en cualquier momento sin destruir el cluster.
Nota importante: No olvides añadir al menos los roles Logs Writer y Monitoring Metric Writer y nunca adjuntar un rol primitivo a esa cuenta de servicio.
Si es posible, no utilices nunca claves de cuentas de servicio
Esta es una recomendación general. No utilices una clave generada por una cuenta de servicio si es posible. La razón es que las claves no se rotan automáticamente y por lo tanto debemos rotarlas manualmente cada vez. Esto no siempre es posible y es un problema de seguridad. El acceso IAM en cambio, gestiona la rotación de claves automáticamente y es, por tanto, más seguro. Si su aplicación es capaz de iniciar sesión utilizando la cuenta de servicio por defecto en la instancia, el mejor enfoque es utilizar la identidad de carga de trabajo para poder vincular las cuentas de servicio de Google con las cuentas de servicio de K8s.
Para utilizar las GSA (cuentas de servicio de Google) en K8s, habilitaremos la opción de identidad de carga de trabajo en el cluster, y luego vincularemos la KSA (cuenta de servicio de Kubernetes) a una GSA. Una vez hecho esto, adjuntaremos esa KSA a un deployment, statefulset, etc… y entonces los pods creados por ella podrán iniciar sesión usando la cuenta de servicio por defecto.
Nota importante: La recomendación aquí es la misma que la de las instancias y es utilizar una cuenta de servicio diferente para cada servicio.
Nunca utilice roles primitivos
Esta es también una recomendación general y es seguir el principio de mínimo privilegio. NUNCA use roles primitivos en la Cuenta de Servicio porque puede llevar a una severa brecha de seguridad.
Encripta la base de datos de secretos usando KMS
Por defecto en GKE la base de datos etcd está encriptada en reposo (como todo), pero este archivo es accesible desde el interior de los nodos de GKE sin encriptación, por lo que puede ser extraído por un atacante si gana suficiente acceso al cluster. Para añadir una capa de seguridad adicional, podemos utilizar el servicio KMS para cifrar los datos utilizando una clave simétrica, por lo que extraer los datos de etcd será mucho más difícil.
Para ello, necesitaremos crear un llavero y una clave simétrica en el servicio KMS. Una vez creada la clave, configuraremos el cifrado de secretos de la capa de aplicación para que utilice esa clave.
Desactiva las autenticaciones inseguras
Asegúrate de que las autenticaciones heredadas e inseguras están deshabilitadas. Por ejemplo:
- Autorización heredada
- Autenticación básica
Habilita la autorización binaria
La autorización binaria es un servicio que le permitirá comprobar si los servicios desplegados en su cluster están validados. Esto se hace verificando que el despliegue está firmado, por lo que evitará que un atacante pueda desplegar un servicio comprometido aunque haya conseguido acceso al cluster.
Este enfoque también es muy útil para asegurarse de que todos los servicios desplegados en el cluster han superado una serie de pasos, por ejemplo, un pipeline de CI/CD que comprueba la seguridad de la imagen.
No utilices nunca la cuenta de root en el pod
Como siempre, debemos utilizar la cuenta de root en cualquier lugar es inseguro. Si un atacante consigue acceder al pod, tendrá acceso ilimitado a él. Lo mejor es crear una cuenta de servicio personalizada con el mínimo acceso en la imagen del pod y utilizarla para ejecutar todos los servicios. Esto protegerá tu pod de accesos no autorizados.
Utiliza un sistema de archivos R/O
Por defecto todos los pods pueden escribir en el sistema de archivos, lo que puede ser aprovechado por un atacante para ejecutar código en su servidor modificando o añadiendo archivos al mismo. Los pods son stateful y esto puede solucionarse simplemente reiniciando el pod, pero puede ser tardío para nuestra aplicación y puede haber sido comprometido de otras formas, como inyectando código en la base de datos o incluso obteniendo datos privados de la misma.
La mejor manera de evitar este tipo de vulnerabilidad es tener una aplicación bien programada, pero nada es totalmente seguro, por lo que es bueno tener una capa de seguridad extra habilitando el acceso R/O. Esto se puede hacer simplemente usando la opción readOnlyRootFilesystem en el despliegue.
Por supuesto, estas no son todas las recomendaciones para asegurar tu cluster GKE, pero es un punto de partida. ¿Quieres saber más sobre la seguridad de GKE? Nuestro equipo de expertos estará encantado de ayudarte en tu caso concreto. ¡Escríbenos! ⛅️
Configuración de cookies