Una guía para navegar por la sobrecarga de políticas en los sistemas distribuidos actuales

Te reto a asistir a KubeCon y asistir a una sesión sobre “políticas”. Cuando llegues allí, no te sorprendas si te preguntas: "¿De qué tipo de política se trata realmente?".

En la reciente KubeCon en Salt Lake City, me encontré corriendo entre sesiones en las que la “política” ocupaba un lugar destacado en los títulos. Pero para cada hablante, la palabra significaba algo completamente diferente.

Como alguien centrado en políticas de red basadas en etiquetas, a menudo tenía que preguntar a los presentadores de antemano: "¿Esta sesión sobre políticas trata sobre políticas de red, controladores de admisión o cumplimiento?".

Estos intercambios revelan un problema creciente en los ecosistemas informáticos distribuidos y nativos de la nube de hoy en día. El término "política" se usa tan ampliamente que es prácticamente una abstracción en sí mismo.

Para desenredar esto, analizaré más de cerca los ocho tipos diferentes de políticas que se discuten con frecuencia bajo este término amplio y por qué son cruciales para comprender la infraestructura, la seguridad y la automatización en los sistemas distribuidos.

1. Políticas de red

Las políticas de red son importantes para controlar y gestionar cómo los sistemas de una red se comunican entre sí, especialmente en entornos como Kubernetes.

La mayoría de las políticas de red emplean un enfoque de lista blanca. Esto significa que las conexiones están bloqueadas de forma predeterminada a menos que la política las permita específicamente. Estas políticas pueden emplear reglas basadas en direcciones IP o etiquetas para decidir qué recursos pueden comunicar.

A medida que los microservicios y las aplicaciones basadas en contenedores se vuelven más comunes, es aún más importante controlar cuidadosamente cómo se comunican los servicios y mantenerlos aislados cuando sea necesario.

Por ejemplo, las políticas de red de Kubernetes son altamente personalizables. Pueden establecer reglas de tráfico para el tráfico interno (este-oeste) y el tráfico externo (norte-sur). Esta flexibilidad los convierte en herramientas poderosas para mantener los sistemas seguros, pero también los hace más complicados de construir y gestionar.

2. Políticas del controlador de admisión

Los controladores de admisión son políticas especializadas en Kubernetes. Evalúan las solicitudes de API para decidir si deben permitir o cambiar. Son esencialmente guardianes. Aplican ciertos estándares o prácticas de seguridad en todo el clúster antes de que una solicitud de API pueda avanzar.

Por ejemplo, las directivas del controlador de admisión pueden:

• Aplicar automáticamente los límites de recursos

• Agregar etiquetas a las implementaciones

• Bloquear el uso de configuraciones no seguras

Este tipo de directivas pueden interceptar y mutar solicitudes. Esto los hace cruciales para mantener una seguridad constante dentro de los clústeres. Pero solo abordan las políticas en el ciclo de vida de las llamadas a la API de Kubernetes.  

3. Políticas de OPA y Kyverno

¿Son las políticas de OPA y Kyverno simplemente controladores de admisión, o son algo más?

Open Policy Agent (OPA) y Kyverno ofrecen más que los controladores de admisión tradicionales. Si bien a menudo trabajan como controladores de admisión en Kubernetes, introducen un lenguaje de políticas más flexible y completo. Esto permite a las organizaciones definir y aplicar reglas complejas en múltiples sistemas.

• OPA (Open Policy Agent) es un motor de políticas versátil que se puede emplear en todos los entornos. Emplea un lenguaje llamado Rego que puede manejar requisitos de políticas complejas. Además de Kubernetes, OPA puede gestionar políticas para canalizaciones de CI/CD, microservicios e incluso recursos en la nube.

• Kyverno es un motor de políticas creado específicamente para Kubernetes. Es una forma más sencilla de definir directivas en YAML. Mucha gente lo prefiere para configurar Kubernetes. Funciona bien con objetos nativos de Kubernetes, lo que facilita la creación y aplicación de políticas.

Estas herramientas pueden controlar lo que obtiene acceso a un sistema, pero pueden hacer mucho más en una variedad de aplicaciones y sistemas. Pueden manejar:

• Gestión del ciclo de vida

• Validación

• Comprobaciones de cumplimiento personalizadas

4. Cuotas de recursos y políticas de límite

Las políticas de administración de recursos ayudan a controlar la cantidad de CPU, memoria y almacenamiento que puede usar un clúster de Kubernetes. Estas directivas son importantes en entornos compartidos porque evitan que una aplicación o un usuario usen demasiados recursos.

• Las cuotas generalmente se establecen para cada espacio de nombres. Limitan la cantidad total de recursos que puede usar un espacio de nombres para que ningún espacio de nombres se haga cargo demasiado.

• Los límites definen el número más pequeño y más grande de recursos que puede usar un contenedor o pod. Esto garantiza que ninguna carga de trabajo use demasiados recursos y cause problemas al resto del sistema.

Con estas directivas, los administradores pueden equilibrar los recursos, lo que es especialmente importante en entornos con muchos usuarios o aplicaciones que se escalan dinámicamente. Si bien estas políticas ayudan a mantener estable el sistema, también complican las cosas, ya que interactúan con otras capas de políticas como la automatización y los controles de admisión.

Estas políticas ayudan a los administradores a equilibrar los recursos, lo cual es especialmente importante en sistemas con muchos usuarios o aplicaciones que se escalan dinámicamente. Sin embargo, gestionar estas políticas puede ser un desafío. A menudo se superponen con otras políticas como la automatización y los controles de admisión.

5. Políticas de seguridad de pods (PSP)

