Proteger Kubernetes Dashboard con Cloudflare Tunnel

En pocas palabras: Para blindar el Dashboard de Kubernetes, la solución definitiva es un túnel Cloudflare Zero Trust con salida outbound-only y Cloudflare Access, eliminando cualquier puerto expuesto y autenticando cada request con políticas de identidad. Así lo implementó Oleksandr Kuryzhev tras detectar el panel expuesto en Shodan.

Un administrador de infraestructura encontró el Dashboard de Kubernetes de su empresa completamente expuesto a internet durante un barrido rutinario con Shodan. Tres semanas antes alguien había dejado un kubectl proxy --address=0.0.0.0 prendido después de debuggear algo (spoiler: se olvidaron de apagarlo). No había VPN, ni política de acceso, ni nada. Ese incidente, documentado por Oleksandr Kuryzhev, refleja el problema más común y evitable en la seguridad Kubernetes Dashboard: configuraciones por defecto, permisos exagerados y puertos abiertos al mundo sin autenticación. La solución que implementó y documentó combina Cloudflare Zero Trust Tunnel con Cloudflare Access, y elimina cualquier puerto entrante en el clúster. Funciona con una conexión outbound-only desde adentro hacia Cloudflare, y autentica cada request con políticas de identidad.

Si alguna vez tuviste que exponer un dashboard interno en Kubernetes sabés que la alternativa clásica es montar una VPN, repartir configuraciones de WireGuard, pelear con allowlists de IP y rezar para que nadie se conecte desde la cafetería de Aeroparque (porque ahí la IP cambia y todo se va al tacho). Cloudflare Tunnel resuelve esto de una forma distinta, y bastante más elegante: en lugar de abrir puertos, el túnel se inicia desde el clúster hacia afuera, Cloudflare lo registra y después vos accedés vía un dominio con autenticación Zero Trust. Fin de los puertos expuestos. Fin de las VPN para un solo servicio.

Cloudflare es una red de entrega de contenido y servicios de seguridad en la nube desarrollada por Cloudflare, Inc., diseñada para acelerar sitios web y protegerlos contra ataques cibernéticos. También ofrece túneles Zero Trust para conectar aplicaciones de forma segura sin exponer direcciones IP.

Cloudflare Zero Trust Tunnel es un servicio que establece un canal cifrado saliente desde un connector (en este caso un pod dentro del clúster) hacia la red de Cloudflare, sin necesitar que haya un puerto abierto en el firewall ni una IP pública asignada al clúster. Cloudflare recibe el tráfico en su edge, lo manda por el túnel y, si activaste Access, lo pasa por una capa de autenticación que evalúa quién está del otro lado antes de dejar pasar un solo paquete. Para Kubernetes Dashboard, esto significa que el tablero deja de ser un blanco abierto y pasa a ser un servicio al que solo entrás si tu identidad está autorizada.

¿Por qué exponer Kubernetes Dashboard es un riesgo real?

Ponele que desplegás el dashboard con los manifiestos que vienen por defecto en el repo oficial de Kubernetes. Lo levantás, hacés un kubectl proxy para probarlo desde tu navegador local y, como estás a las corridas, lo dejás escuchando en 0.0.0.0 para acceder desde otra máquina de la oficina. Ese mismo día Shodan y Censys ya lo tienen indexado.

Kuryzhev lo confirmó de primera mano: durante un barrido contra sus propios rangos IP encontró el dashboard de su empresa expuesto, con kubectl proxy abierto desde hacía tres semanas y sin ningún tipo de autenticación delante. No es un caso aislado — los motores de búsqueda de dispositivos indexan miles de paneles de Kubernetes con la misma configuración desprotegida. Y si el ClusterRoleBinding está seteado como cluster-admin (algo frecuente en instalaciones out of the box), cualquiera que llegue al dashboard tiene control total del clúster: pods, secretos, volúmenes, todo.

Acá no hay “parche” intermedio que zafe. Si abriste el puerto al mundo sin una capa de autenticación, estás regalando la llave maestra. En cómo gestionar variables y secretos en Cloudflare profundizamos sobre esto.

