🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Gestión de identidades con SPIFFE y SPIRE en entornos de servidores distribuidos

Actualizado el 31 de mayo de 2026

La gestión de identidades en entornos de servidores distribuidos ha evolucionado desde simples contraseñas estáticas hacia modelos dinámicos basados en criptografía. En este contexto, SPIFFE (Secure Production Identity Framework for Everyone) y su implementación de referencia SPIRE se han convertido en el estándar de facto para emitir, rotar y verificar identidades de cargas de trabajo en infraestructuras modernas. Este artículo explora en profundidad cómo estas tecnologías permiten implementar un modelo zero-trust real, utilizando mTLS como mecanismo de transporte seguro, y cómo gestionar la identidad servidores en clusters de Kubernetes, nubes híbridas o entornos on-premise.

¿Qué es SPIFFE y por qué es necesario?

SPIFFE define un estándar abierto para la identidad de cargas de trabajo en entornos dinámicos. Su núcleo es el SPIFFE ID, un URI con el formato spiffe://trust-domain/path. Por ejemplo: spiffe://produccion.ejemplo.com/servicios/api-gateway.

Este identificador no depende de direcciones IP, nombres de host o tokens estáticos. En su lugar, se vincula criptográficamente a la carga de trabajo mediante un certificado X.509 firmado por una autoridad certificadora (CA) interna. La ventaja es inmediata: cualquier proceso, contenedor o servicio puede demostrar quién es sin necesidad de compartir secretos de larga duración.

[INFO] SPIFFE no es un producto, es una especificación. SPIRE es la implementación de referencia más madura, mantenida por la CNCF.

El problema de la identidad en entornos distribuidos

En un modelo tradicional, la identidad de un servidor se basa en su dirección IP o en un certificado TLS estático. Pero en entornos con escalado horizontal, balanceadores de carga y contenedores efímeros, esos atributos cambian constantemente. Un pod en Kubernetes puede tener una IP diferente cada vez que se reinicia. Un microservicio puede ejecutarse en múltiples nodos simultáneamente.

Aquí es donde SPIFFE resuelve el problema: la identidad se asigna al workload (la carga de trabajo), no al nodo físico. El SPIRE Agent y el SPIRE Server trabajan juntos para emitir certificados X.509-SVID (SPIFFE Verifiable Identity Document) que son cortos, rotados frecuentemente y revocables al instante.

Arquitectura de SPIRE: Servidor, Agentes y Registro

SPIRE se compone de tres componentes principales que orquestan todo el ciclo de vida de la identidad.

SPIRE Server

Es el núcleo de confianza. Gestiona la CA raíz, firma todos los certificados SVID y mantiene el registro de políticas de identidad. Se ejecuta normalmente en un conjunto reducido de nodos (alta disponibilidad recomendada) y expone una API gRPC para que los agentes soliciten identidades.

# Ejemplo de configuración del servidor SPIRE (server.conf)
server {
    trust_domain = "produccion.ejemplo.com"
    data_dir = "/opt/spire/data/server"
    log_level = "INFO"
    ca_subject {
        country = "ES"
        organization = "Ejemplo Corp"
        common_name = "SPIRE CA"
    }
}

SPIRE Agent

Se despliega en cada nodo del clúster (físico, VM o pod). Su función es actuar como intermediario: verifica la identidad del nodo mediante un node attestor (por ejemplo, usando el token de instancia de AWS, el TPM del servidor o un token precompartido) y luego atestigua las cargas de trabajo locales.

Cada agente mantiene un conjunto de certificados SVID para los workloads que se ejecutan en su nodo. Cuando un workload necesita comunicarse con otro, el agente le proporciona un certificado firmado por el servidor.

# Comando para iniciar el agente en un nodo Linux
spire-agent run -config /opt/spire/conf/agent/agent.conf

Registro de entradas (Registration Entries)

El SPIRE Server almacena un mapa de políticas que asocian selectores (atributos del workload) con un SPIFFE ID. Por ejemplo:

  • Selector: k8s:pod-label:app=frontend → SPIFFE ID: spiffe://produccion.ejemplo.com/servicios/frontend
  • Selector: unix:uid:1001 → SPIFFE ID: spiffe://produccion.ejemplo.com/workers/procesador-datos

