Policies

Kyverno ofrece un enfoque robusto y declarativo para hacer cumplir los estándares de seguridad y cumplimiento dentro de los clústeres de Kubernetes al permitir a los usuarios definir y hacer cumplir políticas personalizadas. Para una mirada en profundidad a la funcionalidad de Kyverno, incluidos los conceptos y beneficios principales, vea mi artículo detallado aquí. En esta guía, nos centraremos en extender las políticas de Kyverno, proporcionando un recorrido estructurado de su modelo de datos e ilustrando casos de uso para aprovechar al máximo Kyverno en un entorno de Kubernetes.

Comprendiendo el Modelo de Datos de Políticas de Kyverno

Las políticas de Kyverno consisten en varios componentes que definen cómo debe comportarse la política, qué recursos debe afectar y las reglas específicas que se aplican. Vamos a profundizar en las partes principales del modelo de políticas de Kyverno:

1. Definición de Política: Esta es la configuración raíz donde defines los metadatos de la política, incluyendo nombre, tipo y alcance. Las políticas pueden crearse a nivel de espacio de nombres para áreas específicas o como reglas a nivel de clúster para hacer cumplir estándares uniformes en todo el clúster de Kubernetes.
   
2. Reglas: Las políticas están compuestas por reglas que dictan qué condiciones debe hacer cumplir Kyverno. Cada regla puede incluir lógica para validación, mutación o generación según tus necesidades.
   
3. Bloques de Coincidencia y Exclusión: Estas secciones permiten un control detallado sobre qué recursos se aplica la política. Puedes especificar recursos por sus tipos (por ejemplo, Pods, Despliegues), espacios de nombres, etiquetas e incluso nombres específicos. Esta flexibilidad es crucial para crear políticas dirigidas que impacten solo en los recursos que deseas gestionar.
   
   1. Bloque de coincidencia: Define las condiciones bajo las cuales la regla se aplica a recursos específicos.
   2. Bloque de exclusión: Se utiliza para omitir explícitamente recursos que coinciden con ciertas condiciones, asegurando que los recursos no afectados no se incluyan inadvertidamente.
      
4. Acciones de Validación, Mutación y Generación: Cada regla puede tomar diferentes tipos de acciones:
   
   1. Validación: Asegura que los recursos cumplan con criterios específicos y bloquea el despliegue si no lo hacen.
   2. Mutación: Ajusta las configuraciones de recursos para alinearse con estándares predefinidos, lo cual es útil para la autorremediación.
   3. Generación: Crea o gestiona recursos adicionales basados en configuraciones de recursos existentes.
      

Ejemplo: Restringir Fuentes de Imágenes de Contenedores a Docker Hub

Un requisito común de seguridad es limitar las imágenes de contenedores a registros de confianza. El ejemplo a continuación demuestra una política que solo permite imágenes de Docker Hub.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-dockerhub-images
spec:
  rules:
    - name: only-dockerhub-images
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Solo se permiten imágenes de Docker Hub."
        pattern:
          spec:
            containers:
              - image: "docker.io/*"

Esta política apunta a todos los recursos Pod en el clúster y hace cumplir una regla de validación que restringe la fuente de la imagen a docker.io. Si un Pod utiliza una imagen fuera de Docker Hub, Kyverno niega su despliegue, reforzando prácticas de aprovisionamiento seguro.

Casos de Uso Prácticos para Políticas de Kyverno

Las políticas de Kyverno pueden manejar una variedad de tareas de gestión de Kubernetes a través de validación, mutación y generación. Vamos a explorar ejemplos para cada tipo para ilustrar la versatilidad de Kyverno:

1. Políticas de Validación

Las políticas de validación en Kyverno aseguran que los recursos cumplan con configuraciones específicas o estándares de seguridad, deteniendo cualquier recurso no conforme de desplegarse.

Caso de Uso: Hacer Cumplir Límites de Recursos para Contenedores

Este ejemplo previene despliegues que carecen de límites de recursos, asegurando que todos los Pods especifiquen restricciones de CPU y memoria.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-resource-limits
spec:
  rules:
    - name: require-resource-limits
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Se requieren límites de recursos (CPU y memoria) para todos los contenedores."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

Al hacer cumplir los límites de recursos, esta política ayuda a prevenir la contención de recursos en el clúster, fomentando un rendimiento estable y predecible.

2. Políticas de Mutación

Las políticas de mutación permiten a Kyverno ajustar automáticamente configuraciones en recursos para cumplir con requisitos de cumplimiento. Este enfoque es beneficioso para configuraciones consistentes sin intervención manual.

Caso de Uso: Agregar Etiquetas Predeterminadas a Pods

Esta política agrega una etiqueta predeterminada, environment: production, a todos los nuevos Pods que carecen de esta etiqueta, asegurando que los recursos se alineen con los estándares de etiquetado de toda la organización.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-label
spec:
  rules:
    - name: add-environment-label
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              environment: "production"

Esta política de mutación es un ejemplo de cómo Kyverno puede estandarizar configuraciones de recursos a escala al agregar dinámicamente información faltante, reduciendo el error humano y asegurando la consistencia en el etiquetado.

3. Políticas de Generación

Las políticas de generación en Kyverno se utilizan para crear o actualizar recursos relacionados, mejorando la automatización de Kubernetes al responder a configuraciones o necesidades específicas en tiempo real.

Caso de Uso: Creación Automática de un ConfigMap para Cada Nuevo Espacio de Nombres

Este ejemplo de política genera un ConfigMap en cada nuevo espacio de nombres, estableciendo valores de configuración predeterminados para todos los recursos en ese espacio de nombres.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-configmap
spec:
  rules:
    - name: add-default-configmap
      match:
        resources:
          kinds:
            - Namespace
      generate:
        kind: ConfigMap
        name: default-config
        namespace: "{{request.object.metadata.name}}"
        data:
          default-key: "default-value"

Esta política de generación se activa cada vez que se crea un nuevo espacio de nombres, aprovisionando automáticamente un ConfigMap con configuraciones predeterminadas. Este enfoque es especialmente útil en entornos multi-tenant, asegurando que los nuevos espacios de nombres tengan configuraciones esenciales en su lugar.

Conclusión

Extender las políticas de Kyverno permite a los administradores de Kubernetes establecer y hacer cumplir prácticas de seguridad y operativas personalizadas dentro de sus clústeres. Al aprovechar las capacidades de Kyverno en validación, mutación y generación, puedes automatizar el cumplimiento, agilizar las operaciones y reforzar los estándares de seguridad sin problemas.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.