Cómo funciona Cloudflare Zero Trust Tunnel en Kubernetes

El túnel corre como un proceso cloudflared adentro del clúster, típicamente en un Deployment separado o como sidecar del pod del dashboard. Ese proceso inicia una conexión saliente por HTTPS hacia el edge de Cloudflare y la mantiene abierta. Cloudflare mapea esa conexión a un hostname público (un subdominio de tu propio dominio) y, cuando alguien hace una solicitud a ese hostname, la enruta por el túnel hacia el clúster sin atravesar el firewall en dirección entrante.

La clave es que el tráfico entrante nunca llega directo: no hay NodePort, no hay LoadBalancer, no hay IP pública del clúster. Todo sale de adentro hacia afuera y se atiende en el edge. Después, si además configurás Cloudflare Access, cada request se chequea contra una política que puede incluir identidad (Google, GitHub, Okta), dispositivo corporativo o geolocalización. El resultado es una experiencia parecida a un proxy inverso con autenticación integrada, pero sin exponer nada.

Túnel de Cloudflare vs VPN tradicional: ¿cuál conviene para el Dashboard?

Criterio	Cloudflare Zero Trust Tunnel	VPN (WireGuard / OpenVPN)
Puertos entrantes en el clúster	Ninguno — conexión outbound-only	Requiere puerto UDP o TCP abierto
Autenticación	Por request, con OAuth y políticas de Access	Por red — una vez adentro, acceso total
Configuración en cliente	Solo navegador, sin software extra	Instalar y mantener cliente VPN por dispositivo
Roaming (coffee shop)	Funciona desde cualquier IP	Se rompe si la IP no está en la allowlist
Gasto operativo	Túnel + Access free tier para equipos chicos	Mantener servidor VPN, keys, rotación
Granularidad de acceso	Por aplicación, hostname y política	Por red — el dashboard comparte plano con todo

Requisitos previos para armar el túnel

• Kubernetes Dashboard operativo: el checklist de Kuryzhev asume que ya lo tenés corriendo (versión 2.7.0 o superior recomendada).
• Cuenta en Cloudflare: con un dominio propio. El túnel necesita que el hostname esté en una zona que vos administres; no alcanza con el *.cloudflareaccess.com del plan gratuito si querés usar Access en serio.
• Permisos de RBAC mínimos: la buena práctica es correr el dashboard con un ServiceAccount que no tenga cluster-admin. El artículo de Kuryzhev insiste en que uses un ClusterRole restringido, solo con permisos de lectura y a namespaces específicos.
• DNS interno o CoreDNS: para que el pod del túnel resuelva el Service del dashboard (algo como kubernetes-dashboard.kubernetes-dashboard.svc.cluster.local).
• Red con salida a internet: el pod de cloudflared necesita conectarse a los servidores de Cloudflare por el puerto 443/TCP. Si corrés el clúster en entornos con proxy corporativo, ajustá la configuración del túnel.

Paso a paso para desplegar Cloudflare Tunnel en Kubernetes

El artículo de Kuryzhev propone una secuencia directa que cualquier persona que ya operó un clúster entiende en cinco minutos.

Crear el túnel desde cloudflared. Instalás cloudflared en tu máquina local (o en un bastion), autenticás contra tu cuenta de Cloudflare con cloudflared tunnel login y ejecutás cloudflared tunnel create k8s-dashboard. Esto genera un certificado JSON y un ID de túnel.

Configurar el DNS. Con cloudflared tunnel route dns le decís a Cloudflare que el tráfico para, por ejemplo, dashboard.midominio.com.ar tiene que ir por ese túnel. El registro CNAME lo crea automáticamente en la zona DNS de tu dominio.

Desplegar el túnel en el clúster. Pasás el certificado JSON a un ConfigMap o Secret, escribís un Deployment mínimo con la imagen oficial de cloudflared y lo configurás para que apunte a http://kubernetes-dashboard.kubernetes-dashboard.svc.cluster.local. Kuryzhev recomienda un Deployment aparte (no sidecar del dashboard) para no mezclar los ciclos de vida: si el dashboard se actualiza o crashea, el túnel sigue vivo. Complementá con comparativa de Cloudflare Containers y AWS.

