Caso de uso común
Conecta jobs de CI/CD a recursos privados
Da a cada job de build o despliegue la conectividad privada que admite su runner, sin publicar el destino.
Respuesta breve
Usa wzctl supervisado para un destino TCP en un runner efímero. En un runner fiable y privilegiado, usa el cliente completo si necesitas DNS y rutas privadas.
El problema
Un pipeline puede necesitar una base de datos, una API de despliegue o el control plane de Kubernetes. Los endpoints públicos y el peering amplio exponen infraestructura innecesaria.
Elige y limita el modelo de conexión
Elige el modelo según el runner. wzctl encaja con herramientas que admiten un puerto local. El cliente completo necesita privilegios para crear WireGuard, rutas y split DNS.
- 1Despliega un publisher que pueda alcanzar el endpoint de despliegue.
- 2Para wzctl, elige el ID del publisher, la IP exacta, el puerto TCP, el TTL y el puerto local.
- 3Inyecta la API key de forma segura, inicia wzctl bajo supervisión y espera a que 127.0.0.1 acepte conexiones.
- 4Ejecuta el job, detén wzctl durante la limpieza y rota por separado las credenciales del destino.
Flujo de acceso de ejemplo
Proceso
Job efímero de despliegue con wzctl
Endpoint local
127.0.0.1:16443Destino del pase
10.0.4.15:6443 (/32)Límite de autorización
Un destino TCP de despliegue hasta que expire el pase
Cuándo encaja este patrón
- Un job efímero necesita un destino TCP de SSH, HTTPS, base de datos o Kubernetes.
- La herramienta de despliegue puede utilizar un puerto en 127.0.0.1.
- El runner puede proteger una API key y supervisar un proceso auxiliar.
- Hay un runner fiable y privilegiado cuando se necesitan DNS y rutas directas.
Límite de seguridad y consideraciones
- wzctl proporciona una ruta TCP, no DNS privado ni rutas generales. Cada destino adicional necesita su propio pase.
- Un runner con el cliente completo recibe los CIDRs autorizados para sus grupos, salvo que reglas restrictivas efectivas reduzcan el alcance.
- Los permisos del repositorio, la identidad del workload, las credenciales y la autorización del despliegue siguen siendo controles separados.
Preguntas frecuentes
¿Debe CI usar el modo daemon de wzctl?+
Trata wzctl como un proceso auxiliar en primer plano y bajo supervisión. La opción daemon registra un PID, pero no hace fork ni se desacopla.
¿Puede un runner propio usar el cliente completo?+
Sí, si es fiable y puede crear interfaces WireGuard, rutas y configuración DNS.
¿WireZTNA autoriza el despliegue?+
No. Proporciona alcance de red. La plataforma de destino debe autenticar el job y autorizar la operación solicitada.