Las políticas de seguridad de pods (PSP) en Kubernetes establecen configuraciones de seguridad en el nivel de pod. Esto incluye evitar que los contenedores se ejecuten como root o que requieran ciertas capacidades de Linux.  

Pero los PSP se están eliminando gradualmente en Kubernetes. Están siendo reemplazados por opciones más nuevas como Pod Security Standards (PSS) y herramientas externas como OPA y Kyverno.

Los PSP se diseñaron para agregar configuraciones de seguridad granulares que evitan que las cargas de trabajo se ejecuten con configuraciones demasiado permisivas. Si bien son útiles, gestionar PSP junto con otras políticas puede resultar confuso. Las herramientas más nuevas ofrecen formas más flexibles de hacer cumplir la seguridad, a menudo bajo el término general "políticas de seguridad".

6. Políticas de malla de servicios

En entornos de microservicios, las mallas de servicios como Istio o Linkerd agregan otra capa de políticas que protege y monitorea la comunicación entre servicios. Estas políticas a menudo:  

• Autenticar y autorizar el tráfico: Las mallas de servicio usan mTLS (TLS mutuo) para cifrar la comunicación entre servicios. También le permiten establecer políticas para que los servicios puedan comunicar entre sí, agregando otra capa de control de acceso.

• Gestionar el tráfico: Las políticas de malla de servicios controlan el enrutamiento, el equilibrio de carga y la conmutación por error. Esto facilita la realización de cosas como pruebas A/B, versiones Canary o enrutar el tráfico a diferentes versiones de servicio.  

A diferencia de las políticas de red, las políticas de malla de servicios funcionan en la capa de aplicación, lo que afecta la forma en que interactúan los servicios. Estas políticas son cruciales para gestionar el tráfico de servicio a servicio. Pero a veces pueden ser confusos porque se superponen con las políticas de red.

7. Políticas de cumplimiento

Las políticas de cumplimiento pueden cubrir la gestión de datos, el acceso y los estándares operativos para garantizar que los sistemas cumplan con los requisitos de cumplimiento legales o internos, como GDPR, HIPAA o SOC 2. Estas políticas pueden desempeñar un papel importante en muchas partes de un sistema, afectando la seguridad, el registro y el almacenamiento de datos.

Por ejemplo, una directiva de cumplimiento puede requerir que los datos solo se almacenen en ubicaciones específicas (residencia de datos) o que los registros de auditoría se conserven durante un periodo de tiempo determinado. En Kubernetes, herramientas como OPA y Kyverno se emplean a menudo para hacer cumplir estas políticas mediante la supervisión y auditoría continua de los sistemas en tiempo real para cerciorar de que cumplen los estándares.

Las políticas de cumplimiento son especialmente importantes en industrias con regulaciones estrictas, como la atención médica y las finanzas. Debido a que funcionan en muchas partes de un sistema y, a menudo, se superponen con las políticas de seguridad, gestionarlas puede volver complejo. A pesar de esto, son cruciales para garantizar que los sistemas se mantengan seguros, organizados y compatibles.

8. Políticas de automatización y ciclo de vida

Las políticas de automatización controlan cuándo y cómo se crean, actualizan o eliminan los recursos de infraestructura. Estas directivas son una parte importante de la infraestructura como código (IaC), donde las configuraciones de recursos se escriben como código y se gestionan a través de canalizaciones de CI/CD.

Por ejemplo, las políticas de automatización pueden manejar tareas como escalar automáticamente los recursos, limpiar los que no se usan o gestionar los pasos del ciclo de vida de una implementación. También pueden integrar con canalizaciones de CI/CD para desencadenar compilaciones, ejecutar pruebas y gestionar implementaciones. Esto crea entornos autogestionados que pueden ajustar a los cambios de carga de trabajo en tiempo real.

Las políticas de automatización pueden simplificar la administración de recursos y garantizar las mejores prácticas en entornos nativos de la nube. Pero interactúan estrechamente con otras políticas, como las de gestión de recursos y control de admisión, que pueden agregar complejidad.

¿Sigues siguiendo? La superposición de "política" continúa...

Si aún no estás abrumado, aquí está el giro. Muchas organizaciones ahora tienen políticas para políticas.  

Estos se denominan "metapolíticas". Actúan como barandillas, estableciendo reglas sobre quién puede hacer, gestionar o aplicar otras políticas.  

Por ejemplo, una metapolítica puede decidir qué equipos pueden crear políticas de red específicas o quién está autorizado para crear políticas de control de admisión. Estas políticas a menudo se basan en el control de acceso basado en roles (RBAC).

En los grandes sistemas, las políticas de RBAC para las políticas son esenciales. Se cercioran de que solo administradores o equipos específicos puedan realizar cambios en las directivas. Al aplicar estrictos controles RBAC, estas "políticas para políticas" garantizan que otras políticas no se extralimiten ni interfieran con la infraestructura crítica.

Reflexiones finales: Una hoja de ruta a través de la sobrecarga de políticas

A medida que crecen los entornos distribuidos y nativos de la nube, la idea de "política" seguirá cambiando. Se volverán más complicados, especializados y, a veces, incluso contradictorios.

Para evitar la sobrecarga de directivas, es importante usar convenciones de nomenclatura claras, crear documentación que defina cada tipo de directiva y hacer un buen uso de las herramientas de directivas.

Y la próxima vez que estés en una conferencia de tecnología y escuches "política", tómate un momento para preguntar: "¿Cuál? " Podría salvarte de mucha confusión, ¡o incluso de un sprint cruzado!

Póngase en contacto con nosotros hoy mismo para saber cómo Illumio puede simplificar sus políticas de seguridad de red en entornos de nube, endpoints y centros de datos.