CEL es un lenguaje de expresiones ligero creado por Google y diseñado para validaciones, evaluaciones lógicas rápidas y portabilidad. A diferencia de un lenguaje de programación completo, CEL es restringido y seguro: no permite ejecución de código arbitrario, lo que lo hace ideal para las APIs de Kubernetes.

Hoy os cuento cómo puedes utilizarlo para configurar un Validating Admission Policy o Mutating Admission Policy.

Validating Admission Policy y Mutating Admission Policy funcionan de forma declarativa y utilizan CEL para definir sus reglas, sin necesidad de desplegar webhooks ni aplicaciones externas.

Cualquier política se ejecuta en el control-plane de nuestro cluster y podemos llegar a bloquear el propio control-plane dependiendo de las reglas definidas.

Cuando solicitamos la creación de un objeto en Kubernetes, el flujo funciona de la siguiente manera:

Cuando un cliente envía una petición al cluster, el API Server primero verifica la identidad y permisos. Si la autenticación es correcta, la petición pasa por el Mutating Admission, que puede modificar el objeto antes de continuar, y después por el Validating Admission, que evalúa la expresión CEL y toma la decisión final. Si la expresión se cumple, el objeto se persiste en etcd; si no, la petición se rechaza con un 403 Forbidden y el mensaje definido en la policy.

Validating Admission Policy

Este tipo de políticas nos van a permitir validar cualquier petición realizada a nuestro cluster Kubernetes, no solo por nosotros, también se incluyen cualquier llamada que pueda hacer el propio cluster o herramientas GitOps como Argo CD o Flux CD.

Para desplegar una politica y hacer uso de ella debemos crear dos objetos.

ValidatingAdmissionPolicy

Definimos la política.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-memory-requests
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: ["apps"]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["deployments"]
  validations:
    - expression: >
        object.spec.template.spec.containers.all(c,
          has(c.resources) &&
          has(c.resources.requests) &&
          has(c.resources.requests.memory)
        )
      message: "Todos los contenedores deben tener requests.memory definido"

failurePolicy

Define qué hacer si hay un error en la política (por ejemplo, error de sintaxis CEL, error en tiempo de ejecución o configuración inválida). Valores permitidos:

• Fail (valor por defecto): rechaza la petición

• Ignore: continúa como si la política no existiera

matchConstraints

Especifica a qué recursos se aplica esta política. Es el filtro principal. Dentro de él, lo más usado es resourceRules: una lista de reglas que definen:

• apiGroups: grupo de la API (ej. [“apps”] o [““] para core)

• apiVersions: versiones (ej. [”v1”])

• operations: operaciones a interceptar: CREATE, UPDATE, DELETE, *

• resources: tipo de recurso (ej. [”deployments”], [”pods”]). También puedes usar namespaceSelector y objectSelector para filtrar por labels

validations

Aquí va la lógica real de validación usando CEL (Common Expression Language). Cada elemento tiene:

• expression: la expresión CEL que debe evaluarse a true. Si es false, se considera fallo de validación. Ejemplo: object.spec.replicas <= 5

• message: mensaje estático que se devuelve al usuario si falla

• messageExpression: (opcional) expresión CEL que genera un mensaje dinámico

• reason: código de razón HTTP (Invalid, Forbidden, etc.)

Otras propiedades útiles

• matchConditions: filtro adicional con CEL (se evalúa antes de las validaciones). Muy útil para excluir system namespaces o recursos internos.

• auditAnnotations: genera anotaciones en los eventos de auditoría cuando la validación pasa.

• variables: define variables reutilizables en CEL para no repetir expresiones complejas.

• paramKind: si quieres que la política sea parametrizable (ej. el límite de réplicas venga de un CRD).

Un ejemplo más completo con todas las propiedades disponibles:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: enforce-production-deployment-standards.example.com
spec:
  # 1. Qué hacer si hay un error en la política (sintaxis CEL, runtime error, etc.)
  failurePolicy: Fail

  # 2. Filtros iniciales: a qué recursos se aplica la política
  matchConstraints:
    resourceRules:
      - apiGroups:   ["apps"]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["deployments"]

  # 3. Condiciones adicionales con CEL (se evalúan ANTES de las validaciones)
  matchConditions:
    - name: "only-production-namespaces"
      expression: "request.namespace.startsWith('prod-') || request.namespace == 'production'"
    - name: "exclude-system-resources"
      expression: "!(request.resource.group == 'coordination.k8s.io' && request.resource.resource == 'leases')"

  # 4. Parámetros (hace la política reutilizable y configurable)
  paramKind:
    apiVersion: "rules.example.com/v1"
    kind: "DeploymentPolicyConfig"
  # El parámetro se referenciará después en el Binding con paramRef

  # 5. Variables reutilizables en CEL (mejora la legibilidad y evita duplicación)
  variables:
    - name: "hasReadOnlyRootFS"
      expression: "object.spec.template.spec.containers.all(c, has(c.securityContext) && has(c.securityContext.readOnlyRootFilesystem) && c.securityContext.readOnlyRootFilesystem == true)"
    - name: "approvedRegistries"
      expression: "params.allowedRegistries.split(',').map(r, r.trim())"

  # 6. Las validaciones reales (lógica principal)
  validations:
    - name: "minimum-replicas"
      expression: "object.spec.replicas >= params.minReplicas"
      messageExpression: "'Deployment debe tener al menos ' + string(params.minReplicas) + ' réplicas en producción.'"
      reason: Invalid

    - name: "readonly-root-filesystem"
      expression: "variables.hasReadOnlyRootFS"
      message: "Todos los contenedores deben tener securityContext.readOnlyRootFilesystem = true por seguridad"
      reason: Forbidden

    - name: "approved-image-registries"
      expression: >
        object.spec.template.spec.containers.all(c,
          variables.approvedRegistries.exists(r, c.image.startsWith(r))
        )
      message: "Todas las imágenes deben provenir de registros aprobados"
      reason: Forbidden

  # 7. Anotaciones para auditoría (útil para compliance y trazabilidad)
  auditAnnotations:
    - key: "policy.enforced"
      valueExpression: "'true'"
    - key: "policy.minReplicas"
      valueExpression: "string(params.minReplicas)"
    - key: "validated-by"
      valueExpression: "'validating-admission-policy'"

ValidatingAdmissionPolicyBinding

Enlazamos la política creada con uno o varios objetos de Kubernetes, en este caso queremos aplicarla únicamente a los recursos que se ejecutan en un namespace por la label env: production.

# Enlazar la política a un namespace (o a todo el cluster)
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-memory-requests-binding
spec:
  policyName: require-memory-requests
  validationActions: [Deny]
  matchResources:
    namespaceSelector:
      matchLabels:
        env: production

policyName

Nombre exacto de la ValidatingAdmissionPolicy que se va a aplicar.

validationActions

Cómo se aplica el fallo de validación. No puedes combinar Deny + Warn.

• Deny: rechaza la petición

• Warn: avisa pero permite (emite un warning visible con kubectl)

• Audit: solo registra en el audit log

matchResources

Igual que en la política, pero aquí puedes afinar aún más el alcance (por ejemplo, aplicar solo a ciertos namespaces con namespaceSelector). Si lo omites, se aplica a todos los recursos que coincidan con los criterios de la política.

Mutating Admission Policy

Esta funcionalidad se encuentra actualmente en beta y está previsto que pase a GA en Kubernetes 1.36.

Este tipo de políticas nos van a permitir modificar el contenido de un objeto de Kubernetes (ej. añadir un label).

MutatingAdmissionPolicy

Definimos la política.

# 1. Definir la política mutante
apiVersion: admissionregistration.k8s.io/v1alpha1
kind: MutatingAdmissionPolicy
metadata:
  name: add-managed-by-label
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{
            metadata: ObjectMeta{
              labels: {"managed-by": "platform-team"}
            }
          }

failurePolicy

Define el comportamiento cuando ocurre un error en la política (error de sintaxis CEL, error en tiempo de ejecución, etc.). Valores permitidos:

• Fail (por defecto): rechaza la creación/actualización del objeto

• Ignore: continúa la operación ignorando esta política

matchConstraints

Es el filtro principal. Define a qué recursos y operaciones se aplica esta política de mutación.

• apiGroups: grupo de la API (ej. [“apps”] o [““] para core)

• apiVersions: versiones (ej. [”v1”])

• operations: operaciones a interceptar: CREATE, UPDATE, DELETE, *

• resources: tipo de recurso (ej. [”deployments”], [”pods”]). También puedes usar namespaceSelector y objectSelector para filtrar por labels

mutations

Es una lista de mutaciones que se aplicarán al objeto. Cada elemento de la lista representa una mutación independiente.

• patchType: Indica el tipo de parche que se va a aplicar. Dos valores posibles:

  • ApplyConfiguration: Usa un estilo declarativo similar al Server-Side Apply. Es más seguro y legible

  • JSONPatch: Permite usar operaciones clásicas de JSON Patch (add, remove, replace, etc.)

• applyConfiguration.expression (cuando patchType: ApplyConfiguration) Expresión CEL que devuelve un objeto con la configuración que se quiere fusionar (merge) en el objeto original. En el ejemplo:

Object{
  metadata: ObjectMeta{
    labels: {"managed-by": "platform-team"}
  }
}

Otras propiedades importantes

• reinvocationPolicy Controla si la política debe volver a ejecutarse después de que otras mutaciones hayan modificado el objeto. Valores:

  • IfNeeded: Se ejecuta en caso de que el objeto haya sido modificado por otra política

  • Never (valor por defecto): la política no se ejecuta si el objeto ya ha sido modificado por otra política