Probar conectividad. Hacés un curl -v https://dashboard.midominio.com.ar y, si todo salió bien, deberías llegar al dashboard — por ahora sin autenticación, pero sin ningún puerto abierto en el firewall.

Cómo configurar Cloudflare Access para que solo entre quien debe

Con el túnel funcionando, el siguiente paso es ponerle autenticación. En el panel de Cloudflare Zero Trust, creás una política de Access sobre ese hostname. Las opciones van desde un simple “permitir solo cuentas @miempresa.com” hasta integraciones con Okta, GitHub, Google Workspace o validación de dispositivo mediante certificado de cliente.

Lo interesante es que la política se aplica antes de que el tráfico llegue al clúster. Si alguien intenta acceder al dashboard sin cumplir la regla, Cloudflare devuelve un HTML de bloqueo directamente desde el edge. Kubernetes ni se entera.

Al ponerlo en producción, es importante tener en cuenta la duración de la sesión en Access. Kuryzhev recomienda configurarla explícitamente para evitar problemas, arrancando con algunas horas y ajustando según la política interna, en lugar de dejar el valor por defecto.

Verificá que el Dashboard no esté dando vueltas por internet

Este paso es el que muchos se saltean y es el más importante de todos: validar que el dashboard no responde desde ningún otro lado. El mismo Kuryzhev usó Shodan para confirmarlo: hacés una query con el rango de IPs de tu clúster (net:tu.rango.ip/24) y te fijás que no aparezca el puerto 8443 ni 8001 abierto con Kubernetes Dashboard en el fingerprint.

También podés hacer un nmap -p 8001,443,8443 tu-ip-publica desde una máquina externa. Si todo está bien armado, esos puertos tienen que aparecer filtrados o cerrados — solo el túnel de Cloudflare, por el dominio que configuraste, debería responder (y únicamente con la pantalla de login de Access delante). Relacionado: Cloudflare R2 sin costos de egreso.

Si en algún momento habías usado NodePort o LoadBalancer para exponer el dashboard, asegurate de que esos recursos estén eliminados del clúster, no solo “desconectados”. Kubernetes no va a borrar un Service porque vos te hayas olvidado de él, y un Service de tipo LoadBalancer puede mantener una IP pública asignada aunque no la estés mirando — con costo y riesgo incluidos (sobre todo si el clúster corre sobre infraestructura cloud donde las IPs elásticas se pagan).

Qué significa para equipos en Latinoamérica

En la región, muchas empresas de producto y agencias corren clústeres de Kubernetes en VPS o bare metal con equipos chicos donde la misma persona que desarrolla también administra infra. El patrón es conocido: se levanta el dashboard “para ver algo rápido” y queda abierto semanas. Meter una VPN completa para dos o tres personas que necesitan acceso esporádico al dashboard es absurdo en costo y mantenimiento.

Cloudflare Tunnel con Access no necesita hardware extra, corre en cualquier clúster con salida a internet y la capa gratuita cubre sin problemas equipos de hasta 50 usuarios. Para startups y scale-ups latinoamericanas que no tienen un equipo de seguridad dedicado, este esquema es un golazo: cerrás la puerta de entrada al clúster y delegás la autenticación en un servicio que ya está probado a escala global.

Errores comunes al poner el túnel en Kubernetes

Dejar el Service del dashboard en NodePort o LoadBalancer “por las dudas”

El túnel funciona sin ningún Service expuesto. Si lo dejás, el dashboard sigue siendo accesible desde la IP del nodo. Borrá el Service de tipo NodePort o LoadBalancer tan pronto como el túnel esté activo, y si querés un respaldo para debug local, usá kubectl proxy en localhost (no en 0.0.0.0, y solo cuando lo necesites).

No configurar bien el tiempo de sesión en Access

Si ponés sesiones demasiado cortas, los loops de redirección OAuth son inevitables. Kuryzhev lo encontró a las piñas. La recomendación es arrancar con 24 horas para el dashboard y después ajustar según política interna.

