Contexto
FortiAIGate 8.0 es la plataforma de Fortinet para la protección de tráfico de inteligencia artificial: control de prompt injection, prevención de fuga de datos y análisis de respuestas de modelos LLM. Su despliegue oficial se realiza mediante un Helm chart sobre Kubernetes con soporte de GPU, lo cual implica orquestar un clúster EKS, nodegroups con instancias de alto costo (familias g6, g5 o p4) y almacenamiento compartido entre pods.
Construí este laboratorio con tres objetivos: dominar el producto a fondo, contar con un entorno controlado para demostraciones técnicas y disponer de un terreno propio para investigaciones de seguridad ofensiva sobre cargas de IA.
Diseño de la arquitectura
El entorno está diseñado para encenderse únicamente cuando se requiere y apagarse de forma automática al concluir la sesión:
- Clúster EKS con dos nodegroups diferenciados: uno reducido para los componentes de control que permanecen activos y otro de GPU que arranca con cero nodos por defecto.
- EFS como almacenamiento RWX para los pods que comparten cachés de modelos, evitando la duplicación innecesaria de volúmenes EBS.
- Helm chart oficial de FortiAIGate con
nodeSelectororientado al nodegroup GPU. - Panel de control propio (CloudFront + S3 + API Gateway + Lambda) que escala el nodegroup GPU de cero a uno bajo demanda, con autenticación simple.
El resultado: la GPU genera costo únicamente durante las horas de uso efectivo, mientras el resto del laboratorio permanece persistente y económico.
Decisiones técnicas relevantes
Bloqueo de licencia por hostname
La licencia de FortiAIGate se vincula al hostname del pod. En la configuración por defecto, cada vez que el nodegroup escala de cero a uno, Kubernetes asigna un hostname distinto y la licencia se invalida. La solución consistió en inyectar la variable NODE_NAME como override estable, permitiendo que la licencia sobreviva los ciclos de Stop/Start sin necesidad de reactivación manual ante FortiCare.
Afinidad sobre etiquetas estables
El Helm chart utiliza por defecto kubernetes.io/hostname para algunas reglas de afinidad. Tras el primer ciclo de apagado y reencendido, esa etiqueta cambia y los pods quedan en estado pendiente de forma permanente. La sustitución por una etiqueta propia del nodegroup, que persiste entre escalados, eliminó completamente el problema.
Patrón reutilizable de panel de control
El panel desarrollado para arrancar el nodo GPU se consolidó como un patrón aplicable más allá de este laboratorio. La misma arquitectura se puede reutilizar para FortiEDR, sandboxes de análisis y, en general, cualquier carga sobre EKS que consuma recursos costosos por sesión.
Aprendizajes
- Para productos Fortinet de naturaleza cloud-native pero intensivos en cómputo, EKS combinado con nodegroups que escalan a cero ofrece el mejor balance entre costo y disponibilidad.
- El reto principal no se encuentra en el despliegue inicial, sino en el ciclo de vida operativo: garantizar apagados limpios y reencendidos consistentes sin afectar licencias ni estado.
- Un panel de control diseñado a la medida del laboratorio es más valioso que cualquier dashboard genérico, ya que codifica decisiones operativas específicas como tiempos de espera, secuencias de apagado y alertas.
Próximos pasos
Estoy consolidando esta arquitectura en un kit reutilizable bajo el nombre “FortiAIGate-on-AWS in a box”, combinando Terraform, valores de Helm y funciones Lambda, con el objetivo de que partners y clientes puedan replicar el laboratorio en sus propias cuentas reduciendo el proceso a un solo comando de aprovisionamiento.