• matchConditions (lista) Filtros adicionales escritos en CEL que se evalúan antes de aplicar las mutaciones. Muy útil para añadir condiciones complejas, por ejemplo:

  • No aplicar la mutación si el Pod ya tiene cierta etiqueta

  • Excluir Pods del sistema (kube-system, kube-node-lease, etc.

Un ejemplo más completo con todas las propiedades disponibles:

apiVersion: admissionregistration.k8s.io/v1beta1 
kind: MutatingAdmissionPolicy
metadata:
  name: add-platform-labels
spec:
  failurePolicy: Ignore
  reinvocationPolicy: IfNeeded

  # 1. matchConstraints → ¿A qué recursos se aplica?
  matchConstraints:
    resourceRules:
      - apiGroups:   [""]
        apiVersions: ["v1"]
        operations:  ["CREATE"]
        resources:   ["pods"]

  # 2. matchConditions → Condiciones adicionales con CEL (opcional pero muy útil)
  matchConditions:
    - name: "skip-system-namespaces"
      expression: "!(request.namespace in ['kube-system', 'kube-node-lease', 'kube-public'])"

  # 3. mutations → Aquí definimos los cambios
  mutations:
    - patchType: ApplyConfiguration
      applyConfiguration:
        expression: >
          Object{
            metadata: ObjectMeta{
              labels: {
                "managed-by": "platform-team",
                "environment": "production"
              },
              annotations: {
                "mutated-by": "mutating-admission-policy",
                "mutation-timestamp": string(request.time)
              }
            }
          }

MutatingAdmissionPolicyBinding

Enlazamos la política creada con uno o varios objetos de Kubernetes, en este caso queremos aplicarla únicamente a los recursos que se ejecutan en un namespace por la label env: production o staging.

# 2. MutatingAdmissionPolicyBinding - Enlace de la política
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: add-platform-labels-binding
spec:
  policyName: add-platform-labels

  # Podemos restringir a qué namespaces se aplica
  matchResources:
    namespaceSelector:
      matchExpressions:
        - key: env
          operator: In
          values: ["production", "staging"]

policyName

Nombre exacto de la ValidatingAdmissionPolicy que se va a aplicar.

matchResources

Igual que en la política, pero aquí puedes afinar aún más el alcance (por ejemplo, aplicar solo a ciertos namespaces con namespaceSelector). Si lo omites, se aplica a todos los recursos que coincidan con los criterios de la política.

Conclusión

Kubernetes está apostando fuertemente por incorporar de forma nativa capacidades avanzadas de admisión, reduciendo la dependencia de herramientas externas como Kyverno o Gatekeeper para casos de uso habituales. Esto permite simplificar el mantenimiento de la plataforma y disminuir su complejidad.

Por otro lado, la adopción de Common Expression Language (CEL) como lenguaje de expresiones parece consolidarse, y no sería extraño que termine convirtiéndose en un estándar dentro del ecosistema.

Validar y mutar objetos de manera declarativa es fundamental para mantener un clúster consistente, seguro y alineado con las configuraciones deseadas, lo que finalmente nos facilita el trabajo diario y nos permite centrarnos en entregar valor real.

Referencias

• https://github.com/kubernetes/enhancements/issues/3962

• https://github.com/kubernetes/kubernetes/issues/122936

• https://github.com/kubernetes/kubernetes/pull/136039

• https://kubernetes.io/docs/reference/access-authn-authz/mutating-admission-policy/

• https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

Common Expression Language (CEL) es un lenguaje de expresiones ligero creado por Google, diseñado para validaciones, evaluaciones lógicas rápidas y portabilidad. A diferencia de un lenguaje de programación completo, CEL es restringido y seguro: no permite ejecución de código arbitrario, lo que lo hace ideal para las APIs de Kubernetes.

Tendencia y adopción en Kubernetes

Durante los ultimos años está habiendo una tendencia ascendente y fuerte a utilizar Common Expression Language (CEL) para las políticas de validación, gobernanza y admission en Kubernetes.

Kubernetes incoporó Common Expression Language (CEL) en la versión 1.25 (CRD validation rules), extendiendo su uso a otras funcionalidad como el ValidatingAdmissionPolicy (GA en 1.30).

Los motivos que han impulsado su utilización:

• Rendimiento: Se ejecuta directamente en el API Server, eliminando la necesidad del uso de webhooks externos, reduciendo así la latencia

• Simplicidad y seguridad: Es un lenguaje de expresiones restringido y determinista. No se pueden realizar iteraciones (bucles), no hay acceso a sistemas externos ni ejecución de código arbitrario

• Nativo: Las reglas se definen en los manifiestos YAML como parte de los propios objetos de Kubernetes (ValidatingAdmissionPolicy y MutatingAdmissionPolicy)

• Portabilidad: Se está convirtiendo en un estándar, proyectos como Kyverno han comenzado a integrarlo como motor de expresiones. Al igual que otros proyectos como Google Cloud IAM Conditions o Envoy entre otros proyectos de la CNCF

9 ejemplos para comenzar a utilizar Common Expression Language (CEL)

Comprobar que exista un mínimo y máximo de replicas

CEL soporta el operador ternario condition ? valueIfTrue : valueIfFalse. En este caso se aplica una regla diferente según el namespace. Es una forma poderosa de crear políticas contextuales.

object.spec.replicas >= params.minReplicas && object.spec.replicas <= params.maxReplicas

# Al menos 2 réplicas para alta disponibilidad
object.spec.replicas >= 2

# Solo aplicar en namespace production
object.metadata.namespace == "production"
  ? object.spec.replicas >= 3
  : object.spec.replicas >= 1

Comprobar el prefijo y sufijo

startsWith() y endsWith() son funciones nativas de CEL sobre strings. Ideales para imponer convenciones de nomenclatura en recursos de Kubernetes.

# El nombre debe empezar con "app-"
object.metadata.name.startsWith("app-")

# El nombre debe terminar con "-prod"
object.metadata.name.endsWith("-prod")

# Combinación de ambos
object.metadata.name.startsWith("app-") &&
object.metadata.name.endsWith("-prod")

Comprobar que la imagen tenga un tag

Exige que todos los contenedores del Pod usen una imagen con tag explícito y distinto de :latest.

object.spec.containers.all(c, c.image.contains(’:’) && !c.image.endsWith(’:latest’))

Comprobar la utilización de contenedores con privilegios

Cuando un campo es opcional, usar has() antes de acceder a él evita errores de evaluación. El cortocircuito de || hace que si !has() es true, la segunda parte no se evalúa. Este patrón es clave en políticas reales.

object.spec.containers.all(c, 
  !has(c.securityContext) || 
  !has(c.securityContext.privileged) || 
  c.securityContext.privileged != true
)

# Si existe securityContext, debe tener runAsNonRoot=true
!has(object.spec.securityContext) ||
object.spec.securityContext.runAsNonRoot == true

# Patrón: campo opcional con valor por defecto
has(object.spec.priority)
  ? object.spec.priority <= 10
  : true

Comprobar que todos los contenedores usan request y limits de CPU y memoria

Garantiza que cada contenedor del Pod defina explícitamente requests y limits tanto de CPU como de memoria, evitando pods sin restricciones que puedan afectar al resto del cluster.

object.spec.containers.all(c, 
  has(c.resources) && 
  has(c.resources.requests) && has(c.resources.requests.cpu) && has(c.resources.requests.memory) &&
  has(c.resources.limits) && has(c.resources.limits.cpu) && has(c.resources.limits.memory)
)

Comprobar si se utilizan volumenes hostPath y hostNetwork

Impide que un Pod acceda directamente al sistema de archivos o a la red del nodo donde se ejecuta. Ambas capacidades pueden comprometer el aislamiento del cluster si caen en manos de un contenedor malicioso.

(!has(object.spec.hostNetwork) || object.spec.hostNetwork == false) &&
(!has(object.spec.volumes) || object.spec.volumes.all(v, !has(v.hostPath)))

Prohibir actualizar la imagen de un contenedor

Garantiza que una vez desplegado un Pod, las imágenes de sus contenedores no puedan cambiarse. Útil para entornos donde los cambios de imagen deben pasar por un nuevo despliegue controlado.

request.operation != ‘UPDATE’ || 
object.spec.template.spec.containers.all(newC, 
  oldObject.spec.template.spec.containers.exists(oldC, 
    oldC.name == newC.name && oldC.image == newC.image
  )
)

Comprobar que existen una label con varios valores predeterminados

Obliga a que todos los recursos tengan el label tier y que su valor sea uno de los permitidos por la organización.

has(object.metadata.labels.tier) && 
object.metadata.labels.tier in ['frontend', 'backend', 'database']

Validar que un campo cumpla un patrón utilizando una expresión regular

matches() evalúa una expresión regular (el subconjunto de regex que usa Go). No soporta lookaheads ni backreferences. Muy útil para validar formatos de versiones, IPs, o nombres con convenciones estrictas.

# Solo minúsculas, números y guiones
object.metadata.name.matches("^[a-z0-9-]+$")

# Validar formato de versión semántica
object.spec.version.matches(
  "^v[0-9]+\.[0-9]+\.[0-9]+$"
)

Como agradecimiento por haber llegado hasta aquí, te dejo una tabla resumen con los operadores, macros y funciones más comunes en CEL.

Conclusión

Creo que CEL no es una moda pasajera: Kubernetes lleva utilizando esta tecnología desde hace varias versiones, y la tendencia es que otros proyectos de la CNCF también están adoptándola, consolidándose como el motor de expresiones estándar.

Con unos pocos operadores se pueden escribir la mayoría de las políticas que necesitamos en nuestro día a día, lo que hace que la curva de aprendizaje sea muy corta.

Creo que aprender CEL es una buena inversión: la misma sintaxis y patrones nos van a servir en diferentes aplicaciones, como Kubernetes, Kyverno y otros proyectos del ecosistema.

Referencias

• https://github.com/google/cel-go

• https://github.com/google/cel-spec/blob/master/doc/langdef.md

• https://kubernetes.io/docs/reference/using-api/cel/

En el siguiente articulo te explico 9 comandos para que domines Git Submodules.

Git submodules

Son repositorios Git anidados dentro de otros repositorios Git. Permiten incluir proyectos externos en tu proyecto o solución como un subdirectorio.

Un Git Submodule es esencialmente un puntero a un commit específico de otro repositorio Git.

¿Por qué usar Git Submodules?

• Reutilización de código: Compartir bibliotecas o componentes entre múltiples proyectos sin duplicar código

• Versionado preciso: Controlar exactamente qué versión de una dependencia usas

• Separación de concerns: Mantener módulos con ciclos de desarrollo independientes

• Colaboración multi-equipo: Diferentes equipos pueden trabajar en módulos separados con sus propios permisos

• Dependencias de terceros: Incluir librerías externas manteniendo la trazabilidad de versiones

9 Comandos para dominar Git Submodules

Activa uno o varios Git Submodules

Cuando clonas un repositorio con submodules, estos no están activos por defecto.

Usa init para registrarlos en tu configuración local antes de descargar su código.

git submodule init

Activar submodules específicos

git submodule init libs/utils
git submodule init libs/utils libs/auth

Añade un Git Submodule

git submodule add <url-repositorio> <ruta-destino>

Si quieres fijar una rama concreta desde el principio:

git submodule add -b main https://github.com/company/auth-lib.git libs/auth

Recuerda realizar commit con los cambios:

git commit -m “Añadir submodule utils”

Eliminar un Git Submodule

Desregistrar el Git Submodule

git submodule deinit -f libs/old-module
git rm -f libs/old-module
rm -rf .git/modules/libs/old-module     # opcional pero muy recomendado
git commit -m "Eliminar submodule old-module"

Clonar un repositorio con Git Submodules

Todo de una vez (opción recomendada):

git clone --recursive <url-repositorio>

Si ya clonaste sin --recursive:

git submodule update --init --recursive

Sincronizar contenido

Utiliza el comando git submodule update para sincronizar el contenido.

Actualizar TODOS los Git Submodules a su último commit remoto

git submodule update --remote --recursive

Actualizar UN Git Submodule específico:

git submodule update --remote libs/utils

Con merge o rebase automático:

git submodule update --remote --merge
git submodule update --remote --rebase

Después de actualizar, commitea el cambio de referencia:

git add .
git commit -m “Actualizar submodules a última versión”

Sincronizar URLs y configuración

Utiliza el comando sync en los siguientes supuestos:

1. La URL del repositorio remoto cambió

2. Cambias entre HTTPS y SSH

3. El repositorio se movió a otro servidor

4. Acabas de hacer git pull y .gitmodules tiene URLs nuevas

git submodule sync

Comprueba el estado de los Git Submodules

Ver estado básico de todos los Git Submodules

git submodule status

Ver resumen de cambios

git submodule summary

Ver status más detallado

git status

Configurar rama a seguir en un Git Submodule

Establece que el Git Submodules siga una rama específica (en vez de commit fijo). Actualiza .gitmodules.

git submodule set-branch -b develop libs/utils

Ejecuta comandos en todos los Git Submodules

git submodule foreach

Hacer pull en todos los Git Submodules

git submodule foreach 'git pull origin main'

Crear rama en todos los Git Submodules

git submodule foreach 'git checkout -b feature/update'

Si usas Git Submodules anidados, la opción--recursive recorrerá todo

git submodule foreach --recursive 'git status'

Limpiar TODO (cuidado – destructivo)

git submodule foreach --recursive 'git clean -fdx && git reset --hard'

Conclusión

Los Git Submodules son una herramienta poderosa cuando se usan con criterio, pero no son la solución mágica para todas las situaciones de dependencias. Valora bien el tradeoff entre control preciso vs. complejidad operativa.

Referencias

• https://git-scm.com/book/en/v2/Git-Tools-Submodules

Si vas con prisa:

Microsoft ha creado .NET Aspire (ahora ha sido renombrado simplemente como Aspire), un framework que agiliza el desarrollo de aplicaciones distribuidas, observables y listas para ser desplegadas en producción. Los desarrolladores pueden concentrarse en la lógica de negocio, mientras Aspire se encarga de tareas como la orquestación de servicios y su configuración.

Si te interesa recibir contenido sobre Kubernetes, DevOps o contentenedores directamente en tu email… suscríbete gratis y no te pierdas ninguna novedad. 🚀

Rebranding y nueva Web

La primera novedad es que .NET Aspire ha sido renombrado simplemente como Aspire, ahora dispone de su propia página web para consultar toda la documentación: https://aspire.dev/

Soporte Políglota

Python y JavaScript se pueden utilizar junto con .NET.

Python

• AddPythonApp, AddPythonModule, AddPythonExecutable para diferentes modelos de aplicación

• AddUvicornApp para aplicaciones ASGI (FastAPI, Starlette, Quart)

• Gestión flexible de paquetes: detección automática, soporte para uv, pip y venv

• Generación automática de Dockerfiles

• Soporte completo de depuración en VS Code

JavaScript

• AddJavaScriptApp como método unificado (reemplaza AddNpmApp)

• Soporte mejorado para Vite con AddViteApp

• Detección automática de gestores de paquetes (npm, yarn, pnpm)

• Generación dinámica de Dockerfiles

Infraestructura

• Propiedades de conexión en múltiples formatos (URI, JDBC, propiedades individuales)

• Confianza automática de certificados en todos los lenguajes

• Variables de entorno simplificadas para descubrimiento de servicios

AI

La versión 13.0 de Aspire añade el servidor MCP (Model Context Protocol) el cual nos permite ofrecer información (recursos, logs y trazas) sobre nuestra solución a nuestros herramientas de AI.

Aspire 13.1 incluye el comando aspire mcp init, detecta automáticamente nuestro entorno de desarrollo y configura todo automáticamente.

• Descubrimiento de integraciones: los agentes de IA pueden listar las integraciones disponibles de Aspire y recuperar la documentación de cualquier paquete

• AppHost: listar y cambiar entre proyectos AppHost en tu espacio de trabajo

• Dashboard: consultar el estado de los recursos, ver logs e inspeccionar trazas de tu aplicación en ejecución

Azure

• Selección de tenant durante el aprovisionamiento para manejar cuentas multi-tenant

• Dashboard de Aspire incluido por defecto en Azure App Service

• Integración con Application Insights para monitoreo y telemetría completa

Developer experience

CLI

• aspire init para inicializar soluciones Aspire de forma interactiva

• Mejoras en aspire update con flag --self para actualizar el CLI

• Soporte para AppHost de archivo único

• Modo no interactivo para CI/CD

Extensión de VS Code

• Depuración de proyectos Python y C# dentro de VS Code

• Gestión de integraciones

• Configuración de launch

• Comandos de publish y deploy (preview)

Pipelines y Deployment

• aspire do: Nuevo sistema de pipelines para coordinar operaciones de build, publicación y despliegue

• Soporte para ejecución paralela, seguimiento de dependencias y flujos de trabajo extensibles

• Reemplaza la infraestructura de publishing anterior con un modelo más flexible

Otros

• Container Files como Artefactos: Permite extraer archivos del contenedor de un recurso (por ejemplo, frontend compilado) y copiarlos en otro contenedor (backend) usando PublishWithContainerFiles(), ideal para servir aplicaciones SPA desde el backend

• Construcción de Imágenes Utilizando C# (Beta): API experimental WithDockerfileBuilder() que permite generar Dockerfiles de forma programática usando C#, con soporte para multi-stage builds y una API fluida y type-safe

• Integración con .NET MAUI: Nueva integración que permite orquestar aplicaciones móviles MAUI junto a servicios cloud, con soporte para Windows, Mac Catalyst, iOS y Android mediante AddMauiProject() y métodos como AddAndroidEmulator(), AddiOSSimulator()

• El paquete Aspire.Hosting.DevTunnels ha pasado de experimental a estable, permitiendo exponer tus aplicaciones locales a Internet de forma segura

Referencias

• https://blog.javivela.dev/p/desarrolla-aplicaciones-distribuidas

• Aspire Unplugged with David and Maddy

Dependiendo del tipo de QoS asignado, Kubernetes puede mover el Pod a otro nodo, lo que provoca un reinicio del mismo.

Cuando definimos estos valores, es un comportamiento que debemos tener en cuenta si queremos evitar que nuestros Pods y contenedores se reinicien en caso de que un nodo no tenga recursos suficientes.

Requests y Limits

Cuando escribimos la definición de un Pod, tenemos la posibilidad de configurar la memoria y CPU asignada a cada uno de los contenedores que lo componen.

Un Pod se compone de uno o más contenedores

Kubernetes ofrece la posibilidad de hacerlo en las propiedades:

• spec.containers[].resources.requests: Memoria y CPU mínima asignada al contenedor.

• spec.containers[].resources.limits: Memoria y CPU máxima asignada al contenedor.

Valores Quality of Service (QoS)

Utilizando los valores de memoria y CPU, Kubernetes asigna un estado a cada Pod. Los valores del estado Quality of Service (QoS) son tres y se utilizan para asignar el nodo donde se ejecutará el Pod y sus contenedores, así como para priorizar los Pods que se pueden mover a otro nodo en caso de que el nodo necesite liberar recursos.

Guaranteed

Se asigna este estado cuando todos los contenedores que componen el Pod tienen configurados tanto los requests como los limits y los valores de memoria y CPU son iguales.

Los Pods con este estado asignado no se mueven a otros nodos cuando se necesitan recursos en el nodo.

Se pueden reiniciar y mover en caso de que el nodo no se encuentre disponible o sea eliminado del clúster.

Esta configuración se aplica a cargas de trabajo críticas para reducir posibles reinicios de los Pods o los contenedores.

A partir de Kubernetes 1.34 (Of Wind & Will - O´WaW), no es necesario definir la memoria y CPU en cada uno de los contenedores. Podemos hacerlo a nivel del Pod a través de la propiedad spec.resources.limits y spec.resources.requests.

La definición de la memoria y CPU se encuentra en estado Beta, asegúrate que está activada en tu clúster si quieres hacer uso de ella.

Puedes comprobarlo utilizando el endpoint /metrics: kubectl get --raw /metrics | grep kubernetes_feature_enabled

apiVersion: v1
kind: Pod
metadata:
  name: pod-guaranteed
spec:
  containers:
  - name: container
    image: nginx
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"
      limits:
        memory: "100Mi"
        cpu: "100m"

Comprobamos el QoS asignado por Kubernetes:

kubectl get pods -n qos -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass

Burstable

Kubernetes asigna este estado cuando al Pod no se le asigna el estado Guaranteed y se define la CPU o memoria en los limits o requests de uno de los contenedores que componen el Pod (no es necesario que sean iguales).

Con este tipo de configuración, podemos hacer un mejor uso de la memoria y CPU compartidas.

Los Pods en este estado pueden ser reiniciados y movidos a otro nodo después de haber movido los Pods en estado BestEffort.

apiVersion: v1
kind: Pod
metadata:
  name: pod-burstable
spec:
  containers:
  - name: container
    image: nginx
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"
      limits:
        memory: "200Mi"
        cpu: "200m"

Comprobamos el QoS asignado por Kubernetes:

kubectl get pods -n qos -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass

BestEffort

Se aplica este estado cuando no se define ningún request ni limit en los contenedores del Pod.

Los Pods con este estado son los primeros en ser eliminados y movidos de nodo en caso de que sea necesario.

Aplicamos esta configuración a aplicaciones que se pueden reiniciar sin provocar un impacto importante en nuestra solución.

apiVersion: v1
kind: Pod
metadata:
  name: pod-besteffort
spec:
  containers:
  - name: container
    image: nginx

Comprobamos el QoS asignado por Kubernetes:

kubectl get pods -n qos -o custom-columns=NAME:.metadata.name,QOS:.status.qosClass

Conclusion

Kubernetes utiliza las clases Quality of Service para priorizar qué Pods permanecen en ejecución cuando un nodo necesita liberar recursos (Node-pressure Eviction). Entender la diferencia entre Guaranteed, Burstable y BestEffort es esencial para configurar correctamente nuestras aplicaciones.

Referencias

• https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

• https://kubernetes.io/docs/tasks/configure-pod-container/assign-pod-level-resources/

• https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/

NGINX Ingress Controller es un Ingress controller. Un ingress controller es un load balancer que se utiliza en los orquestadores de contenedores (como Kubernetes), permitiéndonos gestionar el tráfico externo hacia los contenedores de nuestro clúster. En resumen, es un reverse proxy en el que podemos configurar diferentes reglas para dirigir el tráfico de entrada hacia nuestros contenedores.

El pasado 11 de noviembre de 2025, el grupo de trabajo Kubernetes SIG Network y el comité Security Response anunciaron que el proyecto NGINX Ingress Controller no se mantendrá a partir de marzo de 2026. Su recomendación es migrar a Gateway API o a otro Ingress Controller (puedes consultar una lista aquí: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).

Kubernetes Gateway API

Es un proyecto oficial de Kubernetes para gestionar el tráfico de red en las capas L4 y L7. Proporciona un diseño genérico y basado en roles.

Capa L4: Su objetivo es garantizar la transferencia de datos de extremo a extremo entre dispositivos, gestionando la confiabilidad, el control de flujo y la multiplexación.

Capa L7: Es la capa de aplicación. Siendo la capa superior del modelo OSI, interactúa directamente con el software del usuario, proporcionando servicios para aplicaciones como el correo electrónico o la navegación web.

El proyecto lo mantiene el grupo de trabajo SIG-Network (Network Special Interest Group), siendo sus principales objetivos los de mejorar y proporcionar estándares a nivel de red (networking).

Nos permite configurar y gestionar el tráfico de red en todas las direcciones:

• Norte / Sur (Ingress): Tráfico desde el exterior hacia el clúster (y viceversa).

• Este / Oeste (Mesh): Tráfico entre contenedores dentro del clúster.

Es fácil confundir API Gateway y Gateway API, la primera es una herramienta que agrupa y unifica diferentes APIs en una única API. De esta manera es posible gestionar y configurar las diferentes APIs en un único punto. Algunos servicios como Azure API Management o Amazon API Gateway.

Gateway API es una interfaz definida utilizando recursos de Kubernetes y su diseño se ha basado en los siguientes principios:

• Basada en roles

• Portable

• Expresiva

• Extensible

El diseño orientado a roles (role-oriented) separa las responsabilidades entre diferentes personas para mejorar la usabilidad, flexibilidad y control en entornos de infraestructura compartida.

GatewayClass

Este es un recurso a nivel de clúster que define una plantilla para instanciar Gateways, cada GatewayClass utiliza un proveedor diferente (Traefik, Istio, Cilium, entre otros)

Nos permite desacoplar la implementación de la utilización, pudiendo definir diferentes GatewayClasses dependiendo de los requisitos de nuestra aplicación.

En definitiva, describe los posibles Gateways disponibles en el clúster para que puedan ser utilizados por el usuario.

Un ejemplo típico sería separar las aplicaciones internas de las aplicaciones externas, o utilizar diferentes implementaciones (como Traefik o Istio).

kind: GatewayClass
metadata:
  name: internet
spec:
  controllerName: “example.net/gateway-controller”
  parametersRef:
    group: example.net
    kind: Config
    name: internet-gateway-config
---
apiVersion: example.net/v1alpha1
kind: Config
metadata:
  name: internet-gateway-config
spec:
  ip-address-pool: internet-vips

Gateway

Nos permite definir cómo vamos a gestionar el tráfico de nuestra red: endpoints, hostnames, filtrados, etc.

Cuando un usuario crea un Gateway en Kubernetes, la capa de infraestructura puede crear recursos de load balancer a través del controlador asociado al GatewayClass.

Un Gateway se define a partir de los siguientes elementos:

• GatewayClassName: Define el nombre del GatewayClass a ser utilizado.

• Listener: Define los nombres de host (hostnames), puertos (ports), protocolos (ej. http o https), TLS (Transport Layer Security), y rutas que pueden ser utilizadas.

• Address: Define las direcciones IP requeridas para el Gateway.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
spec:
  gatewayClassName: internet
  listeners:
  - name: default
    hostname: “*.my-custom-domain.com”
    port: 80
    protocol: HTTP

Dependiendo del GatewayClass desplegado, la creación de un Gateway puede implicar la ejecución de algunas acciones para crear diferentes elementos en la infraestructura para poder recibir y redirigir el tráfico de red:

• Uso de las APIs del proveedor cloud para crear un nuevo Load Balancer.

• Actualizar la configuración de un Load Balancer existente.

• Configurar el SDN (Software-Defined Networking) para actualizar la configuración existente.

HTTPRoute

Define la ruta de una petición HTTP desde un Gateway listener hasta un elemento del clúster (API Object, p. ej., a un Service - SVC).

Se define a partir de los siguientes elementos:

• ParentRefs: Define qué Gateways van a estar asociados a este elemento. Se utiliza el Namespace de donde se ha creado el Gateway y el nombre del Gateway.

• Hostnames (opcional): Define el nombre o nombres del host (no se pueden utilizar IPs, se pueden utilizar comodines como *) que serán enrutados en la definición cuando el valor de la cabecera Host de la petición coincida.

• Rules: Permite definir una lista de reglas para enrutar la petición hacia los servicios definidos cuando esta coincida con la expresión definida:

  • Matches: Define las condiciones que debe cumplir la petición para poder hacer uso del HTTPRoute; el match se hará efectivo si solo una de las condiciones se cumple.

  • Filters: Se utiliza para añadir información adicional (p. ej., headers).

  • BackendRefs (opcional): Si no se define, la respuesta a la petición recibirá un código de error 404. Permite definir el objeto de Kubernetes que recibirá la petición (p. ej., Service).

  • Timeouts (opcional / experimental a la hora de escribir el artículo): En caso de no especificarse, los timeouts serán los definidos en la implementación. Permite definir dos timeouts:

    • Request: El tiempo máximo que tiene el Gateway API para enviar una respuesta al cliente que ha iniciado la petición.

    • BackendRequest: Es el tiempo máximo que tiene el Gateway para enviar la petición al backend.

  • Name (opcional): Permite especificar un nombre a la regla definida.

  • sessionPersistence (opcional / experimental a la hora de escribir el artículo): Define y configurar el tipo de persistencia a utilizar.

  • retry (opcional / experimental a la hora de escribir el artículo): Define la política de reintentos para la petición.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
    - name: gateway
  hostnames:
    - “bar.example.com”
  rules:
    - matches:
        - headers:
            - type: Exact
              name: env
              value: canary
      backendRefs:
        - name: bar-svc-canary
          port: 8080
    - backendRefs:
        - name: bar-svc
          port: 8080

GRPCRoute

Al igual que HTTPRoute, GRPCRoute permite definir la ruta de una petición gRPC desde un Gateway listener hasta un elemento del clúster (API Object, p. ej., a un Service - SVC).

Se define a partir de los siguientes elementos:

• ParentRefs: Define qué Gateways van a estar asociados a este elemento. Se utiliza el Namespace de donde se ha creado el Gateway y el nombre del Gateway.

• Hostnames (opcional): Define el nombre o nombres del host (no se pueden utilizar IPs, se pueden utilizar comodines como *) que serán enrutados en la definición cuando el valor de la cabecera Host de la petición coincida.

• Rules: Permite definir una lista de reglas para enrutar la petición hacia los servicios definidos cuando esta coincida con la expresión definida:

  • Matches: Define las condiciones que debe cumplir la petición para poder hacer uso del HTTPRoute; el match se hará efectivo si solo una de las condiciones se cumple.

  • Filters: Se utiliza para añadir información adicional (p. ej., headers).

  • BackendRefs (opcional): Si no se define, la respuesta a la petición recibirá un código de error 404. Permite definir el objeto de Kubernetes que recibirá la petición (p. ej., Service).

  • Timeouts (opcional / experimental a la hora de escribir el artículo): En caso de no especificarse, los timeouts serán los definidos en la implementación. Permite definir dos timeouts:

    • Request: El tiempo máximo que tiene el Gateway API para enviar una respuesta al cliente que ha iniciado la petición.

    • BackendRequest: Es el tiempo máximo que tiene el Gateway para enviar la petición al backend.

  • Name (opcional / experimental a la hora de escribir el artículo): Permite especificar un nombre a la regla definida.

  • sessionPersistence (opcional / experimental a la hora de escribir el artículo): Define y configurar el tipo de persistencia a utilizar.

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: foo-route
spec:
  parentRefs:
    - name: gateway
  hostnames:
    - “foo.example.com”
  rules:
    - matches:
        - method:
            service: com.example
            method: “*”
      backendRefs:
        - name: foo-svc
          port: 50051

Policies

BackendTLSPolicy

Nos permite cifrar el tráfico entre el Gateway y el backend al cual se redirige el tráfico.

BackendTrafficPolicy

Experimental a la hora de escribir el artículo

Esta extensión nos permite configurar la política de reintentos de una conexión en caso de que la petición falle.

Para poder hacer uso de ella necesitamos especificar:

• TargetRefs: Permite definir los objetos de Kubernetes que recibirá la petición (p. ej., Service).

• RetryConstraint: Permite configurar una política de reintentos Budget retries, la cual permite no saturar el backend cuando este no puede atender todas las peticiones.

• SessionPersistence: Permite configurar la persistencia de la sesión para el target o targets definidos. Los posibles valores a configurar son Permanent y Persistence (valor por defecto).

Implementaciones

Gateway API es un estándar creado por el grupo de trabajo SIG-Network (Network Special Interest Group). A partir de este estándar, diferentes proyectos open source y empresas han desarrollado sus implementaciones, gracias al estándar y la compatibilidad podríamos cambiar de proveedor sin necesidad de cambiar ninguno de los recursos creados previamente.

Antes de elegir una implementación es necesario entender el nivel de conformidad para elegir el que mejor se adapte a nuestros requerimientos. Existen 3 niveles:

• Conformant: Han superado pruebas completas para al menos una combinación de Ruta y Perfil (ej. Mesh + HTTPRoute o Gateway + TLSRoute), incluyendo extensiones, en una de las dos versiones más nuevas. Deben cubrir al menos un perfil y ruta con todas las pruebas principales.

• Partially Conformant: Implementaciones que se están desarrollando y que al menos han obtenido un informe de conformidad positivo en una de las últimas tres versiones.

• Stale: Implementaciones que posiblemente no se estén actualizando, se eliminarán en la siguiente versión a no ser que envíen un informe para poder obtener un nivel superior de conformidad.

Puedes consultar una lista de las mismas en el siguiente enlace: https://gateway-api.sigs.k8s.io/implementations/#implementations_1

Comparación NGINX Ingress Controller vs Gateway API

A continuación, puedes ver una tabla comparativa entre el NGINX Ingress Controller (basado en la API Ingress de Kubernetes) y la Gateway API. Esta comparación se basa en aspectos clave como características, ventajas, limitaciones y evolución.

En la tabla puedes comprobar por qué Gateway API representa una evolución más flexible y portable para la gestión de tráfico en clústeres Kubernetes.

Conclusión / Resumen

Gateway API representa la evolución de la gestión de tráfico externo en Kubernetes. Mientras que Ingress NGINX cumplió su propósito durante años, sus limitaciones en extensibilidad y su diseño lo han convertido en una solución obsoleta para las necesidades actuales de las arquitecturas cloud-native, además de que su mantenimiento terminará el próximo mes de marzo de 2026.

La arquitectura basada en roles proporciona una separación clara de responsabilidades entre administradores de infraestructura y desarrolladores. Además, su diseño expresivo y extensible permite configuraciones avanzadas de L4 y L7 que antes requerían anotaciones personalizadas o soluciones alternativas.

¿Quieres ver un ejemplo de funcionamiento con Gateway API? Escribe en comentarios y estaré encantado de prepararlo.

Referencias

• https://gateway-api.sigs.k8s.io/

• https://kubernetes.io/docs/concepts/services-networking/gateway/

Con estas instrucciones defines cómo se construye y ejecuta tu contenedor, impactando en el tamaño de la imagen creada y la flexibilidad a la hora de cambiar una configuración.

Maneras de definir los parámetros de las instrucciones

Podemos definir los parámetros de las instrucciones RUN, CMD y ENTRYPOINT de dos maneras diferentes: exec form y shell form.

Shell form

Utiliza una shell (/bin/sh -c) para ejecutar los comandos definidos como una cadena de texto. Las características principales son:

• Permite usar variables de entorno: $HOME, $PATH

• Permite operadores shell: &&, ||, pipes |, redirecciones

• El PID 1 es el shell, no tu aplicación

• No procesa señales correctamente (problemas con SIGTERM)

Puedes definir el uso de una shell diferente con la instrucción SHELL.

CMD comando parametro1 parametro2
RUN apt-get update

Exec form

Ejecuta el comando directamente sin una shell intermedia. Se utiliza un array JSON para definir cada comando, flag o argumento. Las características principales son:

• Tu aplicación es PID 1

• Procesa señales correctamente (SIGTERM, SIGKILL)

• NO expande variables de entorno directamente

• NO permite operadores shell

• Más eficiente (un proceso menos)

CMD [”ejecutable”, “parametro1”, “parametro2”]
RUN [”apt-get”, “update”]

RUN

Nos permite ejecutar comandos en la fase de construcción de la imagen (docker build). Cada ejecución crea una nueva capa en la imagen.

Se utiliza para instalar dependencias, compilar aplicaciones o aplicar configuraciones.

RUN dotnet restore
RUN apt-get update && apt-get install -y curl

CMD

Define el comando y argumentos predeterminados al iniciar el contenedor. Se puede sobreescribir pasando argumentos al comando docker run.

CMD [”dotnet”, “MiApp.dll”]

ENTRYPOINT

Te permite configurar el contenedor como un ejecutable. Puedes añadir argumentos adicionales al final del mismo con el comando docker run <ARGS>. Se puede sobreescribir con el parámetro --entrypoint.

ENTRYPOINT [”dotnet”, “MiApp.dll”] 

Conclusión

Utiliza RUN para instalar paquetes, configurar el sistema o compilar tu código.

Utiliza CMD para aplicaciones donde necesites flexibilidad, comandos que puedan cambiar o para definir los parámetros de ENTRYPOINT.

Utiliza ENTRYPOINT para configurar tu contenedor como un ejecutable.

Puedes combinar el uso de ENTRYPOINT y CMD para tener una mayor flexibilidad: ENTRYPOINT define el comando fijo y CMD te proporciona los argumentos por defecto, permitiendo que puedan ser modificados.

Ejemplo de fichero Dockerfile para compilar y ejecutar una aplicación dotnet:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore “MiApi.csproj”
RUN dotnet publish “MiApi.csproj” -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT [”dotnet”, “MiApi.dll”]
CMD [”--urls”, “http://0.0.0.0:8080”]

Referencias

https://docs.docker.com/reference/dockerfile/

https://docs.docker.com/build/building/best-practices/

Stable: Dynamic Resource Allocation (DRA) Core GA

• Description: Core DRA functionality for selecting, allocating, sharing, and configuring GPUs, TPUs, NICs and other devices

• Details: Based on structured parameters with ResourceClaim, DeviceClass, ResourceClaimTemplate, and ResourceSlice API types

• KEP: KEP #4381

Beta: Projected ServiceAccount Tokens for Kubelet Image Credential Providers

• Description: Short-lived, audience-bound ServiceAccount tokens for authenticating to container registries

• Benefits: Eliminates long-lived Secrets, reduces attack surface, simplifies credential management

• KEP: KEP #4412

Alpha: KYAML Support - Kubernetes Dialect of YAML

• Description: Safer, less ambiguous YAML subset designed specifically for Kubernetes

• Usage: Available as kubectl output format with KUBECTL_KYAML=true environment variable

• KEP: KEP #5295

Features Graduating to Stable (23 total)

Job and Pod Management

• Delayed creation of Job's replacement Pods - Prevents resource contention by creating replacement Pods only when original Pod fully terminates (KEP #3939)

• Sleep action for Container lifecycle hooks - PreStop and PostStart lifecycle hooks with configurable sleep duration (KEP #3960, KEP #4818)

• Ordered Namespace deletion - Structured deletion process ensuring security dependencies are respected (KEP #5080)

Storage Enhancements

• Recovery from volume expansion failure - Cancel and retry volume expansions with smaller values (KEP #1790)

• VolumeAttributesClass for volume modification - Generic API for modifying volume parameters like provisioned IO (KEP #3751)

Authentication and Authorization

• Structured authentication configuration - Configuration file format for API server client authentication (KEP #3331)

• Finer-grained authorization based on selectors - Authorization decisions based on field and label selectors (KEP #4601)

• Restrict anonymous requests with fine-grained controls - Configure specific endpoints for unauthenticated requests (KEP #4633)

Scheduling and Performance

• More efficient requeueing through plugin-specific callbacks - Accurate decisions about when to retry scheduling unschedulable Pods (KEP #4247)

• Streaming list responses - Streaming encoding mechanism for large list responses to reduce memory pressure (KEP #5116)

• Resilient watch cache initialization - More robust watch cache initialization during API server startup (KEP #4568)

Node and Container Runtime

• Linux node swap support - Configurable per-node swap support with LimitedSwap mode (KEP #2400)

• Allow special characters in environment variables - Support for nearly all printable ASCII characters in variable names (KEP #4369)

• Taint management separated from Node lifecycle - TaintManager refactored as separate controller (KEP #3902)

Network and Windows

• Relaxing DNS search path validation - More flexible DNS search path configuration (KEP #4427)

• Support for Direct Service Return (DSR) in Windows kube-proxy - Performance optimizations for Windows load balancing (KEP #5100)

Additional Stable Features

• API Server tracing (KEP #647)

• AppArmor support (KEP #24)

• Consistent Reads from Cache (KEP #2340)

• Discover cgroup driver from CRI (KEP #4033)

• Kubelet OpenTelemetry Tracing (KEP #2831)

New Features in Beta (22 total)

Resource Management

• Pod-level resource requests and limits - Resource budgets at Pod level shared among containers, with HPA support (KEP #2837)

• In-place Pod resize improvements - Support for decreasing memory usage and Pod-level resource integration (KEP #1287)

CLI and Configuration

• .kuberc file for kubectl user preferences - Configuration file for kubectl preferences and command aliases (KEP #3104)

Authentication and Security

• External ServiceAccount token signing - Integration with external key management solutions for token signing (KEP #740)

• Mutating admission policies - Declarative, in-process alternative to mutating admission webhooks using CEL (KEP #3962)

DRA Beta Features

• Admin access for secure resource monitoring - Controlled administrative access to in-use devices for monitoring (KEP #5018)

• Prioritized alternatives in ResourceClaims - Ordered list of resource alternatives with firstAvailable field (KEP #4816)

• Kubelet reports allocated DRA resources - PodResourcesAPI reporting of DRA allocations (KEP #3695)

Scheduling and Performance

• kube-scheduler non-blocking API calls - Asynchronous API handling with prioritized queue system (KEP #5229)

• Snapshottable API server cache - Serve list requests from cache snapshots instead of etcd (KEP #4988)

• Streaming informers for list requests - Memory-efficient streaming for large datasets using WatchList mechanism (KEP #3157)

Platform Support

• Graceful node shutdown handling for Windows nodes - Windows nodes can detect shutdown events and gracefully terminate Pods (KEP #4802)

Validation and Development

• Tooling for declarative validation of Kubernetes-native types - CEL-based validation rules for native Kubernetes types (KEP #5073)

Network Improvements

• Traffic distribution enhancements - PreferSameZone and PreferSameNode options, deprecating PreferClose (KEP #3015)

New Features in Alpha (13 total)

Security and Authentication

• Pod certificates for mTLS authentication - X.509 certificates for Pods via PodCertificateRequests (KEP #4317)

• "Restricted" Pod security standard forbids remote probes - Security enhancement preventing probe misuse (KEP #4940)

Scheduling

• Use .status.nominatedNodeName to express Pod placement - Scheduler indicates Pod placement intentions to help autoscalers (KEP #5278)

DRA Alpha Features

• Resource health status for DRA - Expose health status of devices allocated to Pods (KEP #4680)

• Extended resource mapping - Simple alternative to DRA using familiar container resource syntax (KEP #5004)

• DRA consumable capacity - Share devices or device slices across multiple ResourceClaims (KEP #5075)

• Device binding conditions - Delay Pod binding until external resources are confirmed ready (KEP #5007)

Container Management

• Container restart rules - Per-container restart policies and rules based on exit codes (KEP #5307)

• Load environment variables from files created in runtime - Runtime environment variable generation from files (KEP #3721)

Deprecations and Removals

Deprecated

• Manual cgroup driver configuration - cgroupDriver configuration setting and --cgroup-driver flag deprecated, removal planned for v1.36+ (KEP #4033)

• PreferClose traffic distribution - Deprecated in favor of PreferSameZone and PreferSameNode (KEP #3015)

End of Support Timeline

• containerd 1.x support - Kubernetes v1.35 will be the last release supporting containerd 1.x, upgrade to 2.0+ recommended (KEP #4033)

Release Cycle: 15 weeks (May 19 - August 27, 2025)
Contributors: 491 individuals from 106 companies
Ecosystem: 2,235 contributors from 370 companies across cloud native projects

En la tercera parte de la saga “Desde el kernel hasta la orquestación” nos adentramos en la orquestación de contenedores.

Si todavía no has leído los artículos anteriores, te recomiendo empezar por el primero, donde hablo de namespaces (Linux) y control groups (cgroups), herramientas de bajo nivel incluidas en el kernel de Linux para aislar procesos y limitar el acceso a los recursos del host: cgroups y namespaces.

En el segundo artículo de la saga, explico cómo herramientas de más alto nivel como runc y containerd crean una capa de abstracción que permite ejecutar “contenedores” de manera más sencilla y segura: runc y containerd.

En este post voy a explicar cómo Kubernetes interactúa con todas estas herramientas para orquestar contenedores de manera eficiente y escalable.

Kubernetes

Kubernetes es un orquestador de contenedores que monitoriza su estado y ejecuta las acciones necesarias para mantenerlos en el estado deseado. Permite escalar y actualizar aplicaciones de forma automática, facilitando la orquestación de soluciones complejas.

Kubernetes dispone de dos tipos de nodos:

• Control Plane: se encarga de ejecutar los procesos que gestionan y orquestan los contenedores de usuario.

• Worker: ejecuta los contenedores de usuario.

En los nodos de tipo control plane se ejecutan los procesos críticos de Kubernetes que permiten monitorizar y ejecutar las acciones necesarias para mantener los contenedores en el estado definido. Estos procesos son:

• etcd: almacenamiento distribuido de datos clave-valor donde Kubernetes guarda toda la información de estado del clúster.

• kube-apiserver: expone la API de Kubernetes y es el punto de entrada para todas las operaciones (ej. crear un Pod o consultar su estado).

• kube-scheduler: asigna los pods a los nodos disponibles según las necesidades de recursos y restricciones.

• kube-controller-manager: ejecuta los controladores que monitorizan el estado del clúster y realizan acciones para mantener el estado deseado.

En cada nodo de tipo worker se ejecutan dos procesos principales:

• kubelet: agente que se encarga de gestionar los pods y contenedores en el nodo, asegurando que se ejecuten correctamente.

• kube-proxy: gestiona la red y el balanceo de carga para exponer los servicios de Kubernetes dentro y fuera del clúster.

Un Pod es la unidad más pequeña de despliegue en Kubernetes. Representa uno o varios contenedores que comparten el mismo espacio de red, almacenamiento y configuración. Todos los contenedores de un Pod se ejecutan en el mismo nodo y pueden comunicarse entre sí a través de localhost.

El flujo de creación de un Pod en Kubernetes sería el siguiente:

• Cuando un usuario crea un nuevo Pod (uno o más contenedores trabajando entre sí), interactúa con kube-apiserver. Una vez procesada la solicitud, kube-scheduler decide en qué nodo de tipo worker debe ejecutarse.

• La solicitud es recibida por kubelet, que realiza las operaciones necesarias para comenzar la ejecución de los contenedores a través del Container Runtime Interface (CRI).

El siguiente diagrama muestra la arquitectura que vamos a explorar en el post, desde el control plane de Kubernetes hasta los procesos del kernel:

Container Runtime Interface (CRI)

Una de las principales características de Kubernetes es la interoperabilidad con diferentes runtimes de contenedores. Para lograrlo, Kubernetes define Container Runtime Interface (CRI), un estándar basado en gRPC que permite a kubelet comunicarse con distintos motores de ejecución de contenedores (como containerd, CRI-O, Docker, etc.) de manera uniforme y desacoplada.

CRI facilita la integración de nuevos runtimes sin necesidad de modificar el código, promoviendo así la flexibilidad y la evolución del ecosistema de contenedores.

Una vez que kubelet recibe la petición para ejecutar un nuevo Pod, realiza las siguientes acciones:

• Crear el namespace, cgroups y configurar la red.

• Realizar pull de la imagen o imágenes en caso de que fuera necesario.

• Crear el container

• Ejecutar el container

Para ello, la interfaz proporciona las siguientes interfaces a través de los servicios RuntimeService e ImageService.

Puedes encontrar la definición de las interfaces en el siguiente enlace:

https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto

A continuación te describo algunos de los métodos más importantes:

El PodSandbox es el entorno compartido donde vivirán todos los contenedores del Pod:

• RunPodSandbox – Crea los namespaces, configura la red y prepara el entorno.

• StopPodSandbox – Detiene todos los procesos y libera los recursos de red.

• RemovePodSandbox – Limpia completamente el sandbox.

Gestión individual de cada contenedor dentro del PodSandbox:

• CreateContainer – Prepara el contenedor con su configuración específica.

• StartContainer – Inicia la ejecución del proceso principal.

• StopContainer – Detiene el contenedor con un período de gracia.

• RemoveContainer – Elimina completamente el contenedor.

Monitoreo continuo del estado y rendimiento:

• ContainerStatus / PodSandboxStatus – Estado actual de los componentes.

• ContainerStats / PodSandboxStats – Métricas de CPU, memoria, I/O.

• ListContainers / ListPodSandbox – Inventario de componentes activos.

Interacción directa con contenedores en ejecución:

• ExecSync - Ejecutar comandos síncronos (kubectl exec)

• Attach - Conectarse a la salida estándar del contenedor

• PortForward - Redirección de puertos para acceso externo

containerd permite el uso de plugins para extender su funcionalidad. Existen varios tipos: snapshotter, almacenamiento o interfaces gRPC.

Para habilitar la comunicación entre kubelet y containerd, es necesario utilizar el plugin CRI.

La configuración de containerd en /etc/containerd/config.toml muestra cómo está habilitado el plugin CRI y configurado para usar runc como runtime por defecto:

Pause container

Un Pod puede contener uno o varios contenedores que comparten recursos, configuración y tienen la posibilidad de comunicarse entre sí.

Para poder lograrlo, es necesario que se ejecuten en el mismo namespace y control group. Para ello, introducimos el componente pause container.

pause container es un componente esencial en Kubernetes. Su función principal es mantener activo el namespace y el control group asociados a un Pod, incluso si los contenedores fallan o se reinician. De esta manera, varios contenedores comparten el mismo espacio de red y otros recursos.

Es extremadamente ligero (por ejemplo, la imagen mcr.microsoft.com/oss/kubernetes/pause:3.6 ocupa solo 484 kB). Ejecuta un bucle infinito escrito en C y gestiona señales como:

• SIGINT/SIGTERM: señales que indican al proceso que debe finalizar de forma ordenada. El pause container las gestiona para permitir una parada controlada del Pod.

• SIGCHLD: señal recibida cuando un proceso hijo termina. El pause container la maneja para limpiar correctamente los procesos hijos y evitar procesos zombis.

Estas señales permiten que el pause container actúe como un proceso init dentro del Pod, gestionando el ciclo de vida de los contenedores y asegurando la correcta recolección de procesos hijos.

En resumen, el pause container actúa como el proceso “padre” de todos los contenedores de un Pod, asegurando que los namespaces y cgroups permanezcan activos mientras el Pod exista. Si los procesos de los contenedores fallan o se reinician, el pause container mantiene el entorno aislado y listo para que los nuevos procesos se inicien en el mismo contexto.

Ejemplo práctico

En el siguiente ejemplo voy a mostrar cómo ver las diferentes jerarquías de procesos, cgroups y namespaces que se crean cuando ejecutamos un pod en un clúster de Kubernetes.

He desplegado un clúster de Kubernetes en Azure. En el siguiente enlace puedes ver cómo crear uno: https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-portal.

Desplegamos el siguiente Pod en el clúster AKS:

kubectl create ns develop


cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: web-with-logger
  namespace: develop
spec:
  containers:
  - name: web-server
    image: nginx:alpine
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  - name: log-reader
    image: busybox
    command: ["sh", "-c"]
    args:
    - |
      while true; do
        if [ -f /logs/access.log ]; then
          tail -n 5 /logs/access.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  volumes:
  - name: shared-logs
    emptyDir: {}
EOF

Para poder acceder a la shell del nodo del clúster (sí, con los permisos correctos puedes acceder a la shell del nodo), utilizo el plugin kubectl node-shell.

El comando ps --forest -ef nos proporciona una vista completa del árbol de procesos, mostrando cómo todos los componentes se relacionan jerárquicamente desde systemd hasta nuestros contenedores de aplicación:

Podemos comprobar que el proceso padre de nuestro contenedor es el PID 14132 (este valor es del ejemplo y puede variar en cada entorno).

Ejecutando el comando pstree -pa se muestra la jerarquía de procesos:

• systemd es el proceso raíz

• containerd gestiona el runtime

• containerd-shim-runc-v2 (un proceso por pod)

• pause mantiene los namespaces del pod

• web-server (nginx) / log-reader son los contenedores de aplicación

Ejecutando el comando pstree -pa -H 14132 -p 14132 --show-parents podemos ver claramente la jerarquía de procesos, donde systemd actúa como proceso raíz, containerd gestiona el runtime, y containerd-shim-runc-v2 maneja cada pod individual:

crictl es una aplicación de línea de comandos que permite interactuar con la interfaz CRI (Container Runtime Interface). Podemos utilizarla para inspeccionar los contenedores, consultar información o depurar un contenedor.

El comando crictl pods nos muestra todos los pods ejecutándose en el nodo, incluyendo tanto nuestro pod web-with-logger en el namespace develop como los pods del sistema:

El comando crictl ps --pod bb3b311a34072 podemos ver los contenedores nuestro Pod (no se muestra el pause container).

También nos permite obtener la configuración de todos los Pods que se están ejecutando en un namespace de Kubernetes: crictl inspectp --namespace develop.

El fichero contiene más de 800 líneas, puedes ver el archivo completo en el siguiente gist:

https://gist.github.com/fjvela/5374b33184c4ecbd39259e2d45dcf09d#file-crictl-inspectp-json

A continuación te muestro algunas de los datos más importantes que puedes encontrar en el fichero:

Configuración de Red:

• IP del Pod: 10.244.0.153

• Gateway: 169.254.1.1

• DNS: Configurado para resolver servicios dentro del clúster

• Namespace de red: /var/run/netns/cni-d47bdb8a-6641-6cd2-d33e-55eb78bc2407

Jerarquía de Control Groups:

• Ruta: /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podf07700a5_b996_4b1a_a3af_5f99ecb29549.slice

• Límite de memoria: 268 MB (256 Mi total del Pod)

• Límite de CPU: 100000/100000 (1 CPU core máximo)

Configuración de Seguridad:

• Política Seccomp: Activa con 100+ syscalls permitidas

• Capabilities: Conjunto restringido (CAP_CHOWN, CAP_SETUID, etc.)

• Namespaces aislados: PID, IPC, UTS, Mount, Network

Otros datos importantes:

• Logs: /var/log/pods/develop_web-with-logger_f07700a5-b996-4b1a-a3af-5f99ecb29549

• Imagen pause: mcr.microsoft.com/oss/kubernetes/pause:3.6

Entre los datos que nos muestra el comando, podemos observar la propiedad io.kubernetes.cri.sandbox-log-directory. El valor de la propiedad especifica dónde se almacenan los logs. Al explorar este directorio, encontramos los logs individuales de cada contenedor:

La carpeta /proc contiene el sistema de archivos virtual que almacena información de los procesos que se están ejecutando.

En esta carpeta se encuentra la información sobre los cgroups de nuestro proceso. El comando cat /proc/14132/cgroup muestra la ruta donde se almacena la configuración de cgroups:

Podemos observar que todos los procesos iniciados por containerd están dentro de la jerarquía de cgroups de containerd.

A continuación, comprobamos si los límites de memoria y CPU están configurados en los ficheros de configuración de cgroups. Al examinar los archivos de configuración, podemos verificar que los límites de memoria (134217728 bytes = 128Mi) y CPU (50000/100000 = 500m) están correctamente aplicados:

El comando systemd-cgls nos ayuda a visualizar la jerarquía de cgroups de forma gráfica y sencilla. Permite ver cómo están organizados los procesos y recursos dentro de los diferentes grupos de control, facilitando la identificación de los procesos hijos y su relación con los recursos asignados.

Por último, y no menos importante, comprobamos la configuración de los namespaces. Recordemos que su objetivo es aislar y compartir los recursos del sistema.

El siguiente script muestra los namespaces configurados para cada uno de los procesos que componen el Pod web-with-logger (pid 14132):

SHIM_PID=14132
for pid in $(ps --ppid $SHIM_PID --no-headers -o pid); do
    echo "PID $pid namespaces:"
    ls -la /proc/$pid/ns/ | grep -E "(net|pid|uts|ipc)" | awk '{print "  " $9 ": " $11}'
    echo ""
done

Podemos comprobar que los tres contenedores comparten los siguientes namespaces:

• ipc: Permite que los contenedores compartan mecanismos de comunicación entre procesos (IPC), como semáforos y colas de mensajes.

• net: Todos los contenedores del Pod comparten la misma pila de red, interfaces y dirección IP, lo que posibilita la comunicación interna mediante localhost.

• uts: Compartir este namespace permite que todos los contenedores tengan el mismo hostname y nombre de dominio, facilitando la identificación dentro del Pod.

Gracias al uso de namespaces compartidos, los contenedores de un mismo Pod pueden comunicarse y compartir recursos de manera eficiente y segura.

Comprobamos la configuración de red de cada uno de los procesos:

SHIM_PID=14132
for pid in $(ps --ppid $SHIM_PID --no-headers -o pid); do
    echo "Network interfaces from PID $pid:"
    nsenter -t $pid -n ip addr show eth0 | grep inet
    echo ""
done

Los tres contenedores utilizan la misma IP, lo que permite la comunicación entre ellos a través de localhost.

Comprobamos que los tres contenedores usan el mismo hostname:

SHIM_PID=14132
for pid in $(ps --ppid $SHIM_PID --no-headers -o pid); do
    hostname=$(nsenter -t $pid -u hostname)
    echo "PID $pid hostname: $hostname"
done

Conclusión

“Any sufficiently advanced technology is indistinguishable from magic” - Arthur C. Clarke

Parece trivial ejecutar un contenedor o un Pod en Kubernetes, pero la realidad es mucho más compleja.

El comando para ejecutar un contenedor lanza una coreografía perfecta de acciones en un ecosistema de herramientas y abstracciones que hemos explorado en detalle:

• Primitivas del kernel: namespaces y cgroups

• Runtimes de contenedores: runc y containerd

• Interfaces estándar: CRI y OCI

• Orquestación de contenedores: Kubernetes

Este sistema nos permite obtener portabilidad, escalabilidad y tolerancia a fallos, entre otras ventajas. Cada capa resuelve problemas reales y aporta valor a la solución final.

Sin embargo, cuando algo no funciona correctamente, esta misma complejidad puede convertir un problema simple en una pesadilla que requiere conocimiento profundo para poder resolverla.

Ahora sabes qué sucede realmente cuando Kubernetes hace su “magia”. Ese conocimiento es poder.

Referencias

• https://github.com/containerd/containerd/blob/main/docs/cri/architecture.md

• https://github.com/containerd/containerd/blob/main/docs/cri/config.md

• https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto

• https://github.com/kubernetes/cri-api/blob/master/pkg/apis/services.go

• https://github.com/kubernetes/kubernetes/blob/master/build/pause/linux/pause.c

• https://kubernetes.io/blog/2024/05/01/cri-streaming-explained/

• https://kubernetes.io/docs/concepts/architecture/

• https://kubernetes.io/docs/concepts/overview/components/

• https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

• https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/

Continuamos con la segunda parte de “Desde el kernel hasta la orquestación”, en este artículo vamos a hablar sobre runc y containerd.

En el post Contenedores: Desde el kernel hasta la orquestación - namespaces y control groups (cgroups) vimos los pilares fundamentales sobre los que se ejecutan los contenedores: namespaces y cgroups del kernel de Linux.

Estas funcionalidades del sistema operativo permiten el aislamiento de procesos y el control de los recursos utilizados; trabajar con estas tecnologías requiere un conocimiento del kernel y de los comandos de bajo nivel.

runc y containerd son dos herramientas que actúan como interfaces entre las herramientas de alto nivel y los comandos de bajo nivel, simplificando enormemente el trabajo con contenedores.

Al comienzo, Docker integraba toda la funcionalidad en una aplicación monolítica: gestión de imágenes, networking, almacenamiento, ejecución de contenedores… Esta arquitectura presentaba grandes problemas de dependencia, evolución y control por una única empresa.

En 2015 nació la Open Container Initiative (OCI), su objetivo principal es crear un estándar para el manejo y ejecución de contenedores que hasta el momento estaba dominado por Docker. De esta manera se garantizaba la interoperabilidad entre los diferentes proveedores y permitió crear estándares abiertos para los runtimes de contenedores y el formato de las imágenes, permitiendo así una arquitectura modular y flexible.

Las especificaciones más importantes son las siguientes:

• Distribution Spec (cómo distribuir las imágenes): Define la API REST estándar para la distribución y almacenamiento de imágenes de contenedor, incluyendo operaciones como el envío (push) y la descarga (pull) de imágenes. Esto asegura la interoperabilidad entre diferentes herramientas y registros de imágenes compatibles con OCI.

• Image Spec (formato de las imágenes): Define el formato de la estructura, almacenamiento y referencia de una imagen, garantizando que la imagen creada pueda ser ejecutada por cualquier runtime que cumpla estándar OCI.

• Runtime Spec (cómo ejecutar las imágenes): Define la interfaz entre el runtime de bajo nivel y las herramientas de alto nivel, de esta manera podemos intercambiar el uso de herramientas como containerd o CRI-O sin realizar ninguna modificación.

runc y containerd hacen que trabajar con contenedores sea más sencillo, también son la clave para sistemas de orquestación de contenedores como Kubernetes, que pueden utilizar interfaces estándar sin la necesidad de saber los detalles de la implementación del sistema operativo y de las herramientas utilizadas.

Ambas herramientas eran parte de Docker, fueron extraídas y donadas a la CNCF (Cloud Native Computing Foundation).

runc

Es una herramienta de línea de comandos escrita en Go que solo puede ejecutarse en Linux. Permite ejecutar aplicaciones contenerizadas siguiendo el estándar definido por la Open Container Initiative (OCI).

Aunque proporciona un mayor nivel de abstracción respecto a los comandos del kernel, sigue siendo una utilidad de bajo nivel y normalmente es utilizada por herramientas de más alto nivel.

El estándar definido para la ejecución de contenedores se basa en el concepto de bundle, que consiste en un directorio que contiene un archivo config.json y un directorio rootfs (root filesystem) con el sistema de archivos del contenedor.

El archivo config.json define cómo debe ejecutarse el contenedor. Algunos parámetros que proporciona son los siguientes:

• process: Define qué comando ejecutar, el usuario, las variables de entorno y las capacidades.

• root: Especifica la ruta al sistema de archivos raíz.

• mounts: Lista los puntos de montaje necesarios.

• linux.namespaces: Configura el aislamiento mediante namespaces.

• linux.resources: Establece límites de recursos.

Esta estructura JSON permite que herramientas de alto nivel generen configuraciones complejas.

{
  "ociVersion": "1.2.1",
  "process": {
    "terminal": true,
    "user": {
      "uid": 0,
      "gid": 0
    },
    "args": ["sh"],
    "env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "TERM=xterm"
    ],
    "cwd": "/",
    "capabilities": {
      "bounding": ["CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE"],
      "effective": ["CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE"],
      "permitted": ["CAP_AUDIT_WRITE", "CAP_KILL", "CAP_NET_BIND_SERVICE"]
    },
    "rlimits": [
      {
        "type": "RLIMIT_NOFILE",
        "hard": 1024,
        "soft": 1024
      }
    ],
    "noNewPrivileges": true
  },
  "root": {
    "path": "rootfs",
    "readonly": true
  },
  "hostname": "runc",
  "mounts": [
    {
      "destination": "/proc",
      "type": "proc",
      "source": "proc"
    },
    {
      "destination": "/dev",
      "type": "tmpfs",
      "source": "tmpfs",
      "options": ["nosuid", "strictatime", "mode=755", "size=65536k"]
    },
    {
      "destination": "/dev/pts",
      "type": "devpts",
      "source": "devpts",
      "options": [
        "nosuid",
        "noexec",
        "newinstance",
        "ptmxmode=0666",
        "mode=0620",
        "gid=5"
      ]
    },
    {
      "destination": "/dev/shm",
      "type": "tmpfs",
      "source": "shm",
      "options": ["nosuid", "noexec", "nodev", "mode=1777", "size=65536k"]
    },
    {
      "destination": "/dev/mqueue",
      "type": "mqueue",
      "source": "mqueue",
      "options": ["nosuid", "noexec", "nodev"]
    },
    {
      "destination": "/sys",
      "type": "sysfs",
      "source": "sysfs",
      "options": ["nosuid", "noexec", "nodev", "ro"]
    },
    {
      "destination": "/sys/fs/cgroup",
      "type": "cgroup",
      "source": "cgroup",
      "options": ["nosuid", "noexec", "nodev", "relatime", "ro"]
    }
  ],
  "linux": {
    "resources": {
      "devices": [
        {
          "allow": false,
          "access": "rwm"
        }
      ]
    },
    "namespaces": [
      {
        "type": "pid"
      },
      {
        "type": "network"
      },
      {
        "type": "ipc"
      },
      {
        "type": "uts"
      },
      {
        "type": "mount"
      },
      {
        "type": "cgroup"
      }
    ],
    "maskedPaths": [
      "/proc/acpi",
      "/proc/asound",
      "/proc/kcore",
      "/proc/keys",
      "/proc/latency_stats",
      "/proc/timer_list",
      "/proc/timer_stats",
      "/proc/sched_debug",
      "/sys/firmware",
      "/proc/scsi"
    ],
    "readonlyPaths": [
      "/proc/bus",
      "/proc/fs",
      "/proc/irq",
      "/proc/sys",
      "/proc/sysrq-trigger"
    ]
  }
}

Algunos de los comandos que define el estándar OCI y que runc implementa son:

• events: muestra eventos del contenedor como notificaciones OOM, estadísticas de uso de CPU, memoria e IO.

• create: ejecuta el proceso definido por el usuario en un contenedor creado.

• delete: elimina los recursos asociados al contenedor, utilizado frecuentemente con contenedores en modo desacoplado.

• kill: envía la señal especificada (por defecto: SIGTERM) al proceso principal del contenedor.

• start: inicia el proceso principal.

• state: obtiene el estado actual de un contenedor.

rootfs (root filesystem) es el sistema de archivos raíz del contenedor. Contiene todos los archivos, librerías y herramientas para que el contenedor pueda ejecutarse.

Una estructura típica del sistema de archivos sería:

rootfs/
├── bin/           	# Binarios esenciales (sh, ls, cat, etc.)
├── boot/          	# Archivos de arranque (generalmente vacío)
├── dev/           	# Dispositivos (se monta dinámicamente)
├── etc/           	# Configuraciones del sistema
│   ├── passwd     	# Usuarios del contenedor
│   ├── group      	# Grupos del contenedor
│   ├── hosts      	# Resolución local de nombres
│   └── resolv.conf # Configuración DNS
├── home/          	# Directorios de usuarios
├── lib/           	# Bibliotecas compartidas esenciales
├── lib64/         	# Bibliotecas de 64 bits
├── media/         	# Puntos de montaje para medios removibles
├── mnt/           	# Puntos de montaje temporales
├── opt/           	# Paquetes de software opcionales
├── proc/          	# Sistema de archivos virtual (se monta dinámicamente)
├── root/          	# Directorio home del usuario root
├── run/           	# Datos de runtime
├── sbin/          	# Binarios del sistema
├── srv/           	# Datos de servicios
├── sys/           	# Sistema de archivos virtual (se monta dinámicamente)
├── tmp/           	# Archivos temporales
├── usr/           	# Programas y datos de usuario
│   ├── bin/       	# Binarios de usuario
│   ├── lib/       	# Bibliotecas
│   ├── local/     	# Software local
│   └── share/     	# Datos compartidos
└── var/           	# Datos variables
    ├── log/      	# Logs del sistema
    ├── cache/    	# Cache de aplicaciones
    └── tmp/      	# Archivos temporales adicionales

Sistema de archivos de la imagen Alpine:

rootfs/
├── bin -> /usr/bin
├── etc/
│   ├── alpine-release
│   ├── passwd
│   └── group
├── lib -> /usr/lib
├── sbin -> /usr/sbin
├── usr/
│   ├── bin/
│   │   ├── sh -> /bin/busybox
│   │   ├── ls -> /bin/busybox
│   │   └── cat -> /bin/busybox
│   └── lib/
│       └── libc.musl-x86_64.so.1
└── var/

Sistema de archivos de la imagen Ubuntu:

rootfs/
├── bin/
│   ├── bash
│   ├── sh -> dash
│   └── ls
├── usr/
│   ├── bin/
│   │   ├── python3
│   │   └── apt
│   └── lib/
│       └── x86_64-linux-gnu/
└── lib/
    └── x86_64-linux-gnu/
        ├── libc.so.6
        └── libdl.so.2

containerd

Es un servicio que gestiona el ciclo de vida de los contenedores, implementando los estándares definidos por la OCI.

Actúa como la capa de abstracción entre los orquestadores de contenedores, como Kubernetes, y los runtimes de bajo nivel, como runc.

Las funcionalidades principales de containerd son:

• Image service: Gestiona la descarga, almacenamiento y distribución de imágenes.

  • Pull/Push: Descarga y subida de imágenes desde/hacia registries

  • Gestión de capas: Manejo eficiente de layers con deduplicación

  • Verificación de la integridad de las capas.

  • Recolección de basura (garbage collection).

• Runtime service: Gestiona la ejecución de contenedores.

• Snapshot service: Gestiona los sistemas de archivos (filesystem) de los contenedores.

Podemos interactuar con el servicio utilizando diferentes herramientas:

• ctr: Cliente oficial de bajo nivel para containerd. Permite gestionar imágenes, snapshots y contenedores, principalmente para tareas administrativas y de depuración.

• nerdctl: Interfaz de línea de comandos compatible con Docker, diseñada para usuarios que buscan una experiencia similar a Docker pero utilizando containerd como backend.

• crictl: Herramienta de línea de comandos para interactuar con runtimes compatibles con el estándar CRI (Container Runtime Interface), utilizada principalmente en entornos Kubernetes para inspeccionar y gestionar contenedores.

La configuración del servicio containerd se realiza a través del archivo /etc/containerd/config.toml. Este archivo permite ajustar parámetros clave del servicio, como rutas de almacenamiento, plugins habilitados, configuración de red (CNI), integración con runtimes como runc, y opciones de seguridad.

Un ejemplo de configuración podría ser:

version = 3
root = '/var/lib/containerd'
state = '/run/containerd'
temp = ''
disabled_plugins = []
required_plugins = []
oom_score = 0
imports = []

[grpc]
  address = '/run/containerd/containerd.sock'
  tcp_address = ''
  tcp_tls_ca = ''
  tcp_tls_cert = ''
  tcp_tls_key = ''
  uid = 0
  gid = 0
  max_recv_message_size = 16777216
  max_send_message_size = 16777216

[ttrpc]
  address = ''
  uid = 0
  gid = 0

[debug]
  address = ''
  uid = 0
  gid = 0
  level = ''
  format = ''

[metrics]
  address = ''
  grpc_histogram = false

[plugins]
  [plugins.'io.containerd.cri.v1.images']
    snapshotter = 'overlayfs'
    disable_snapshot_annotations = true
    discard_unpacked_layers = false
    max_concurrent_downloads = 3
    concurrent_layer_fetch_buffer = 0
    image_pull_progress_timeout = '5m0s'
    image_pull_with_sync_fs = false
    stats_collect_period = 10
    use_local_image_pull = false

    [plugins.'io.containerd.cri.v1.images'.pinned_images]
      sandbox = 'registry.k8s.io/pause:3.10'

    [plugins.'io.containerd.cri.v1.images'.registry]
      config_path = ''

    [plugins.'io.containerd.cri.v1.images'.image_decryption]
      key_model = 'node'

  [plugins.'io.containerd.cri.v1.runtime']
    enable_selinux = false
    selinux_category_range = 1024
    max_container_log_line_size = 16384
    disable_apparmor = false
    restrict_oom_score_adj = false
    disable_proc_mount = false
    unset_seccomp_profile = ''
    tolerate_missing_hugetlb_controller = true
    disable_hugetlb_controller = true
    device_ownership_from_security_context = false
    ignore_image_defined_volumes = false
    netns_mounts_under_state_dir = false
    enable_unprivileged_ports = true
    enable_unprivileged_icmp = true
    enable_cdi = true
    cdi_spec_dirs = ['/etc/cdi', '/var/run/cdi']
    drain_exec_sync_io_timeout = '0s'
    ignore_deprecation_warnings = []

    [plugins.'io.containerd.cri.v1.runtime'.containerd]
      default_runtime_name = 'runc'
      ignore_blockio_not_enabled_errors = false
      ignore_rdt_not_enabled_errors = false

      [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes]
        [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
          runtime_type = 'io.containerd.runc.v2'
          runtime_path = ''
          pod_annotations = []
          container_annotations = []
          privileged_without_host_devices = false
          privileged_without_host_devices_all_devices_allowed = false
          cgroup_writable = false
          base_runtime_spec = ''
          cni_conf_dir = ''
          cni_max_conf_num = 0
          snapshotter = ''
          sandboxer = 'podsandbox'
          io_type = ''

          [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
            BinaryName = ''
            CriuImagePath = ''
            CriuWorkPath = ''
            IoGid = 0
            IoUid = 0
            NoNewKeyring = false
            Root = ''
            ShimCgroup = ''

    [plugins.'io.containerd.cri.v1.runtime'.cni]
      bin_dir = ''
      bin_dirs = ['/opt/cni/bin']
      conf_dir = '/etc/cni/net.d'
      max_conf_num = 1
      setup_serially = false
      conf_template = ''
      ip_pref = ''
      use_internal_loopback = false

  [plugins.'io.containerd.differ.v1.erofs']
    mkfs_options = []

  [plugins.'io.containerd.gc.v1.scheduler']
    pause_threshold = 0.02
    deletion_threshold = 0
    mutation_threshold = 100
    schedule_delay = '0s'
    startup_delay = '100ms'

  [plugins.'io.containerd.grpc.v1.cri']
    disable_tcp_service = true
    stream_server_address = '127.0.0.1'
    stream_server_port = '0'
    stream_idle_timeout = '4h0m0s'
    enable_tls_streaming = false

    [plugins.'io.containerd.grpc.v1.cri'.x509_key_pair_streaming]
      tls_cert_file = ''
      tls_key_file = ''

  [plugins.'io.containerd.image-verifier.v1.bindir']
    bin_dir = '/opt/containerd/image-verifier/bin'
    max_verifiers = 10
    per_verifier_timeout = '10s'

  [plugins.'io.containerd.internal.v1.opt']
    path = '/opt/containerd'

  [plugins.'io.containerd.internal.v1.tracing']

  [plugins.'io.containerd.metadata.v1.bolt']
    content_sharing_policy = 'shared'
    no_sync = false

  [plugins.'io.containerd.monitor.container.v1.restart']
    interval = '10s'

  [plugins.'io.containerd.monitor.task.v1.cgroups']
    no_prometheus = false

  [plugins.'io.containerd.nri.v1.nri']
    disable = false
    socket_path = '/var/run/nri/nri.sock'
    plugin_path = '/opt/nri/plugins'
    plugin_config_path = '/etc/nri/conf.d'
    plugin_registration_timeout = '5s'
    plugin_request_timeout = '2s'
    disable_connections = false

  [plugins.'io.containerd.runtime.v2.task']
    platforms = ['linux/arm64/v8']

  [plugins.'io.containerd.service.v1.diff-service']
    default = ['walking']
    sync_fs = false

  [plugins.'io.containerd.service.v1.tasks-service']
    blockio_config_file = ''
    rdt_config_file = ''

  [plugins.'io.containerd.shim.v1.manager']
    env = []

  [plugins.'io.containerd.snapshotter.v1.blockfile']
    root_path = ''
    scratch_file = ''
    fs_type = ''
    mount_options = []
    recreate_scratch = false

  [plugins.'io.containerd.snapshotter.v1.devmapper']
    root_path = ''
    pool_name = ''
    base_image_size = ''
    async_remove = false
    discard_blocks = false
    fs_type = ''
    fs_options = ''

  [plugins.'io.containerd.snapshotter.v1.erofs']
    root_path = ''
    ovl_mount_options = []
    enable_fsverity = false

  [plugins.'io.containerd.snapshotter.v1.native']
    root_path = ''

  [plugins.'io.containerd.snapshotter.v1.overlayfs']
    root_path = ''
    upperdir_label = false
    sync_remove = false
    slow_chown = false
    mount_options = []

  [plugins.'io.containerd.snapshotter.v1.zfs']
    root_path = ''

  [plugins.'io.containerd.tracing.processor.v1.otlp']

  [plugins.'io.containerd.transfer.v1.local']
    max_concurrent_downloads = 3
    concurrent_layer_fetch_buffer = 0
    max_concurrent_uploaded_layers = 3
    check_platform_supported = false
    config_path = ''

[cgroup]
  path = ''

[timeouts]
  'io.containerd.timeout.bolt.open' = '0s'
  'io.containerd.timeout.cri.defercleanup' = '1m0s'
  'io.containerd.timeout.metrics.shimstats' = '2s'
  'io.containerd.timeout.shim.cleanup' = '5s'
  'io.containerd.timeout.shim.load' = '5s'
  'io.containerd.timeout.shim.shutdown' = '3s'
  'io.containerd.timeout.task.state' = '2s'

[stream_processors]
  [stream_processors.'io.containerd.ocicrypt.decoder.v1.tar']
    accepts = ['application/vnd.oci.image.layer.v1.tar+encrypted']
    returns = 'application/vnd.oci.image.layer.v1.tar'
    path = 'ctd-decoder'
    args = ['--decryption-keys-path', '/etc/containerd/ocicrypt/keys']
    env = ['OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf']

  [stream_processors.'io.containerd.ocicrypt.decoder.v1.tar.gzip']
    accepts = ['application/vnd.oci.image.layer.v1.tar+gzip+encrypted']
    returns = 'application/vnd.oci.image.layer.v1.tar+gzip'
    path = 'ctd-decoder'
    args = ['--decryption-keys-path', '/etc/containerd/ocicrypt/keys']
    env = ['OCICRYPT_KEYPROVIDER_CONFIG=/etc/containerd/ocicrypt/ocicrypt_keyprovider.conf']

En configuraciones avanzadas, se pueden definir múltiples runtimes, ajustar el driver de almacenamiento (por ejemplo, overlayfs), configurar la comunicación por sockets, y personalizar la integración con Kubernetes mediante CRI.

Algunos puntos destacados de la configuración:

• General: Define rutas de datos (root, state), plugins habilitados y parámetros globales.

• Comunicación y APIs: Configura los sockets para gRPC y ttrpc, utilizados para la comunicación entre procesos y con los shims.

• CRI (Container Runtime Interface): Permite la integración con Kubernetes, especificando imágenes sandbox, runtimes por defecto y opciones de red.

• Gestión de imágenes: Selección del snapshotter (por ejemplo, overlayfs), deduplicación de capas y políticas de recolección de basura.

• Red (CNI): Define rutas y parámetros para la configuración de red de los contenedores.

• Runtimes: Permite definir y personalizar diferentes runtimes (como runc), así como sus opciones específicas.

La flexibilidad de este archivo permite adaptar containerd a distintos entornos y necesidades, desde laboratorios hasta despliegues en producción con Kubernetes.

Además de containerd, existen otras alternativas para la ejecución de contenedores:

• CRI-O: Un runtime ligero diseñado específicamente para Kubernetes. Implementa la especificación Container Runtime Interface (CRI) y utiliza runc como runtime de bajo nivel.

• Docker Engine: Plataforma ampliamente utilizada para construir, enviar y ejecutar contenedores. Ofrece gestión de imágenes, redes y volúmenes, y emplea internamente containerd y runc.

• Mirantis Container Runtime: Solución empresarial previamente conocida como Docker Engine - Enterprise, certificada para entornos de producción y con características avanzadas de seguridad y soporte extendido.

containerd-shim

Para garantizar que los contenedores sigan funcionando incluso si el proceso principal de containerd se reinicia o actualiza, existe un componente intermedio llamado containerd-shim.

Este shim se sitúa entre containerd y el runtime de bajo nivel (runc), y cumple varias funciones clave para ofrecer la gran resiliencia del sistema:

• Permite que los contenedores continúen ejecutándose de forma independiente al proceso principal de containerd.

• Gestiona la entrada y salida estándar (stdin, stdout, stderr) de los procesos dentro del contenedor.

• Se encarga de recolectar procesos huérfanos (zombies) para evitar fugas de recursos.

• Propaga señales del sistema operativo (como SIGTERM o SIGKILL) al proceso principal del contenedor.

De este modo, cada contenedor tiene su propio proceso shim, lo que mejora la resiliencia y el aislamiento de los contenedores gestionados por containerd.

Ejemplo práctico

Vamos a comprobar la evolución desde comandos del Kernel de Linux hasta las herramientas de alto nivel runc y containerd.

sudo unshare --pid --mount --uts --fork /bin/bash
mount -t proc proc /proc
hostname manual-container
ps aux

1. El comando unshare permite crear nuevos namespaces en Linux, proporcionando una shell de bash que se ejecuta de forma aislada, puntos de montaje y hostname, aunque sigue teniendo acceso al sistema de archivos y procesos del host:

   • --pid: crea un nuevo namespace de PID, donde los procesos tienen su propio espacio de identificadores, comenzando desde 1.

   • --mount: aísla las operaciones de montaje, de modo que los cambios no afectan al host.

   • --uts: crea un namespace UTS, permitiendo modificar el hostname y domainname solo dentro del namespace.

   • --fork: ejecuta el proceso /bin/bash como hijo, haciendo que este sea el proceso principal del nuevo namespace.

2. El comando mount -t proc proc /proc monta un sistema de archivos virtual proc en el nuevo namespace, mostrando solo los procesos del namespace.

3. El comando hostname manual-container cambia el nombre del host dentro del namespace UTS recién creado, sin afectar al sistema principal.

Vamos a utilizar el comando runc para obtener el mismo resultado:

CONTAINER_NAME=manual-container
mkdir $CONTAINER_NAME
cd $CONTAINER_NAME

sudo ctr image pull docker.io/library/alpine:3.22.0

mkdir rootfs

sudo ctr image mount docker.io/library/alpine:3.22.0 rootfs

runc spec

echo $(
  jq '.process.args = ["/bin/sh", "-c", "uname -a && ps aux && sleep 30"]' config.json
) > config.json

sudo runc run $CONTAINER_NAME

1. Creamos un directorio para alojar el sistema de archivos rootfs y la configuración del contenedor (config.json).

2. Descargamos una imagen (por ejemplo, Alpine) para obtener el sistema de archivos base (rootfs).

3. Generamos el archivo de configuración config.json con el comando runc spec.

4. Modificamos el comando de inicio del contenedor para que ejecute uname -a && ps aux && sleep 30.

5. Iniciamos el contenedor con sudo runc run $CONTAINER_NAME.

Ejecutamos el contenedor utilizando containerd:

sudo ctr images pull docker.io/library/alpine:3.22.0
sudo ctr run --rm docker.io/library/alpine:3.22.0 manual-container /bin/sh -c "uname -a && ps aux && sleep 30"

Conclusión

La orquestación y ejecución de contenedores no es una tarea trivial. Los namespaces y cgroups del kernel de Linux proporcionan el aislamiento y control de recursos a bajo nivel. Sobre estos cimientos, herramientas como runc y containerd añaden una capa de abstracción que facilita la gestión, mejora la experiencia de usuario y habilita funcionalidades avanzadas como la recolección de métricas.

Gracias a la estandarización impulsada por la comunidad y organizaciones como la OCI y la CNCF, hoy disponemos de un ecosistema diverso de herramientas (como gVisor, Kata Containers o CRI-O) que permiten adaptar la ejecución de contenedores a diferentes necesidades y escenarios, desde laboratorios hasta entornos de producción y orquestación con Kubernetes.

Con estas bases sólidas, estamos preparados para el siguiente paso: Kubernetes.

Referencias

• https://containerd.io/

• https://github.com/containerd/containerd/blob/main/docs/PLUGINS.md

• https://github.com/opencontainers/containerd

• https://github.com/opencontainers/runc

• https://iximiuz.com/en/posts/you-dont-need-an-image-to-run-a-container/

• https://kubernetes.io/docs/setup/production-environment/container-runtimes/

Este es el primer artículo de la serie “Desde el kernel hasta la orquestación”. El objetivo de los artículos es entender cómo funciona la orquestación de contenedores a más bajo nivel.

Uno de los beneficios de la ejecución y orquestación de contenedores es que no necesitamos preocuparnos por cómo se ejecutan a bajo nivel en la infraestructura.

Es genial tener una abstracción de cómo funciona la tecnología para poder centrarnos en añadir los servicios y la funcionalidad necesaria para nuestras aplicaciones, pero en ocasiones es importante tener el conocimiento de cómo funciona esta tecnología para entender lo que está pasando cuando tenemos una incidencia o necesitamos depurar un problema.

En el siguiente diagrama podemos ver el stack de tecnologías utilizado para la ejecución y orquestación de contenedores. En este post y en los siguientes los iremos desgranando para conocer cómo funcionan entre ellas:

Para comenzar, vamos a hablar sobre namespaces y cgroups (control groups), los cuales son la base de la virtualización de procesos en sistemas operativos que utilizan Linux como base.

Namespaces y cgroups están disponibles desde 2002 y 2008, respectivamente. Utilizándolos de manera conjunta, podemos ejecutar de manera aislada procesos en Linux; además, son las tecnologías utilizadas para la ejecución de contenedores en Linux.

Namespaces (Linux)

No confundir los namespaces en Linux con los namespaces de Kubernetes.

El kernel de Linux incorpora una funcionalidad llamada namespaces, la cual permite aislar y limitar el acceso de un proceso a algunos recursos del sistema.

De esta manera, el proceso puede ejecutarse dentro de su propio entorno sin interferir ni acceder a otros recursos de otros procesos.

Esta funcionalidad se añadió al kernel de Linux en la versión 2.6.24 (2008) y es la base para poder ejecutar contenedores a través de aplicaciones como Docker, LXC, containerd…

Algunos de los tipos de namespaces disponibles en el kernel son los siguientes:

• cgroup namespace (kernel 4.6 - 2016): Permite aislar la vista y manipulación de los grupos de control (cgroups) para los procesos dentro del namespace. Así, los procesos solo pueden gestionar y ver los cgroups a los que pertenecen, sin acceder a los del sistema anfitrión o de otros contenedores. Esto mejora la seguridad y el aislamiento de recursos.

• Inter-process communication (IPC) namespace (kernel 2.4.19 - 2006): Aísla los mecanismos de comunicación entre procesos, como semáforos, colas de mensajes y memoria compartida. Los procesos dentro de un namespace IPC solo pueden comunicarse entre sí, evitando interferencias o accesos no autorizados a recursos IPC de otros namespaces.

• Mount namespace (kernel 2.4.19 - 2002): Permite gestionar qué sistemas de archivos están montados y disponibles para los procesos dentro del namespace. Cada mount namespace puede tener su propio conjunto de puntos de montaje, posibilitando que los contenedores tengan vistas independientes del sistema de archivos y aumentando el aislamiento y la flexibilidad en la gestión de almacenamiento.

• Network namespace (kernel 2.6.29 - 2009): Virtualiza los elementos de red disponibles. Al crear el namespace, solo está disponible el dispositivo loopback. Cada dispositivo solo puede estar asociado a un namespace. Cada namespace tiene su propia IP, tabla de enrutamiento y firewall.

• PID namespace (kernel 2.6.24 - 2008): Permite aislar el espacio de identificadores de procesos (PID). Los procesos dentro de un PID namespace ven solo los procesos que existen en ese namespace, y el primer proceso creado tiene PID 1, similar al proceso init en un sistema Linux tradicional. Esto permite que los contenedores ejecuten sus propios árboles de procesos de manera independiente y facilita la gestión de procesos huérfanos.

• Time namespace (kernel 5.6 - 2020): Permite que los procesos de cada namespace utilicen diferentes offsets de tiempo.

• Unix time-sharing (UTS) namespace (kernel 2.6.19 - 2006): Permite que los procesos dentro de un namespace tengan su propio nombre de host (hostname) y nombre de dominio (domainname). Esto es útil para que los contenedores tengan identificadores de red independientes, aislando la identidad del sistema dentro de cada contenedor.

• User namespace (kernel 3.8 - 2013): Proporciona aislamiento de usuarios y grupos. Los procesos pueden tener diferentes identificadores de usuario (UID) y grupo (GID) dentro del namespace respecto al sistema anfitrión. Esto permite, por ejemplo, que un proceso tenga privilegios de root dentro del contenedor pero sea un usuario sin privilegios fuera de él, mejorando la seguridad.

cgroups (control groups)

cgroups es la abreviación de control groups. Esta funcionalidad del kernel de Linux permite establecer el control sobre la cantidad de recursos que un proceso puede utilizar. De esta manera, evitamos que un proceso que necesite hacer un uso intensivo de la CPU pueda interferir con otros procesos que estamos ejecutando en la misma máquina. Las principales características son:

• Limitación de recursos: permite establecer límites sobre el uso de CPU, memoria, I/O y número máximo de archivos abiertos por grupo de procesos.

• Priorización: posibilita asignar diferentes prioridades de acceso a los recursos entre distintos grupos de procesos.

• Accounting (facturación): proporciona métricas detalladas sobre el consumo de recursos, útiles para monitorización y facturación.

• Control: permite pausar (congelar) o reanudar la ejecución de un grupo de procesos.

• Jerarquía: en cgroup v1, los grupos pueden organizarse jerárquicamente, permitiendo heredar límites y configuraciones entre padres e hijos.

Esta versión presenta algunos problemas de uso:

• Es complejo administrar múltiples jerarquías.

• Inconsistencia entre diferentes controladores.

• Dificultad para delegar privilegios de manera segura.

En 2016, con la versión del kernel 4.5, llega la versión 2 de cgroup. Las principales mejoras son:

• Jerarquía unificada: todos los controladores que componen cgroup comparten una única jerarquía; la estructura es más simple y coherente. Cada proceso pertenece solo a un cgroup.

• Actualización de los controladores que componen cgroup:

  • CPU: Control unificado de uso de CPU (bandwidth y cuotas).

  • Memoria: Gestión avanzada de memoria, con soporte para swapping y límites más precisos.

  • IO: Sustituye a blkio, ofreciendo una contabilidad y control de entrada/salida más eficiente.

  • RDMA (Remote Direct Memory Access): Permite a los procesos acceder directamente a la memoria de otros sistemas a través de la red, sin intervención del procesador ni del sistema operativo remoto. Esto mejora el rendimiento en aplicaciones que requieren baja latencia y alto ancho de banda, como bases de datos distribuidas o sistemas de almacenamiento de alto rendimiento.

  • PIDS: Permite establecer límites en la cantidad de procesos que puede crear un grupo, evitando el agotamiento de recursos por exceso de procesos.

• Funcionalidades mejoradas en CPU y memoria: cgroup v2 ofrece un control más granular y eficiente sobre el uso de CPU y memoria. Por ejemplo, permite definir cuotas y prioridades de CPU de forma más precisa, así como establecer límites de memoria más estrictos y gestionar mejor situaciones de presión de memoria. Además, la gestión de memoria swap es más flexible, lo que ayuda a evitar situaciones de OOM (Out Of Memory).

• Delegación segura: cgroup v2 introduce mecanismos más robustos para delegar la administración de subgrupos a procesos sin privilegios. Esto significa que los usuarios pueden gestionar sus propios recursos y crear jerarquías de cgroups dentro de los límites establecidos por el administrador del sistema, sin necesidad de privilegios elevados. Esta funcionalidad mejora la seguridad y facilita la multi-tenencia, permitiendo que diferentes usuarios o aplicaciones gestionen sus propios recursos de manera aislada y controlada, sin comprometer la integridad del sistema anfitrión.

• Semántica mejorada: los límites de recursos son más predecibles y consistentes entre los distintos controladores, lo que facilita la configuración y reduce comportamientos inesperados. Además, se han mejorado las métricas de consumo y la gestión de situaciones de OOM (Out Of Memory), permitiendo una monitorización y respuesta más precisa ante el agotamiento de recursos.

Gracias a esta versión se ha mejorado el aislamiento de recursos entre contenedores y se permite limitar los recursos de una manera más precisa.

Desde la versión 1.25, en Kubernetes cgroups v2 está activado por defecto.

Ejemplo práctico

Vamos a comprobar cómo podemos ejecutar procesos limitando el uso de CPU y memoria.

Antes de continuar, verifica si tu máquina utiliza cgroups v2 ejecutando el comando mount | grep cgroup.

• Si ves múltiples montajes, estás usando cgroups v1.

• Si ves solo un montaje de tipo cgroup2, estás usando cgroups v2.

Otra forma de comprobarlo es ejecutar ls /sys/fs/cgroup/cgroup.controllers. Si el comando falla, tienes cgroups v1; si muestra contenido, tienes cgroups v2.

Estructura de directorios en cgroups v1:

/sys/fs/cgroup/
├── blkio/           # Control de I/O de bloques
├── cpu/             # Control de CPU
├── cpuacct/         # Contabilidad de CPU  
├── memory/          # Control de memoria
├── devices/         # Control de dispositivos
├── freezer/         # Congelar/descongelar procesos
├── net_cls/         # Clasificación de red
├── pids/            # Control de número de procesos
└── systemd/         # Jerarquía de systemd

Estructura de directorios en cgroups v2:

/sys/fs/cgroup/
├── cgroup.controllers      # Controladores disponibles
├── cgroup.procs           # Procesos en este cgroup
├── cgroup.subtree_control # Controladores habilitados
├── cpu.max                # Límite máximo de CPU
├── memory.max             # Límite máximo de memoria
├── io.max                 # Límite máximo de I/O
├── pids.max               # Límite máximo de procesos
└── user.slice/            # Jerarquía de systemd
    ├── system.slice/
    └── docker.slice/

El directorio /sys/fs/cgroup/ es el estándar para las interfaces del kernel:

• sys: Interfaces del kernel

• fs: Sistemas de archivos especiales

• cgroup: Subsistema cgroups

Al crear un directorio en /sys/fs/cgroup/, se generan automáticamente los archivos necesarios para configurar un nuevo cgroup:

sudo mkdir /sys/fs/cgroup/my-group/

El número de archivos puede variar según los controladores activos. Puedes consultar los controladores disponibles con cat /sys/fs/cgroup/cgroup.controllers.

Existen varios métodos para configurar un cgroup:

1. Editar directamente los archivos.

2. Usar los binarios del paquete cgroup-tools (libcgroup).

3. Utilizar el comando systemd-run.

Para limitar la memoria de un cgroup:

echo "10M" | sudo tee /sys/fs/cgroup/my-group/memory.max

Para limitar el uso de CPU al 25%:

echo "25000 100000" | sudo tee /sys/fs/cgroup/my-group/cpu.max

Puedes comprobar su funcionamiento utilizando la herramienta stress-ng:

sudo bash -c "echo $$ > /sys/fs/cgroup/my-group/cgroup.procs && exec stress-ng --vm 1 --vm-bytes 200M"

También puedes usar los comandos de cgroup-tools (libcgroup):

datawrapper.dwcdn.net/1rKVm/1/

sudo cgcreate -g memory,cpu:/my-group

sudo cgset -r memory.max=10M my-group     
sudo cgset -r cpu.max="25000 100000" my-group

sudo cgexec -g memory,cpu:my-group stress-ng --vm 1 --vm-bytes 200M

systemd-run es la herramienta recomendada para gestionar procesos, ya que systemd es el principal gestor de cgroups (v2) en Linux y simplifica la ejecución de comandos bajo restricciones de recursos:

systemd-run --scope -p MemoryMax=10M stress-ng --vm 1 --vm-bytes 200M --timeout 30s

Otro ejemplo más avanzado, limitando CPU, memoria e IO:

systemd-run --unit=backup-job \
  -p CPUQuota=20% \
  -p IOWeight=50 \
  -p MemoryMax=1G \
  tar czf /backup/system-$(date +%Y%m%d).tar.gz /home

Podemos utilizar de manera conjunta cgroups y namespaces. El siguiente ejemplo crea un nuevo cgroup, limitando la memoria a 256 megabytes, el uso de CPU al 25% y el número máximo de procesos a 10:

sudo mkdir /sys/fs/cgroup/my-container
echo "+memory +cpu +pids" | sudo tee /sys/fs/cgroup/cgroup.subtree_control
echo "256M" | sudo tee /sys/fs/cgroup/my-container/memory.max
echo "25000 100000" | sudo tee /sys/fs/cgroup/my-container/cpu.max
echo "10" | sudo tee /sys/fs/cgroup/my-container/pids.max

sudo unshare --pid --net --mount --uts --fork bash -c "
  echo \$\$ > /sys/fs/cgroup/my-container/cgroup.procs
  hostname my-container
  mount -t proc proc /proc
  exec bash
"

Estos ejemplos permiten experimentar y comprender de forma práctica cómo los cgroups y namespaces trabajan juntos para aislar y limitar recursos en Linux.

Resumen

Aunque puedan parecer similares, namespaces y cgroups cumplen roles complementarios en la virtualización de procesos en Linux:

• Namespaces proporcionan aislamiento: cada contenedor tiene su propia vista del sistema operativo, incluyendo red, procesos, sistema de archivos, usuarios, etc. Esto significa que los procesos dentro de un contenedor no pueden ver ni interactuar directamente con los recursos de otros contenedores o del sistema anfitrión.

• cgroups proporcionan control de recursos: permiten limitar, priorizar y monitorizar el uso de recursos como CPU, memoria, almacenamiento y procesos para cada grupo de procesos. Así, se evita que un contenedor consuma todos los recursos del sistema y afecte a los demás.

La combinación de ambas tecnologías es lo que permite ejecutar múltiples aplicaciones de forma segura, aislada y eficiente en el mismo kernel Linux. Cada contenedor se ejecuta en su propio espacio aislado (gracias a los namespaces) y con recursos controlados (gracias a los cgroups).

En resumen, los namespaces aíslan qué puede ver y hacer un proceso, mientras que los cgroups controlan cuánto puede consumir. Juntos, hacen posible la ejecución de contenedores tal y como los conocemos hoy.

Referencias

• https://earthly.dev/blog/namespaces-and-cgroups-docker/

• https://en.wikipedia.org/wiki/Cgroups

• https://en.wikipedia.org/wiki/linux_namespaces

• https://kubernetes.io/docs/concepts/architecture/cgroups/

• https://lwn.net/Articles/259217/

• https://man7.org/linux/man-pages/man7/cgroups.7.html

• https://www.redhat.com/en/blog/cgroups-part-four

Cuando trabajamos con contenedores, podemos utilizar diferentes patrones para ejecutar nuestras aplicaciones.

Algunos de ellos son:

• Sidecar: Contenedor que extiende funcionalidad (logging, monitoring).

• Ambassador: Proxy para comunicaciones externas.

• Adapter: Transforma datos para compatibilidad.

• Init Container: Crea y configura parte de la aplicación antes de que se ejecute el contenedor del Pod.

En este post vamos a hablar del patrón sidecar container. El objetivo de este patrón es que uno o varios contenedores extiendan la funcionalidad principal de otro contenedor.

Imagina que necesitas extraer parte de la información generada por tu aplicación. En vez de incluir esta funcionalidad dentro de tu aplicación, haciéndola más pesada, delegamos este trabajo en otra aplicación que se despliega junto a la tuya, leyendo y extrayendo la información generada.

Desde la versión Kubernetes 1.28 Planternetes (alpha), se soporta la configuración de este patrón de manera nativa, y desde la versión 1.33 Octarine (stable) está disponible de forma estable.

A continuación, mostramos cómo podemos utilizarlo.

¿Cómo crear un sidecar container sin utilizar el soporte nativo de Kubernetes?

Antes de que Kubernetes incluyera el soporte nativo de sidecar containers, podíamos aplicar el patrón de la siguiente manera:

apiVersion: v1
kind: Pod
metadata:
  name: web-with-logger
spec:
  containers:
  - name: web-server
    image: nginx:alpine
    ports:
    - containerPort: 80
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  - name: log-reader
    image: busybox
    command: ["sh", "-c"]
    args:
    - |
      while true; do
        if [ -f /logs/access.log ]; then
          tail -n 5 /logs/access.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs

  volumes:
  - name: shared-logs
    emptyDir: {}

Esta manera de utilizar sidecar containers en Kubernetes presenta algunos problemas en ciertos casos:

• Jobs: el Pod no termina hasta que todos los contenedores finalizan.

• Los contenedores que procesan logs y métricas necesitan un orden específico de ejecución para evitar la pérdida de datos.

• Service mesh: necesitan arrancar y estar en funcionamiento antes que el resto de los contenedores para ejecutar tareas relacionadas con el enrutamiento o la seguridad.

¿Cómo crear un sidecar container de manera nativa en Kubernetes?

La implementación nativa de sidecar containers se ha realizado utilizando la funcionalidad initContainers. Para ello, debemos especificar el valor Always en la propiedad restartPolicy del contenedor (si utilizamos otro valor, Kubernetes no ejecuta los contenedores como sidecar containers).

De esta manera, un sidecar container puede iniciarse, pararse o reiniciarse sin afectar al resto de contenedores que componen el Pod.

apiVersion: v1
kind: Pod
metadata:
  name: web-with-logger
spec:
  initContainers:
  - name: log-reader
    image: busybox
    command: ["sh", "-c"]
    restartPolicy: Always
    args:
    - |
      while true; do
        if [ -f /logs/access.log ]; then
          tail -n 5 /logs/access.log
        fi
        sleep 10
      done
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
  containers:
  - name: web-server
    image: nginx:alpine
    ports:
    - containerPort: 80
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/nginx

  volumes:
  - name: shared-logs
    emptyDir: {}

Definiendo el valor Always en la propiedad restartPolicy, el contenedor se ejecutará durante todo el ciclo de vida del Pod y nos garantizará el orden correcto de ejecución de cada uno de los contenedores, siendo los definidos en initContainers los primeros en ejecutarse.

Cuando se inicia el proceso de finalización del Pod, kubelet pospone la finalización de los contenedores definidos en initContainers hasta que los contenedores definidos en la propiedad containers hayan finalizado, garantizando así hasta el final del ciclo de vida del Pod el funcionamiento de los sidecar containers.

Conclusión

Aunque la implementación mediante initContainers y la propiedad restartPolicy puede resultar menos intuitiva para definir los sidecar containers de nuestro Pod, creo que contar con soporte nativo en Kubernetes simplifica significativamente la aplicación de este patrón, resolviendo los problemas de orquestación entre los contenedores y garantizando su correcto funcionamiento.

Referencias

• https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md

• https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/

• https://kubernetes.io/blog/2023/08/15/kubernetes-v1-28-release/

• https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/

Puedes encontrar el código fuente del post en el siguiente enlace: https://github.com/fjvela/cosign-trivy-kyverno-in-action

Introducción

Vamos a describir cómo podemos verificar la autenticidad e integridad de una imagen firmada en el proceso de integración continua y cómo verificar un attestation (información verificable sobre la imagen: revisión código fuente, escaneo de vulnerabilidades…) con la información de las vulnerabilidades de la imagen antes de ejecutar la imagen en un cluster Kubernetes.

Para ello vamos a utilizar las siguientes herramientas:

• Cosign

• Kyverno

• Trivy

Cosign

Cosign es una herramienta creada por el proyecto Sigstore que nos permite firmar imágenes Docker y otros artefactos software.

Su principal función es proporcionar una forma sencilla y segura de firmar digitalmente software, permitiendo verificar posteriormente su autenticidad e integridad.

Las firmas se pueden almacenar junto con las imágenes en un registro de imágenes compatible con OCI (Open Container Initiative).

Por defecto, Cosign firma los artefactos software utilizando el modo Keyless, para ello utiliza Fulcio como entidad certificadora y Rekor como transparency log. En caso de que fuera necesario también es posible realizar la firma utilizando nuestro certificado.

Una attestation es una “declaración” firmada que contiene metadatos sobre la imagen Docker. Pueden incluir información sobre un escaneo de vulnerabilidades de la imagen o información de cómo se ha generado. Estas se almacenan en el registro de imágenes junto con la imagen y pueden ser verificadas por Cosign o por otras herramientas cómo Kyverno.

Trivy

Trivy es un escáner de seguridad que nos permite escanear diferentes elementos como:

• Imágenes

• Ficheros

• Repositorios Git

• cluster de Kubernetes

Dispone de distintos tipos de escáneres que podemos ejecutar en cualquier momento dentro de nuestros procesos de CI/CD:

• Escaneo de vulnerabilidades (CVEs)

• Paquetes y dependencias (SBOM)

• Configuraciones en el código de infraestructura (IaC)

• Información sensible (contraseñas y secretos)

Kyverno

Kyverno es gestor de políticas que nos va a permitir validar y/o modificar las peticiones de creación o modificación de los elementos de un cluster de Kubernetes. Para que esto sea posible, Kyverno se configura en el cluster como un Admission controller para recibir todas las peticiones realizadas a la API de Kubernetes.

Las políticas se definen utilizando YAML, eliminando así la necesidad de aprender lenguajes específicos. Estas políticas permiten verificar si las imágenes han sido firmadas o si los elementos creados en el cluster cumplen con nuestros estándares de calidad y seguridad.

Generación de la imagen y firma

Para poder continuar instala las siguientes herramientas:

• Docker

• Cosign

• Trivy

Antes de comenzar con el proceso debes autenticarte en el almacén de imágenes que vayas a utilizar (si usas GitHub: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry)

1. Generamos nuestra imagen: docker build . -t ghcr.io/fjvela/blog-demo-image-sign-attestation:1.0.0

2. Almacenamos la imagen generada en nuestro contenedor de imágenes: docker push ghcr.io/fjvela/blog-demo-image-sign-attestation:1.0.0

3. Obtenemos el digest (el valor es único por cada imagen generada y nos aseguramos que estamos firmando la imagen que queremos) de la imagen generada: docker inspect --format='{{index .RepoDigests}}' ghcr.io/fjvela/blog-demo-image-sign-attestation:1.0.0

4. Firmamos la imagen con Cosign cosign sign ghcr.io/fjvela/blog-demo-image-sign-attestation@sha256:76e0af3bda5badd9b8e9772903bfdc8d5e2810f647ea6942e73d913a467c2cff.

Cuando ejecutamos el comando cosign sign se ejecutan las siguientes acciones:

• Se verifica nuestra identidad a través de un Identity provider.

• Una vez obtenido un OIDC token, Cosign solicita un certificado (válido durante 10 minutos) a una entidad certificadora. En este caso a Fulcio, el cual emite certificados efímeros basados en identidades OIDC para firmar artefactos de software de forma segura.

• Se firma la imagen con el certificado, se genera un timestamp. A través de la información del timestamp podemos:

  • Demostrar cuándo se creó la firma

  • Ayuda a prevenir ataques de repetición

  • Proporciona una línea temporal auditable de la firma del contenedor

  • Permite decisiones de políticas basadas en tiempo en controladores de admisión como Kyverno

• Toda la información se almacena en nuestro container registry.

• La información sobre el certificado, la firma y el timestamp se envía a Rekor. Rekor es un registro inmutable y transparente (transparency log) que almacena y permite verificar firmas digitales y metadatos de artefactos de software.

Creación informe de vulnerabilidades y attestation

Una vez firmada la imagen, generamos un informe con las vulnerabilidades de la imagen que hemos generado. El siguiente comando nos proporciona el formato necesario para poder crear un attestation utilizando cosign:

trivy image --ignore-unfixed --format cosign-vuln --output vuln.json ghcr.io/fjvela/blog-demo-image-sign-attestation@sha256:76e0af3bda5badd9b8e9772903bfdc8d5e2810f647ea6942e73d913a467c2cff

Creamos el attestation utilizando cosign:

cosign attest --type vuln --predicate vuln.json ghcr.io/fjvela/blog-demo-image-sign-attestation@sha256:76e0af3bda5badd9b8e9772903bfdc8d5e2810f647ea6942e73d913a467c2cff

Puedes consultar los tipos de attestation que puedes incluir en el siguiente enlace: https://docs.sigstore.dev/cosign/verifying/attestation/

Con los siguientes comandos, se puede verificar la firma e información incluida en el attestation:

cosign verify ghcr.io/fjvela/blog-demo-image-sign-attestation@sha256:76e0af3bda5badd9b8e9772903bfdc8d5e2810f647ea6942e73d913a467c2cff

cosign verify-attestation --type vuln ghcr.io/fjvela/blog-demo-image-sign-attestation@sha256:76e0af3bda5badd9b8e9772903bfdc8d5e2810f647ea6942e73d913a467c2cff

Verificación de firma y del escaneo de vulnerabilidades utilizando Kyverno

En el siguiente enlace puedes consultar cómo instalar Kyverno en un cluster Kubernetes: https://kyverno.io/docs/installation/methods. Kyverno se despliega en el cluster cómo un Admission Controller, si lo vas a utilizar en producción es importante que revises la siguiente información: https://kyverno.io/docs/introduction/admission-controllers/

Kyverno soporta diferentes tipos de políticas. El tipo verifyImages nos permite realizar comprobaciones sobre las imágenes que se despliegan en nuestro cluster. También dispone de una amplia galería de políticas ya creadas y que nos pueden servir como base para crear nuestras propias políticas.

Partiendo de la política Require Image Vulnerability Scans:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-vulnerability-scan
spec:
  validationFailureAction: Audit
  webhookTimeoutSeconds: 10
  failurePolicy: Fail
  rules:
    - name: scan-not-older-than-one-week
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - mutateDigest: false
          imageReferences:
            - "ghcr.io/fjvela/blog-demo-image-sign-attestation*"
          attestors:
            - entries:
                - keyless:
                    subject: "YOUR_EMAIL"
                    issuer: "https://github.com/login/oauth"
                    rekor:
                      url: https://rekor.sigstore.dev
          attestations:
            - type: https://cosign.sigstore.dev/attestation/vuln/v1
              attestors:
                - entries:
                    - keyless:
                        subject: "YOUR_EMAIL"
                        issuer: "https://github.com/login/oauth"
                        rekor:
                          url: https://rekor.sigstore.dev
              conditions:
                - all:
                    - key: "{{ time_since('','{{metadata.scanFinishedOn}}','') }}"
                      operator: LessThanOrEquals
                      value: "1h"

Conclusión

Como has podido comprobar, la combinación de Cosign para la firma digital, Trivy para el análisis de vulnerabilidades y Kyverno para la gestión de políticas de seguridad en Kubernetes, nos proporciona una manera sencilla de comprobar la integridad y autenticidad de las imágenes que desplegamos en un cluster Kubernetes.

La combinación de estas herramientas nos permite:

• Asegurar la integridad y autenticidad de nuestras imágenes mediante firmas digitales

• Detectar vulnerabilidades de seguridad antes del despliegue

• Automatizar la verificación de seguridad durante el despliegue en Kubernetes

• Mantener un registro inmutable de todas las firmas y attestations

Referencias

• https://docs.sigstore.dev/cosign/signing/signing_with_containers/

• https://docs.sigstore.dev/logging/overview/

• https://github.com/sigstore/fulcio

• https://github.com/sigstore/rekor

• https://kyverno.io/

• https://trivy.dev/latest/

Puedes encontrar el código fuente del post en el siguiente enlace: https://github.com/fjvela/blog-demo-azure-ad-workload-identity

Introducción

En el siguiente post voy a explicar cómo puedes utilizar Azure Managed Identities y Azure Federated Identity Credentials desde un cluster Kubernetes desplegado en Azure. Esto permitirá a las aplicaciones que se ejecutan en el cluster acceder a servicios desplegados en Azure sin necesidad de utilizar credenciales.

Antes de continuar leyendo el post, te recomiendo que leas los posts sobre Azure Managed Identities y Azure Federated Identity Credentials.

En los posts mencionados, explico cómo acceder a los recursos desplegados en Azure sin necesidad de gestionar secretos y/o certificados:

• Azure Managed Identities: Se usan en aplicaciones que se ejecutan en servicios de Azure (ej. máquinas virtuales).

• Azure Federated Identity Credentials: Se usan en aplicaciones y servicios que se ejecutan fuera de Azure (ej. GitHub Workflow).

¿Cómo funciona?

Una federated identity credential permite establecer una relación de confianza entre una User managed identity y un proveedor de identidad externo (external identity provider IdP).

Esta relación permite a Microsoft Identity autenticar una aplicación externa a través del token recibido y el IdP configurado, generando a su vez otro token que permitirá a la aplicación acceder a los recursos desplegados en Azure.

Tras crear la user managed identity, podemos configurar hasta un máximo de 20 federated identity credentials.

Para aplicaciones desplegadas en un cluster de Kubernetes, se requiere la siguiente información:

• issuer: Dirección URL del proveedor de identidades externo del cluster (IdP).

• namespace: Nombre del namespace donde se ejecutarán los pods.

• service account: Nombre del service account (SA) asociado a los pods de nuestro workload.

• audiences: Indica qué plataforma de identidad de Microsoft debe aceptar el token entrante (por defecto: api://AzureADTokenExchange - el valor depende del entorno cloud utilizado - Fairfax, Mooncake, USNat o USSec).

Nota: La combinación de namespace y service account debe ser única en la user managed identity.

1. Cuando Kubernetes inicia un nuevo POD, AD Workload Identity crea un token en un path determinado.

2. La aplicación solicita un token a Microsoft identity platform, utilizando el token generado en el paso 1.

3. Microsoft identity platform valida el token incluido en la petición contra el servicio de validación externo que se ha registrado previamente (OIDC del cluster). Si el token es válido, se genera un token de autenticación para autenticarse contra otros servicios desplegados en Azure (hay que asignar los permisos necesarios en el servicio).

4. La aplicación utiliza el token generado para acceder a los recursos desplegados en Azure.

Configurar federated identity credentials (Kubernetes)

Para comenzar, necesitamos un proveedor de identidad externo para crear la relación de confianza entre nuestro cluster y las managed identities utilizadas por las aplicaciones que se ejecutan en nuestro cluster.

Azure nos proporciona el servicio OpenID Connect (OIDC). Para activarlo podemos usar el siguiente comando:

az aks update --resource-group myResourceGroup --name myAKScluster --enable-oidc-issuer

Si estás utilizando Amazon Elastic Kubernetes (EKS) o Google Kubernetes Engine (GKE) revisa la siguiente documentación:

• https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

• https://cloud.google.com/kubernetes-engine/enterprise/identity/setup/per-cluster

A continuación, vamos a configurar una federated identity credential para permitir que la aplicación pueda acceder a recursos desplegados en Azure.

Desde el menú “Managed Identities” podemos crear una User Managed Identity.

Una vez creada, añadimos una federated identity credential:

1. Azure nos da la opción de configuración para diferentes escenarios, en nuestro caso seleccionamos la opción para configurar Kubernetes.

2. Completamos la información que nos solicita:

• Namespace donde se ejecuta la aplicación.

• Service Account (SA) que utiliza la aplicación.

• URL del emisor de OIDC de nuestro cluster, puedes consultarla en el portal o través del comando: az aks show --name myAKScluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv.

Después de crear la user managed identity y configurados los federated identity credentials, debemos asignar los permisos correspondientes de acceso.

Como acceder a un recurso en Azure utilizando una Managed Identity utilizando .NET

Podemos hacer uso de las Managed Identities creadas en Azure a través de los diferentes SDKs disponibles.

Vamos a describir cómo podemos acceder a un Azure Key Vault utilizando código .NET y la librería Azure.Identity:

1. Crea un proyecto .NET, en este caso hemos creado un proyecto tipo Web.

2. Añade la referencia a la librería Azure.Identity dotnet add package Azure.Identity.

Azure.Identity proporciona varias clases que encapsulan la lógica necesaria para poder obtener un token de autenticación de Microsoft Entra ID haciendo uso de la Managed Identity configurada:

DefaultAzureCredential: Intenta realizar la autenticación a través de diferentes mecanismos hasta que consigue conectarse con uno de ellos.

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

ChainedTokenCredential: Intenta realizar la autenticación a través de la Managed Identity. Si no lo consigue, intenta conectarse a través de Azure CLI

var credential = new ChainedTokenCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

ManagedIdentityCredential: Utiliza la Managed Identity para solicitar el token de autenticación

var credential = new ManagedIdentityCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

El código final de nuestro API controlador es el siguiente:

 [ApiController]
 [Route("[controller]")]
 public class SecretController : ControllerBase
 {
     private readonly ILogger<SecretController> _logger;
     private readonly IConfiguration _config;

     public SecretController(ILogger<SecretController> logger, IConfiguration config)
     {
         _logger = logger;
         _config = config;
     }

     [HttpGet(Name = "GetSecret")]
     public IActionResult Get(string name, string credentialType = "DefaultAzureCredential")
     {
         var kvName = _config["KV_NAME"];
         _logger.LogInformation($"C# HTTP trigger function processed a request. {name} {credentialType} {kvName}");

         var tokenCredential = GetTokenCredential(credentialType);
         var client = new SecretClient(new Uri($"https://{kvName}.vault.azure.net/"), tokenCredential);

         return new OkObjectResult(client.GetSecret(name));
     }

     private TokenCredential GetTokenCredential(string credentialType)
     {
         switch (credentialType)
         {
             case "DefaultAzureCredential":
                 return new DefaultAzureCredential();
             case "ChainedTokenCredential":
                 return new ChainedTokenCredential();
             case "ManagedIdentityCredential":
                 return new ManagedIdentityCredential();
         }

         throw new Exception($"The credential type {credentialType} is not valid");
     }
 }

Como configurar Managed Identity en el cluster

Para configurar la Managed Identity en el cluster es necesario crear y asignar una Service Account (SA) a nuestra aplicación.

Utilizando las anotaciones azure.workload.identity/client-id y azure.workload.identity/tenant-id podemos configurar la Managed Identity creada previamente y que utilizaremos con nuestra aplicación. A continuación puedes ver un ejemplo:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-app-1
  namespace: develop
  annotations:
    azure.workload.identity/client-id: "3d49c3ea-369c-4af2-b770-3a5de4d0aca2"
    azure.workload.identity/tenant-id: "xxxxxx-xxx-x-x-x"

Además es necesario añadir la etiqueta azure.workload.identity/use a los pods de nuestra aplicación para indicarle a Azure AD Workload Identity que debe crear un token de autenticación en el POD utilizando los datos de configuración proporcionados en la Service Account (SA).

A continuación puedes encontrar el código yaml necesario para desplegar la aplicación en el cluster kubernetes haciendo uso de una Managed Identity creada previamente:

apiVersion: v1
kind: Namespace
metadata:
  name: develop
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-app-1
  namespace: develop
  annotations:
    azure.workload.identity/client-id: "3d49c3ea-369c-4af2-b770-3a5de4d0aca2"
    azure.workload.identity/tenant-id: "xxxxxx-xxx-x-x-x"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: myapp
  name: myapp
  namespace: develop
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  strategy: {}
  template:
    metadata:
      labels:
        app: myapp
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: sa-app-1
      containers:
        - image: acrqi99.azurecr.io/app:1.0.0
          name: app
          ports:
            - containerPort: 8080
          env:
            - name: KV_NAME
              value: kv-qi99
          resources: {}

Una vez desplegada la aplicación podemos comprobar como Azure AD Workload Identity ha modificado la configuración del POD para que la aplicación pueda acceder a los servicios desplegados en Azure haciendo uso de la Managed Identity configurada:

Realizando una llamada GET para consultar la información del secreto secret-sauce, podemos comprobar que la Managed Identity ha sido configurada correctamente:

Conclusión

La implementación de Azure Managed Identities junto con Azure Federated Identity Credentials y Azure AD Workload Identity proporciona una solución robusta y segura para gestionar el acceso a servicios de Azure a aplicaciones que se ejecutan en un cluster de Kubernetes.

Esta solución elimina la necesidad de gestionar credenciales manualmente, reduciendo significativamente los riesgos de seguridad asociados con el manejo de secretos y certificados.

Las ventajas principales de esta solución son:

• Eliminar la gestión manual de credenciales.

• Mayor seguridad al no almacenar secretos en el código o en el cluster.

• Escalabilidad para múltiples aplicaciones y servicios.

• Compatibilidad con múltiples entornos y proveedores de Kubernetes.

Referencias

• https://azure.github.io/azure-workload-identity/docs/

• https://learn.microsoft.com/en-us/azure/aks/aks/use-oidc-issuer

• https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

• https://cloud.google.com/kubernetes-engine/enterprise/identity/setup/per-cluster

Puedes encontrar el código fuente del post en el siguiente enlace: https://github.com/fjvela/blog-demo-federated-identity-credential

Introducción

En el post Azure Managed Identities revisamos cómo funcionan y cómo podemos utilizar Managed Identities. Estas nos permiten autenticarnos contra servicios de Azure u otras aplicaciones desplegadas en Azure sin necesidad de gestionar secretos y/o certificados.

Existen otros escenarios donde las aplicaciones o servicios desplegados fuera de Azure necesitan acceder a recursos desplegados en Azure.

Rotar y/o guardar secretos o certificados puede ser tedioso, además supone un riesgo para la seguridad ya que cualquiera que disponga de esta información podría acceder a estos servicios.

Las federated identity credentials nos van a permitir autenticar aplicaciones y servicios externos sin necesidad de gestionar secretos o certificados.

¿Cómo funciona?

Una federated identity credential permite establecer una relación de confianza entre una User managed identity y un proveedor de identidad externo (external identity provider IdP).

Esta relación va a permitir a Microsoft Identity autenticar a una aplicación externa a través del token recibido y el IdP configurado, generando a su vez otro token que permitirá a la aplicación acceder a los recursos desplegados en Azure.

Una vez creada la user managed identity, podemos configurar hasta un máximo de 20 federated identity credentials.

La información necesaria es la siguiente:

• issuer: Dirección URL del proveedor de identidades externo (IdP).

• subject: Es el identificador de la aplicación externa, el formato depende del proveedor de identidad externo (IdP).

• audiences: Indica qué plataforma de identidad de Microsoft debe aceptar el token entrante (por defecto: api://AzureADTokenExchange - el valor depende del entorno cloud utilizado - Fairfax, Mooncake, USNat o USSec).

La combinación de issuer y subject debe ser única en la user managed identity.

1. La aplicación solicita un token a su proveedor de identidades.

2. La aplicación solicita un token a Microsoft identity platform, utilizando el token generado en el paso 1.

3. Microsoft identity platform valida el token incluido en la petición contra el servicio de validación definido externo registrado. Si el token es válido, se genera un token de autenticación para autenticarse contra otros servicios desplegados en Azure (hay que asignar los permisos necesarios en el servicio).

4. La aplicación utiliza el token generado para acceder a los recursos desplegados en Azure.

Configurar federated identity credentials (GitHub)

A continuación, vamos a configurar una federated identity credential para permitir que un GitHub workflow pueda acceder a recursos desplegados en Azure.

Desde el menú “Managed Identities” podemos crear una User Managed Identity.

Una vez creada, añadimos una federated identity credential:

1. Azure nos da la opción de configuración para diferentes escenarios, en nuestro caso seleccionamos la opción para configurar GitHub.

2. Completamos la información de la organización, repositorio y entidad (entity). En nuestro caso seleccionamos la entidad “branch” e introducimos el nombre del branch que estará autorizado a utilizar los recursos de Azure.

   • No se pueden utilizar wildcards (*).

   • Si necesitamos dar permisos a otros branches, debemos añadir cada uno de ellos.

Una vez creada la user managed identity y configurados los federated identity credentials, debemos asignar los permisos correspondientes de acceso.

Crear GitHub workflow

Para comprobar el correcto funcionamiento de la federated identity credential vamos a crear un GitHub workflow que realiza un login y mostrará la información de la suscripción de Azure.

Para ello vamos a utilizar el GitHub action Azure login:

name: Run Azure Login with OIDC
on: [push]

permissions:
  id-token: write
  contents: read

jobs:
  azure-login:
    runs-on: ubuntu-latest
    steps:
      - name: Azure login
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Azure CLI script
        uses: azure/cli@v2
        with:
          azcliversion: latest
          inlineScript: |
            az account show

Una vez que el contenido está en el repositorio, la GitHub action se ejecuta cada vez que se añade algo al branch main:

Conclusión

El uso de federated identity credentials representa un avance significativo en la administración de seguridad y autenticación para aplicaciones y servicios que interactúan con recursos de Azure desde entornos externos.

Algunas de las ventajas de su uso son:

• Seguridad mejorada: No se necesita administrar ni almacenar secretos y certificados, lo que reduce en gran medida el riesgo de que se comprometan las credenciales.

• Administración simplificada: La configuración de federated identity credentials es un proceso simple que reduce la carga administrativa asociada con la rotación y el mantenimiento de secretos.

• Flexibilidad: Permite una integración perfecta con una variedad de proveedores de identidad externos y se adapta a diferentes arquitecturas y requisitos de seguridad.

Para los desarrolladores y administradores de sistemas que utilizan Azure, la adopción de esta tecnología puede mejorar significativamente la seguridad de las aplicaciones y al mismo tiempo simplificar el proceso de autenticación y autorización.

Referencias

• https://learn.microsoft.com/en-gb/entra/identity/managed-identities-azure-resources/

• https://learn.microsoft.com/en-us/entra/workload-id/

• https://learn.microsoft.com/en-us/azure/developer/github/connect-from-azure?tabs=azure-portal%2Cwindows#use-the-azure-login-action-with-openid-connect

• https://learn.microsoft.com/en-us/azure/architecture/patterns/federated-identity

• https://github.com/Azure/login

Puedes encontrar el código fuente del post en el siguiente enlace: https://github.com/fjvela/blog-managed-identities

Introducción

Uno de los grandes retos que tenemos hoy en día es gestionar la información sensible (credenciales, certificados, …) que nuestras aplicaciones necesitan.

Azure proporciona Managed Identities para simplificar la autenticación necesaria para acceder a los recursos desplegados en Azure como Azure Key Vault. Puedes comprobar la lista de servicios que soportan la autenticación a través de Managed Identities en el siguiente enlace: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/managed-identities-status

La utilización de Managed Identities tiene algunas ventajas:

• No es necesario utilizar y/o gestionar credenciales

• Permite autenticarnos con cualquier otra aplicación (incluyendo nuestras propias aplicaciones)

• No tiene un coste extra

Tipos de Managed Identities

Existen dos tipos de Managed Identities:

• System managed identities: Son creadas automáticamente por Azure cuando se crean algunos servicios como máquinas virtuales:

  • Solo se puede utilizar por el servicio que la ha creado

  • Su ciclo de vida está asociado al ciclo de vida del recurso que lo ha creado (si borras el recurso, se borra la Managed Identity)

  • Automáticamente se crea un Service Principal en Microsoft Entra ID (directorio activo)

  • Debemos autorizar a qué servicios pueden acceder a la Managed Identity

• User managed identities: Podemos crear un Managed Identity y asignársela a más de una aplicación:

  • Podemos utilizarla en una o varias aplicaciones

  • Debemos autorizar a qué servicios pueden acceder las aplicaciones que usen la Managed Identity creada

  • Automáticamente se crea un Service Principal en Microsoft Entra ID (directorio activo), su ciclo de vida no está asociado al ciclo de vida de la aplicación que lo utiliza

¿Cómo funciona?

Antes de explicar como funciona el proceso de creación y funcionamiento de una managed identity, debemos conocer qué es Azure Instance Metadata Service identity (IMDS):

• Es un servicio REST interno disponible en la dirección IP: 169.254.169.254

• Proporciona información sobre las instancias de VM en ejecución: Sistema operativo, mantenimientos programados, …

• También proporciona tokens de autenticación que obtiene de Microsoft Entra ID

1. Azure Resource Manager crea un service principal en Microsoft Entra ID asociado a la Managed Identity creada

2. A continuación Azure Resource Manager, actualiza Azure Instance Metadata Service identity (IMDS) proporcionando el ID el service principal y los certificados creados por Microsoft Entra ID. Más tarde serán necesarios para poder autenticarse contra Microsoft Entra ID

3. En este paso, Azure Resource Manager habilita los permisos necesarios para acceder a otros recursos de Azure (Azure RBAC). Por ejemplo, asignar el rol Key Vault Secrets User para poder leer secretos de un Azure Key Vault

4. Cuando nuestra aplicación necesita acceder al recurso, se comunica con el IMDS, el cual solicita un token de autenticación a Microsoft Entra ID (utilizando el service principal y certificados creados en el paso 2) que será utilizado por la aplicación para poder acceder a otros recursos desplegados en Azure.

Habilitar una Managed Identity en Azure

Como hemos comentado, exiten dos tipos de Managed Identites: System managed identities y User managed identities. Vamos a ver como crear y habilitarlas en Azure.

Una vez creada la managed identity, debemos asignar los permisos correspondientes de acceso.

System Managed Identity

Para crear un System Managed Identity asociado a un recurso de Azure tan solo debemos seleccionarlo desde el portal y en el menu “Identity”, habilitarlo y guardar los cambios realizados.

User Managed Identity

Desde el apartado “Managed Identities” podemos crear User Managed Identites, una vez completados los datos requeridos debemos asignar la managed identity al recurso o recursos que harán uso de ella.

Como acceder a un recurso en Azure utilizando una Managed Identity utilizando .NET

Podemos hacer uso de las Managed Identities creadas en Azure a través de los diferentes SDKs disponibles o implementando el código necesario para poder interactuar con el API REST proporcionado por la IMDS y así obtener los tokens de autenticación para acceder a otros recursos de Azure.

Vamos a describir cómo podemos acceder a un Azure Key Vault utilizando código .NET y la librería Azure.Identity:

1. Crea una proyecto .NET, en este caso hemos creado un proyecto tipo Azure Functions para facilitar su despliegue en Azure

2. Añade la referencia a la librería Azure.Identity dotnet add package Azure.Identity

Azure.Identity proporciona varias clases que encapsulan la lógica necesaria para poder obtener un token de autenticación de Microsoft Entra ID haciendo uso de la Managed Identity configurada a través de la IMDS:

DefaultAzureCredential: Intenta realizar la autenticación a través de diferentes mecanismos hasta que consigue conectarse con uno de ellos.

var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

ChainedTokenCredential: Intenta realizar la autenticación a través de la Managed Identity. Si no lo consigue, intenta conectarse utilizando a través de Azure CLI

var credential = new ChainedTokenCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

ManagedIdentityCredential: Utiliza la Managed Identity para solicitar el token de autenticación

var credential = new ManagedIdentityCredential();
var client = new SecretClient(new Uri("https://mykv.vault.azure.net/"), credential);

El código final de nuestra Azure Function es el siguiente:

  [Function("GetSecret")]
  public IActionResult GetSecret([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req, 
      [FromQuery] string name,
      [FromQuery] string credentialType)
  {
      _logger.LogInformation("C# HTTP trigger function processed a request.");
      var kvName = _config["KV_NAME"];

      var tokenCredential = GetTokenCredential(credentialType);
      var client = new SecretClient(new Uri($"https://{kvName}.vault.azure.net/"), tokenCredential);

      return new OkObjectResult(client.GetSecret(name));
  }

  private TokenCredential GetTokenCredential(string credentialType)
  {
      switch (credentialType) {
          case "DefaultAzureCredential":
              return new DefaultAzureCredential();
          case "ChainedTokenCredential":
              return new ChainedTokenCredential();
          case "ManagedIdentityCredential":
              return new ManagedIdentityCredential();
      }

      throw new Exception($"The credential type {credentialType} is not valid");
  }

A continuación podemos ver el resultado de la ejecución de la Azure Function desde local y desde Azure:

Conclusión

La utilización de Managed Identities no solo simplifica la gestión de credenciales, sino que también mejora significativamente la seguridad de las aplicaciones, al eliminar la necesidad de configurar y guardar secretos en archivos de configuración.

Para los desarrolladores y arquitectos, utilizar Managed Identities debería ser una práctica estándar en la mayoría de los escenarios.

Referencias

• https://learn.microsoft.com/en-us/training/modules/implement-managed-identities/5-acquire-access-token

• https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview

• https://learn.microsoft.com/en-us/entra/identity-platform/how-applications-are-added

• https://learn.microsoft.com/en-us/azure/postgresql/single-server/how-to-connect-with-managed-identity

• https://learn.microsoft.com/en-us/dotnet/api/overview/azure/identity-readme

• https://learn.microsoft.com/es-es/azure/virtual-machines/instance-metadata-service

Puedes encontrar el código fuente de los ejemplos en repositorio: https://github.com/fjvela/csharp-13

params collections

El modificador params nos permite pasar un número variable de argumentos a un método. Hasta el momento estaba limitado unicamente al uso con tipos de datos Array.

var persons = new List<Person>
{
   new Person("Mads", "Torgersen"),
   new Person("Dustin", "Campbell"),
   new Person("Kathleen", "Dollard")
};

static void WriteNames(params string[] names)
 => Console.WriteLine(String.Join(", ", names));

WriteNames(persons.Select(person => person.FirstName).ToArray());

internal class Person( string Name, string FirstName)
{
    public string Name { get; set; }
    public string FirstName { get; set; }
}

C# 13 extiende el modificador permitiendonos trabajar con cualquier tipo de colección, tales como: System.Span<T>_, _System.ReadOnlySpan<T>, y tipos de datos que implementan la interfaz System.Collections.Generic.IEnumerable<T>.

static void WriteNames(params IEnumerable<string> names)
  => Console.WriteLine(String.Join(", ", names));

WriteNames(persons.Select(person => person.FirstName));
WriteNames(from p in persons select p.FirstName);

New lock type and semantics

.NET 9 permitirá bloquear el acceso a recursos compartidos se pueda realizar de una manera más simple, eficiente y menos ambigua a través de la clase System.Threading.Lock.

Para poder usar esta nueva clase en nuestras aplicaciones existentes, solo tendremos que sustituir private object myLock = new object(); por private System.Threading.Lock myLock = new System.Threading.Lock();. C# automáticamente generará las llamadas necesarias a la API para usar la nueva clase.

public class ClassLockTwo
{
    private System.Threading.Lock myLock = new System.Threading.Lock();

    public void MyMethod()
    {
        lock (myLock)
        {
            // Your code
        }
    }
}

New escape sequence - \e.

C# 13 introduce la secuencia de espace \e. Esta secuencia equivale al código unicode \u001b.

Console.WriteLine("\e[1mThis is a bold text\e[0m");

Console.ReadLine();

Implicit indexer access in object initializers

En C# podemos utilizar el operador ^ para acceder a un elemento de un Array desde el final del mismo. Con C# 13, podemos utilizarlo para inicializar elementos de un Array desde el final del mismo.

var countdown = new TimerRemaining(10)
{
    Buffer =
    {
        [^1] = 0,
        [^10] = 9
    }
};

Console.WriteLine($"First: {countdown.Buffer.First()} Last: {countdown.Buffer.Last()}");
Console.ReadLine();

class TimerRemaining(int bufferSize)
{
    public int[] Buffer  { get; set; } = new int[bufferSize];
}

ref struct

A continuación podemos comprobar algunas novedades relacionadas con el tipo ref struct y C# 13.

Enable ref locals and unsafe contexts in iterators and async methods

Para versiones anteriores a C# 13, no es posible utilizar los tipos ref struct en métodos iteradores (yield return). En los métodos asincronos (async) tampoco se pueden declarar variables de este tipo ni pueden ser usadas en contextos inseguros. C# 13 nos permitirá hacer uso de este tipo en todos estos casos de uso.

ref struct ClassOne
{
    public int Current => 0;
    public bool MoveNext() => false;
    public void Dispose() { }
}

class ClassTwo
{
    public ClassOne GetEnumerator() => new ClassOne();
    async void M()
    {
        await Task.Yield();
        using (new ClassOne()) { }
        lock (new System.Threading.Lock()) { }
        await Task.Yield();
    }
}

Allow ref struct types as arguments for type parameters in generics.

Versiones anteriores a C# 13 no permiten hacer uso del tipo ref structcomo parámetro generico de un método. A partir de esta versión ya es posible:

T Identity<T>(T p)
    where T : allows ref struct
    => p;

var local = Identity(new User());

Console.ReadLine();

ref struct User
{

}

Referencias

• https://devblogs.microsoft.com/dotnet/csharp-13-explore-preview-features/

• https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-13

• https://github.com/fjvela/csharp-13