Snyk en Snyk: habilitar RBAC de Kubernetes para los desarrolladores de Snyk

Como dijo el tío Ben: «Un gran poder conlleva una gran responsabilidad». Esto también aplica a la API de Kubernetes. Es muy poderosa y permite crear cosas increíbles, pero tiene un costo: un usuario malintencionado también puede usarla para hacer daño.

Aquí entra en juego Kubernetes RBAC (control de acceso basado en roles), que permite usar la API de forma controlada al otorgar solo los privilegios necesarios, siguiendo el principio de mínimo privilegio.

Kubernetes permite definir roles dentro de los espacios de nombres y roles de clúster fuera de ellos.

Pero esto solo traslada el problema a otro lugar: necesitamos buenos procesos para los recursos RBAC, o un simple error de configuración podría tener un grave impacto en la seguridad. Pensemos, por ejemplo, en un desarrollador que «accidentalmente» asigna el rol de administrador del clúster a la cuenta de servicio predeterminada en el espacio de nombres predeterminado. ¡Qué horror!

Foto de https://unsplash.com/@arnykoor

El enfoque de ruta pavimentada para la seguridad de Kubernetes

Lo ideal sería permitir que cada desarrollador cree los permisos RBAC que necesite y, al mismo tiempo, establecer medidas de protección para bloquear lo que no sea seguro. Una forma de lograrlo es exigir que AppSec revise el código de cualquier cambio que incluya recursos RBAC. Aunque esto podría funcionar, tiene algunas desventajas:

• AppSec se convierte en un obstáculo que ralentiza a los desarrolladores.

• La seguridad se vuelve algo «mágico» que solo conoce AppSec, porque no hay pautas publicadas sobre qué busca al revisar estos cambios.

• Terminamos profundizando los silos e impidiendo que los desarrolladores asuman responsabilidades de seguridad, lo que agrava aún más el problema de que AppSec sea un cuello de botella que los ralentiza.

Lista de verificación de seguridad de Kubernetes RBAC

En Snyk, enfrentamos problemas similares. Queríamos darles más autonomía a nuestros desarrolladores y permitirles usar la API de Kubernetes sin ralentizarlos. Empezamos por compilar una lista de requisitos de seguridad para las reglas RBAC. La lista es bastante breve y se basa principalmente en los benchmarks de CIS Kubernetes:

• No usar recursos ni verbos comodín

• No usar reglas integradas, ya que otorgan demasiados permisos

• No vincular cuentas de servicio a los espacios de nombres default (que deberían estar vacíos) ni kube-system (donde se ejecutan cargas de trabajo confidenciales)

• No vincular la cuenta de servicio predeterminada

• No usar permisos peligrosos, como crear pods o leer secretos

Una vez compilada la lista, podemos hacer varias cosas con ella:

• Publicarla como nuestras pautas internas y exigir que todos los objetos RBAC las cumplan. Así, los criterios dejan de ser algo «mágico».

• Pedirles a nuestros desarrolladores e ingenieros de seguridad que documenten como riesgo de seguridad cualquier incumplimiento de la lista e informen a AppSec.

• Solicitar comentarios e invitar a todos los desarrolladores a contribuir y actualizar la lista para derribar los silos.

• AUTOMATIZACIÓN. Al fin y al cabo, una vez que tenemos una lista, queremos que sea increíblemente fácil probarla.

Automatizar las verificaciones de configuración de Kubernetes con Snyk IaC

A fines de 2020, Snyk anunció un nuevo producto: Snyk Infrastructure as Code (Snyk IaC). Snyk IaC incluye un conjunto de reglas que podemos usar para probar nuestro código de IaC, incluidos los manifiestos de Kubernetes (y Terraform, pero eso queda para otro blog). Una de las ventajas de trabajar en Snyk es tener acceso anticipado a las funciones y, mejor aún, poder contribuir al producto.

Así que, después de compilar la lista, nos pusimos en contacto con el equipo de Snyk IaC para conversar sobre nuestra lista de verificación de Kubernetes RBAC y, ¡voilà!, tenemos cinco nuevas verificaciones en Snyk IaC que nos ayudan a automatizar las comprobaciones de seguridad y a evitar que AppSec se convierta en un cuello de botella.

Hacer que la seguridad de IaC sea increíblemente fácil para los desarrolladores de Snyk

Snyk IaC puede analizar mediante GitHub Actions y generar resultados en formato Sarif, que se pueden integrar con GitHub Security. Pero queríamos ir un paso más allá y mostrar los incumplimientos directamente en nuestras solicitudes de incorporación de cambios (PR), algo que Snyk IaC todavía no hace. Nuestro equipo de AppSec lo logró escribiendo nuestra propia integración con GitHub: cada cambio en los archivos de manifiesto de Kubernetes se analiza automáticamente con Snyk al confirmarlo y, si hay un incumplimiento, el desarrollador recibe una advertencia clara en la PR:

Ahora, todos nuestros desarrolladores pueden hacer cambios en RBAC sin detenerse para involucrar a AppSec, y el equipo de AppSec puede estar más tranquilo, sabiendo que Snyk nos cuida las espaldas.

¿Quieres algo similar para tu equipo? Consulta aquí el repositorio de ejemplo y asegúrate de tener una cuenta de Snyk: ¡puedes empezar a usar IaC gratis!