Estas entradas se pueden gestionar mediante la API de SPIRE o con herramientas como spire-server entry create.

Integración con mTLS para zero-trust

Uno de los casos de uso más potentes de SPIFFE/SPIRE es habilitar mTLS (mutual TLS) sin necesidad de gestionar una PKI tradicional. En lugar de compartir certificados raíz o listas de revocación, cada workload obtiene su propio SVID y confía en la CA de SPIRE.

Flujo típico de conexión mTLS con SPIRE

  1. El workload A solicita su SVID al agente SPIRE local.
  2. El agente verifica los selectores del workload (ej. etiqueta de pod, usuario Unix) y, si coincide con una entrada de registro, solicita al servidor un certificado firmado.
  3. El servidor emite un SVID con validez corta (ej. 1 hora).
  4. El workload A inicia una conexión TLS con el workload B.
  5. El workload B, usando su propio SVID, presenta su certificado y verifica el de A contra la CA raíz de SPIRE.
  6. Si ambos SVID son válidos y pertenecen al mismo trust domain, la conexión se establece.

Este mecanismo elimina la necesidad de listas de control de acceso basadas en IP o redes. La identidad se verifica criptográficamente en cada conexión, implementando el principio de zero-trust: nunca confíes, siempre verifica.

[TIP] Puedes integrar SPIRE con Envoy Proxy o Istio para que el sidecar maneje automáticamente el mTLS sin modificar el código de la aplicación.

Beneficios frente a certificados estáticos

AspectoCertificados tradicionalesSVID con SPIRE
ValidezMeses o añosMinutos u horas
RotaciónManual o con scripts complejosAutomática y orquestada
RevocaciónLenta, basada en CRL/OCSPInstantánea (el agente deja de renovar)
AsociaciónIP o DNS fijoAtributos dinámicos (labels, UID, etc.)

Despliegue práctico en un clúster de servidores

Para ilustrar el proceso, supongamos un escenario con tres servidores físicos ejecutando microservicios en contenedores Docker. Queremos que el servicio api-gateway se comunique con auth-service mediante mTLS, usando SPIRE.

Paso 1: Instalación de SPIRE Server

En un nodo dedicado (o un conjunto de tres para alta disponibilidad), instalamos el binario de SPIRE Server y generamos la configuración inicial.

# Descargar la última versión
wget https://github.com/spiffe/spire/releases/download/v1.9.0/spire-1.9.0-linux-amd64.tar.gz
tar -xzf spire-1.9.0-linux-amd64.tar.gz
cd spire-1.9.0/bin

# Inicializar el servidor
./spire-server run -config ../conf/server/server.conf

Paso 2: Instalación de SPIRE Agent en cada servidor

En cada nodo del clúster, instalamos el agente. Usaremos un token precompartido como método de atestación de nodo (para entornos on-premise sin cloud metadata).

# En el servidor, generar un token para cada nodo
./spire-server token generate -spiffeID spiffe://produccion.ejemplo.com/nodes/servidor01
# Devuelve: Token: 01234567-89ab-cdef-0123-456789abcdef

# En el nodo, configurar el agente con ese token
cat > /opt/spire/conf/agent/agent.conf << EOF
agent {
    trust_domain = "produccion.ejemplo.com"
    data_dir = "/opt/spire/data/agent"
    log_level = "INFO"
    server_address = "10.0.0.10"
    server_port = "8081"
}
plugins {
    node_attestor "join_token" {
        plugin_data {
            join_token = "01234567-89ab-cdef-0123-456789abcdef"
        }
    }
    workload_attestor "unix" {
        plugin_data {}
    }
}
EOF

# Iniciar el agente
./spire-agent run -config /opt/spire/conf/agent/agent.conf

Paso 3: Crear entradas de registro

Registramos los workloads basándonos en selectores Unix (por ejemplo, el UID del proceso o la ruta del binario).

# Registrar el servicio api-gateway
./spire-server entry create \
    -spiffeID spiffe://produccion.ejemplo.com/servicios/api-gateway \
    -parentID spiffe://produccion.ejemplo.com/nodes/servidor01 \
    -selector unix:uid:1001 \
    -ttl 3600

