Caso de uso común

Accede directamente a una API privada de Kubernetes

Mantén kubeconfig en el endpoint privado real del control plane mientras WireZTNA aporta las rutas y el split DNS necesarios.

Respuesta breve

Para operadores, ejecuta wireztna connect y usa el hostname privado de la API en kubeconfig. La autenticación y RBAC de Kubernetes siguen controlando cada acción.

El problema

Operadores y pipelines necesitan una ruta al control plane privado. Una VPN amplia también puede exponer nodos, bases de datos y balanceadores internos.

Elige y limita el modelo de conexión

Autoriza el grupo del operador para el publisher de Kubernetes. Usa una regla restrictiva efectiva para el /32 de la API y TCP 6443 si otros sistemas del CIDR deben quedar fuera.

  1. 1Despliega un publisher que alcance la API privada de Kubernetes y expón el CIDR que la contiene.
  2. 2Asigna el operador mediante un grupo autorizado para ese publisher.
  3. 3Añade una regla de acceso efectiva (AccessRule) para el /32 y TCP 6443 cuando necesites limitar el acceso al endpoint.
  4. 4Ejecuta wireztna connect, conserva el hostname privado en kubeconfig y usa la identidad habitual de Kubernetes.

Flujo de acceso de ejemplo

Consumidor

Operador con el cliente completo

Comando del cliente

wireztna connect

Destino privado

https://k8s-api.internal:6443

Límite de autorización

Regla efectiva para API /32 y TCP 6443; RBAC controla las acciones

Cuándo encaja este patrón

  • Un operador necesita kubectl mediante el nombre privado real del control plane.
  • Un runner fiable y privilegiado puede usar el cliente completo para desplegar.
  • Un job efímero puede usar un pase wzctl separado con configuración TLS explícita.
  • La autenticación, RBAC, admission controls y auditoría de Kubernetes ya están configurados.

Límite de seguridad y consideraciones

  • Sin una regla restrictiva efectiva, el cliente enruta los CIDRs del publisher autorizados mediante los grupos del operador.
  • WireZTNA no sustituye la seguridad de kubeconfig, identidad, RBAC, admission policy, TLS ni los logs de auditoría de Kubernetes.
  • Un pase wzctl para CI puede necesitar el nombre TLS original porque el certificado suele identificar el hostname privado de la API.

Preguntas frecuentes

¿kubectl usa localhost con el cliente completo?+

No. Mantén kubeconfig en el hostname o IP privada de la API. El cliente aporta la ruta y el split DNS.

¿Puede CI usar wzctl?+

Sí, para una IP y puerto TCP exactos de la API. Supervisa wzctl y conserva el nombre TLS original para validar el certificado.

¿WireZTNA sustituye RBAC de Kubernetes?+

No. WireZTNA controla el alcance de red. Kubernetes autentica la identidad y autoriza recursos, namespaces y verbos.

Pon este patrón en práctica

← Todos los casos de uso