Olvidarse de que Kubernetes Dashboard, por defecto, sigue teniendo permisos de más

El túnel y Access protegen la entrada, no lo que el dashboard puede hacer una vez autenticado. Reducí el RBAC a un ClusterRole de solo lectura y aplicá namespaces si no necesitás visibilidad global. La seguridad en capas, acordate: un solo anillo para gobernarlos a todos nunca sale bien. Cubrimos ese tema en detalle en nuestra comparativa de CI/CD 2026.

Preguntas Frecuentes

¿Cómo proteger Kubernetes Dashboard usando Cloudflare Tunnel?

Creás un túnel con cloudflared, lo desplegás como Deployment en el clúster apuntando al Service interno del dashboard, enrutás el tráfico desde tu dominio y cerrás cualquier NodePort o LoadBalancer existente. Luego configurás una política de Cloudflare Access sobre ese hostname para que solo usuarios autorizados (por email, OAuth o dispositivo) puedan ver el dashboard.

¿Qué es Cloudflare Zero Trust y cómo se usa en Kubernetes?

Cloudflare Zero Trust reúne Tunnel y Access en un solo producto. El Tunnel reemplaza la necesidad de abrir puertos en el firewall del clúster; Access agrega autenticación por identidad delante de cada aplicación. En Kubernetes, desplegás cloudflared como un pod que mantiene una conexión saliente al edge de Cloudflare, y desde ahí gestionás el acceso al dashboard, APIs internas o cualquier servicio HTTP sin exponer la infraestructura.

¿Es mejor usar VPN o Cloudflare Tunnel para acceder al dashboard de Kubernetes?

Para acceso puntual a un dashboard, Cloudflare Tunnel suele ser más práctico que una VPN: no necesitás instalar cliente, funciona desde cualquier IP sin allowlists y la autenticación es por aplicación, no por red. Una VPN sigue teniendo sentido si ya la tenés montada para otros servicios y querés unificar todo bajo el mismo túnel WireGuard. El costo operativo del túnel, en equipos chicos, es casi nulo porque el free tier de Cloudflare Zero Trust cubre hasta 50 usuarios.

¿Qué requisitos de red necesita Cloudflare Tunnel en Kubernetes?

El pod de cloudflared necesita salida a internet por el puerto 443/TCP hacia los servidores de Cloudflare. Dentro del clúster, tiene que resolver el nombre DNS del Service de Kubernetes Dashboard. No requiere IP pública, NAT estático ni reglas de firewall entrantes. Si hay un proxy corporativo en el medio, configurás cloudflared con las variables de entorno HTTP_PROXY y HTTPS_PROXY para que el túnel salga por el proxy.

Cloudflare Zero Trust Tunnel, ¿tiene versión gratuita?

Sí. Cloudflare Zero Trust incluye un plan gratuito que permite hasta 50 usuarios, además de túneles ilimitados. Para la mayoría de los equipos que solo necesitan proteger el dashboard de Kubernetes (y quizás algunas herramientas internas más), ese plan cubre el caso de uso sin costo.

Conclusión

La checklist que publicó Kuryzhev no inventa nada nuevo, pero le pone orden a algo que en la práctica se hace medio a los ponchazos. Kubernetes Dashboard sigue siendo un punto ciego para muchos equipos que lo instalan, lo dejan con permisos de cluster-admin y lo exponen sin querer con un --address=0.0.0.0. Cloudflare Tunnel y Access reemplazan esa exposición por un esquema prolijo: outbound-only, autenticación por identidad y visibilidad desde cualquier lado sin VPN.

Si ya tenés un dominio en Cloudflare y un clúster con acceso a internet, podés tener esto andando en menos de una hora. Y si todavía estás entrando a tu dashboard con un kubectl proxy abierto a cuatro manos, cerrá eso ahora. Después hacé el túnel.

Fuentes

• Secure Kubernetes Dashboard with Cloudflare Zero Trust Tunnel – Oleksandr Kuryzhev
• Cloudflare Tunnel documentation – Cloudflare Docs
• Shodan – Motor de búsqueda de dispositivos conectados a internet