Seguridad de la Plataforma y Ciclo de Vida¶
La seguridad no depende de un componente único. Se aplica en capas, para que el fallo de una no exponga la aplicación entera.
Cada capa cubre lo que deja pasar la de arriba — y el nivel de protección puede adaptarse por entorno, sin exigir que toda aplicación use exactamente la misma configuración.
Sistema operativo de los workers¶
La solución no depende de una única distribución Linux. Los nodos worker usan el sistema operativo adecuado a los requisitos de compatibilidad y seguridad del proyecto: distribuciones mínimas, distribuciones Cloud Native, sistemas inmutables, distribuciones corporativas o perfiles con hardening específico.
El criterio de selección considera la compatibilidad de la aplicación, la superficie de ataque, la gestión del ciclo de vida y los requisitos de cumplimiento. El objetivo es mantener el SO del worker como una capa de plataforma controlada, sin servicios ni componentes innecesarios.
El hardening aplicado puede incluir:
- instalación mínima, con servicios innecesarios eliminados o deshabilitados;
- actualizaciones controladas, en ventana de mantenimiento;
- políticas restrictivas de permisos del sistema de archivos;
- acceso SSH restringido o deshabilitado según el perfil;
- hardening de kernel;
- configuraciones alineadas con CIS Benchmarks cuando se requiere o se contrata.
Capa Kubernetes¶
En la plataforma se aplican:
- RBAC de mínimo privilegio — service accounts con lo estrictamente necesario;
- Pod Security Standards — restricciones a contenedores privilegiados;
- aislamiento por namespace — separación entre equipos, entornos y aplicaciones;
- ejecución como no-root, con capabilities de Linux reducidas;
- sistema de archivos raíz de solo lectura, cuando la aplicación lo soporta;
- políticas de recursos — requests, limits y cuotas por namespace;
- auditoría y monitoreo del plano de control.
Red con Cilium¶
La capa de red del clúster usa Cilium, lo que permite aplicar conectividad y seguridad directamente a las cargas, con políticas basadas en identidad en lugar de direcciones IP:
| Capacidad | Qué entrega |
|---|---|
| Network Policies L3/L4 | Control explícito de quién habla con quién |
| Políticas por identidad | Reglas que sobreviven al cambio de IP de los pods |
| Segmentación por namespace | Aislamiento entre entornos y equipos |
| Observabilidad de red | Visibilidad de flujos permitidos y bloqueados |
| Cifrado entre nodos | Tráfico node-to-node cifrado, cuando la arquitectura lo prevé |
En la práctica, el frontend habla con la API, la API habla con la base, y el frontend no habla con la base. Esto reduce el movimiento lateral si una aplicación es comprometida.
Las políticas se definen según los requisitos de aislamiento de cada clúster — no existe un conjunto único impuesto a todos los entornos.
Ciclo de vida gestionado¶
Los clústeres ejecutan versiones estables y soportadas de Kubernetes. InteSys gestiona el ciclo de vida de la plataforma:
- planificación de actualizaciones y seguimiento de versiones soportadas;
- actualización progresiva de los nodos worker, sin parada del entorno;
- compatibilidad entre componentes y actualización de la CNI;
- validación de las cargas tras cada actualización;
- reemplazo controlado de nodos;
- monitoreo de salud del clúster.
El objetivo es mantener la plataforma actualizada sin transferir la complejidad operativa de ese mantenimiento al equipo del cliente.
División de responsabilidades¶
| Capa | Responsable |
|---|---|
| Centro de datos, red e infraestructura | InteSys (o el proveedor elegido para esa región) |
| Sistema operativo de los workers y hardening | InteSys |
| Control plane, actualizaciones y CNI | InteSys |
| Políticas de red, RBAC y namespaces | InteSys, según requisitos del cliente |
| Aplicaciones, imágenes y dependencias | Cliente |
| Esquema, datos y reglas de negocio | Cliente |
InteSys no reemplaza a su equipo de desarrollo
El modelo más común es que InteSys asuma plataforma, red, seguridad de infraestructura y ciclo de vida, mientras el equipo del cliente sigue siendo dueño de las aplicaciones que corren encima.
Páginas Relacionadas¶
- Kubernetes Gestionado — Visión general de la plataforma
- Multi-Región y Multi-Cloud — Topología, planificación y balanceo global
- Kubernetes en el día a día — Deployments, probes, HPA e ingress
- DevOps como Servicio — DevSecOps, CI/CD y observabilidad
- Contáctenos — Converse sobre los requisitos de seguridad de su entorno