Open Policy Agent: controles de seguridad al alcance de devops
No se si alguna vez habéis intentado usar SELinux. Es un sistema de seguridad increíblemente potente y flexible que le da mil patadas a chown y chmod, y se puede ocupar de que tus deslices de permisos sean contenidos como incidentes de seguridad. Pero si no tienes experiencia con él, juega tanto en tu contra como lo hace en contra de tus atacantes. Pero cómo podemos aprovechar estos sistemas a nuestro favor?
¿Qué hace exactamente SELinux?
SELinux es una suite de seguridad de Linux que aplica controles de seguridad obligatorios (Mandatory Access Controls), que a diferencia de los Discrecionales (Discretionary Access Controls), aún con un desliz de permisos, no tiene acceso fuera de su rol. Puedes hacer chown www-data y chmod 777 a los archivos de tu home, que si no están taggeados como grupo “webserver” de SELinux, los binarios de webserver no podrán acceder a esos directorios. Y eso es dentro de los estándares preexistentes, si quieres generar tu propio módulo, prepárate para leer documentación como nunca has leído.
¿Puedo facilitar este trabajo de desarrollo?
Igual que utilizar Kubernetes en vez de orquestar tus propios contenedores, hay herramientas existentes que aplican las ventajas del control de acceso obligatorio abstrayéndolas detrás de una API que facilita el uso y reutilización de normas y módulos. Aprovecha lo que la comunidad ya ha hecho, y no peques del síndrome Not Invented Here. Dicho esto, depende del sistema que tengas, puede que te sirva o no. El ejemplo de SELinux es un sistema de control de permisos en hosts linux como CentOS o Red Hat Enterprise Linux.
Si quieres utilizarlo en un contenedor de Docker, será algo más complicado. Para esto se deben utilizar herramientas específicas para el mismo objetivo. Una herramienta muy extendida para esta tarea es Open Policy Agent.
¿Qué beneficios me da esta herramienta?
Open Policy Agent tiene implementaciones para muchos entornos, como el caso que nos ocupa, Kubernetes, a través de Gatekeeper. En este ejemplo crearemos normas que indicarán cómo se deben crear los recursos, y qué acciones pueden o no hacerse, y validarán estas acciones contra las políticas especificadas antes de aplicar los recursos. Por ejemplo, no permitir crear pods con permisos privilegiados en el namespace de producción, o no poder crear un deployment sin resources y limits declarados.
¿Debo aprender todo un nuevo lenguaje?
En parte. Estas políticas están creadas en un lenguaje llamado REGO que está pensado para ser más legible por las personas. Además, al estar abstraído y estandarizado en la industria, ya existen muchos ejemplos de acciones frecuentes, como repositorios de reglas REGO de RedHat. Es posible que para cumplir la mayoría de requisitos de seguridad estándar ni siquiera necesites escribir una regla REGO.
¿No suena a algo denso de implementar?
Ahí es donde entramos nosotros! El equipo de Geko tiene amplia experiencia implementando tecnologías punteras a entornos cloud-native y Kubernetes. Si quieres que alguien más experimentado con la plataforma te ayude a cumplir los estándares de seguridad de hoy en día, sentémonos a charlar y veamos cómo podemos facilitarte esta transición.