# Registrar el auth-service
./spire-server entry create \
    -spiffeID spiffe://produccion.ejemplo.com/servicios/auth-service \
    -parentID spiffe://produccion.ejemplo.com/nodes/servidor02 \
    -selector unix:uid:1002 \
    -ttl 3600

Paso 4: Obtener SVID desde la aplicación

Cada workload puede obtener su SVID mediante la API del agente SPIRE (socket Unix). Por ejemplo, en Python:

import subprocess
import json

# Obtener SVID usando la CLI del agente
result = subprocess.run(
    ["/opt/spire/bin/spire-agent", "api", "fetch", "x509", "-socketPath", "/tmp/spire-agent/api.sock"],
    capture_output=True, text=True
)
svid_data = json.loads(result.stdout)
cert_pem = svid_data["svids"][0]["x509_svid"]["cert_chain"]
key_pem = svid_data["svids"][0]["x509_svid"]["private_key"]

Luego, esos materiales se usan directamente en la configuración de TLS de la aplicación o del proxy.

Consideraciones de seguridad y operaciones

Rotación y revocación

Los SVID tienen un TTL corto (recomendado entre 1 y 24 horas). El agente renueva automáticamente los certificados antes de que expiren. Si un workload se considera comprometido, se elimina su entrada de registro y el agente dejará de renovar su SVID; en minutos, el certificado caduca y el workload pierde toda capacidad de autenticarse.

Almacenamiento de claves privadas

SPIRE genera las claves privadas en el lado del agente (nunca salen del nodo). Se almacenan en memoria o en disco con permisos restrictivos. Para entornos de alta seguridad, se puede integrar con módulos HSM o TPM.

[WARNING] No almacenes los tokens de atestación de nodo en repositorios de código. Úsalos solo durante el aprovisionamiento inicial o cámbialos periódicamente.

Monitoreo y logging

SPIRE expone métricas en formato Prometheus y logs estructurados. Es crucial monitorizar:

  • Tasa de renovación de SVID (debería ser constante).
  • Fallos de atestación (indican problemas de configuración o nodos no autorizados).
  • Tiempo de vida medio de las conexiones mTLS.

Casos de uso avanzados: multi-clúster y trust domains

Cuando se tienen múltiples clústeres de Kubernetes o centros de datos, cada uno puede tener su propio trust domain (ej. spiffe://datacenter-1.ejemplo.com y spiffe://datacenter-2.ejemplo.com). Para que servicios de distintos dominios confíen entre sí, se establece una federación.

SPIRE soporta federación mediante el intercambio de bundles de CA. Así, un workload en el datacenter 1 puede verificar un SVID emitido por el datacenter 2, siempre que ambos servidores hayan intercambiado sus raíces de confianza.

# En el servidor SPIRE del datacenter 1, exportar el bundle
./spire-server bundle show > bundle-dc1.pem

# En el servidor SPIRE del datacenter 2, importarlo
./spire-server bundle set -id spiffe://datacenter-1.ejemplo.com -path bundle-dc1.pem

Este mecanismo permite construir mallas de confianza entre entornos heterogéneos sin depender de una CA externa.

Conclusión

La combinación de SPIFFE y SPIRE ofrece un modelo de identidad servidores que se adapta a la naturaleza efímera y dinámica de los entornos distribuidos modernos. Al desacoplar la identidad de la infraestructura física y basarla en atributos semánticos, se facilita la implementación de arquitecturas zero-trust con mTLS como mecanismo de verificación continua.

La curva de aprendizaje inicial puede ser pronunciada, pero el retorno en seguridad, escalabilidad y facilidad de operación es enorme. Para cualquier equipo que gestione más de unas docenas de servidores o microservicios, adoptar SPIRE no es una opción, es una necesidad para mantener un modelo de confianza sólido y automatizado.

[INFO] SPIRE es un proyecto de la CNCF (Cloud Native Computing Foundation) y cuenta con integraciones nativas con Kubernetes, Envoy, Istio y Consul. Su ecosistema sigue creciendo.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel