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.

Kyverno offers a robust, declarative approach to enforcing security and compliance standards within Kubernetes clusters by allowing users to define and enforce custom policies. For an in-depth look at Kyverno’s functionality, including core concepts and benefits, see my detailed article here. In this guide, we’ll focus on extending Kyverno policies, providing a structured walkthrough of its data model, and illustrating use cases to make the most of Kyverno in a Kubernetes environment.

Understanding the Kyverno Policy Data Model

Kyverno policies consist of several components that define how the policy should behave, which resources it should affect, and the specific rules that apply. Let’s dive into the main parts of the Kyverno policy model:

1. Policy Definition: This is the root configuration where you define the policy’s metadata, including name, type, and scope. Policies can be created at the namespace level for specific areas or as cluster-wide rules to enforce uniform standards across the entire Kubernetes cluster.
   
2. Rules: Policies are made up of rules that dictate what conditions Kyverno should enforce. Each rule can include logic for validation, mutation, or generation based on your needs.
   
3. Match and Exclude Blocks: These sections allow fine-grained control over which resources the policy applies to. You can specify resources by their kinds (e.g., Pods, Deployments), namespaces, labels, and even specific names. This flexibility is crucial for creating targeted policies that impact only the resources you want to manage.
   
   1. Match block: Defines the conditions under which the rule applies to specific resources.
   2. Exclude block: Used to explicitly omit resources that match certain conditions, ensuring that unaffected resources are not inadvertently included.
      
4. Validation, Mutation, and Generation Actions: Each rule can take different types of actions:
   
   1. Validation: Ensures resources meet specific criteria and blocks deployment if they don’t.
   2. Mutation: Adjusts resource configurations to align with predefined standards, which is useful for auto-remediation.
   3. Generation: Creates or manages additional resources based on existing resource configurations.
      

Example: Restricting Container Image Sources to Docker Hub

A common security requirement is to limit container images to trusted registries. The example below demonstrates a policy that only permits images from 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: "Only Docker Hub images are allowed."
        pattern:
          spec:
            containers:
              - image: "docker.io/*"

This policy targets all Pod resources in the cluster and enforces a validation rule that restricts the image source to docker.io. If a Pod uses an image outside Docker Hub, Kyverno denies its deployment, reinforcing secure sourcing practices.

Practical Use-Cases for Kyverno Policies

Kyverno policies can handle a variety of Kubernetes management tasks through validation, mutation, and generation. Let’s explore examples for each type to illustrate Kyverno’s versatility:

1. Validation Policies

Validation policies in Kyverno ensure that resources comply with specific configurations or security standards, stopping any non-compliant resources from deploying.

Use-Case: Enforcing Resource Limits for Containers

This example prevents deployments that lack resource limits, ensuring all Pods specify CPU and memory constraints.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-resource-limits
spec:
  rules:
    - name: require-resource-limits
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Resource limits (CPU and memory) are required for all containers."
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    cpu: "?*"
                    memory: "?*"

By enforcing resource limits, this policy helps prevent resource contention in the cluster, fostering stable and predictable performance.

2. Mutation Policies

Mutation policies allow Kyverno to automatically adjust configurations in resources to meet compliance requirements. This approach is beneficial for consistent configurations without manual intervention.

Use-Case: Adding Default Labels to Pods

This policy adds a default label, environment: production, to all new Pods that lack this label, ensuring that resources align with organization-wide labeling standards.

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"

This mutation policy is an example of how Kyverno can standardize resource configurations at scale by dynamically adding missing information, reducing human error and ensuring labeling consistency.

3. Generation Policies

Generation policies in Kyverno are used to create or update related resources, enhancing Kubernetes automation by responding to specific configurations or needs in real-time.

Use-Case: Automatically Creating a ConfigMap for Each New Namespace

This example policy generates a ConfigMap in every new namespace, setting default configuration values for all resources in that namespace.

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"

This generation policy is triggered whenever a new namespace is created, automatically provisioning a ConfigMap with default settings. This approach is especially useful in multi-tenant environments, ensuring new namespaces have essential configurations in place.

Conclusion

Extending Kyverno policies enables Kubernetes administrators to establish and enforce tailored security and operational practices within their clusters. By leveraging Kyverno’s capabilities in validation, mutation, and generation, you can automate compliance, streamline operations, and reinforce security standards seamlessly.