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

Te reto a que asistas a KubeCon e vayas a una sesión sobre “política”. Cuando llegues ahí, no te sorprendas si te quedas preguntándote: “¿De qué tipo de política se trata realmente?”

En el reciente KubeCon en Salt Lake City, me encontré a mí misma esprintando entre sesiones donde “política” era prominente en los títulos. Pero para cada orador, la palabra significaba algo completamente diferente.

Como alguien enfocado en políticas de red basadas en etiquetas, a menudo tenía que captar oradores de antemano para preguntar: “¿Esta sesión de políticas es sobre políticas de red, controladores de admisión o cumplimiento de normas?”

Estos intercambios revelan un problema creciente en los ecosistemas de computación distribuidos y nativos de la nube actuales. El término “política” se usa de manera tan amplia que prácticamente es una abstracción en sí mismo.

Para desenredar esto, voy a echar un vistazo más de cerca a los ocho tipos diferentes de políticas que se discuten con frecuencia bajo este amplio término 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 administrar cómo los sistemas de una red se comunican entre sí, especialmente en entornos como Kubernetes.

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

Como microservicios y 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 administrar.

2. Políticas de 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 ser permitidas o cambiadas. Son esencialmente guardianes. Hacen cumplir ciertos estándares o prácticas de seguridad en todo el cluster antes de que una solicitud de API pueda avanzar.

Por ejemplo, las políticas del controlador de admisión pueden:

• Hacer cumplir automáticamente los límites de recursos

• Agregar etiquetas a las implementaciones

• Bloquear el uso de configuraciones inseguras

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

3. Políticas de OPA y Kyverno

¿Las políticas OPA y Kyverno son 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 e integral. Esto permite a las organizaciones definir y aplicar reglas complejas en múltiples sistemas.

• OPA (Agente de Políticas Abiertas) es un motor de políticas versátil que se puede utilizar en todos los entornos. Utiliza un lenguaje llamado Rego que puede manejar requerimientos complejos de políticas. Además de Kubernetes, OPA puede administrar 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 políticas 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 administrar:

• Administración del ciclo de vida

• Validación

• Comprobaciones de cumplimiento de normas personalizadas

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

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

• Cuotas generalmente se establecen para cada espacio de nombres. Limitan la cantidad total de recursos que puede usar un espacio de nombres, por lo que ningún espacio de nombres individual toma demasiado control.

• Límites definir el menor y mayor número de recursos que un contenedor o pod puede usar. Esto asegura que ninguna carga de trabajo individual utilice demasiados recursos y cause problemas para el resto del sistema.

Con estas políticas, los administradores pueden equilibrar los recursos, lo cual es especialmente importante en entornos con muchos usuarios o aplicaciones que escalan dinámicamente. Si bien estas políticas ayudan a mantener el sistema estable, también complican las cosas a medida 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 escalan dinámicamente. Sin embargo, administrar 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 del pod (PSP)

Políticas de seguridad del pod (PSP) en Kubernetes establecer configuraciones de seguridad a nivel de pod. Esto incluye impedir que los contenedores se ejecuten como root o que requieran ciertas capacidades de Linux.

Pero los PSP están siendo eliminados 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, administrar 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 servicio

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

• Autenticar y autorizar el tráfico: Las mallas de servicio utilizan MTLs (TLS mutuo) para cifrar la comunicación entre servicios. También le permiten establecer políticas para las cuales los servicios pueden comunicarse entre sí, agregando otra capa de control de acceso.

• Administrar el tráfico: Las políticas de malla de servicio controlan el enrutamiento, el balanceo de carga y el failover. Esto hace que sea más fácil hacer cosas como pruebas A/B, lanzamientos canarios 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 administrar el tráfico de servicio a servicio. Pero a veces pueden ser confusas porque se superponen con las políticas de red.

7. Políticas de cumplimiento

Políticas de cumplimiento puede cubrir la administración de datos, el acceso y los estándares operativos para garantizar que los sistemas cumplan con los requisitos legales o internos de cumplimiento, 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 política de cumplimiento de normas puede requerir que los datos solo se almacenen en ubicaciones específicas (residencia de datos) o que los registros de auditoría se mantengan durante un cierto período de tiempo. En Kubernetes, herramientas como OPA y Kyverno se utilizan a menudo para hacer cumplir estas políticas al monitorear y auditar continuamente los sistemas en tiempo real para asegurarse de que cumplen con los estándares.

Las políticas de cumplimiento de normas son especialmente importantes en industrias con regulaciones estrictas, como salud y finanzas. Debido a que funcionan en muchas partes de un sistema y, a menudo, se superponen con las políticas de seguridad, administrarlas puede volverse compleja. A pesar de esto, son cruciales para garantizar que los sistemas se mantengan seguros, organizados y cumplan con las normas.

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 políticas son una parte importante de Infrastructure as Code (IaC) donde las configuraciones de recursos se escriben como código y se administran 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 utilizan o administrar los pasos en el ciclo de vida de una implementación. También pueden integrarse con canalizaciones de CI/CD para activar compilaciones, ejecutar pruebas y administrar implementaciones. Esto crea entornos de autoadministración que pueden ajustarse 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 administración de recursos y control de admisión, lo que puede agregar complejidad.

¿Sigues siguiendo? Continúa el solapamiento de “política”...

Si aún no estás abrumado, aquí está el giro. En la actualidad, muchas organizaciones tienen políticas para las políticas.

Éstas se llaman “meta-políticas”. Actúan como barandillas, estableciendo reglas para quién puede hacer, administrar o aplicar otras políticas.

Por ejemplo, una metapolítica podría 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 sistemas grandes, Políticas de RBAC ya que las políticas son esenciales. Se aseguran de que solo los administradores o equipos específicos puedan realizar cambios en las políticas. Al hacer cumplir estrictos controles RBAC, estas “políticas para políticas” aseguran que otras políticas no se excedan 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” continuará cambiando. Se volverán más complicados, especializados, y a veces hasta contradictorios.

Para evitar la sobrecarga de políticas, es importante utilizar convenciones de nomenclatura claras, crear documentación que defina cada tipo de política y hacer un buen uso de las herramientas de políticas.

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

Ponte en contacto con nosotros hoy para saber cómo Illumio puede simplificar sus políticas de seguridad de red en entornos de nube, endpoint y data center.