Cómo aislamos a los tenants a nivel del kernel

El problema de las fronteras blandas

Los contenedores corrientes sobre un kernel compartido son un formato de empaquetado, no una frontera de seguridad. Por defecto, todos los contenedores de un host comparten la misma superficie de ataque del kernel, el mismo planificador y las mismas colas de IO. Si un tenant encuentra una vulnerabilidad del kernel — o simplemente ejecuta una fork bomb — el radio de impacto es la máquina entera, incluidos todos los demás clientes que aloja.

Los vecinos ruidosos son la versión cotidiana del mismo fallo. Sin límites impuestos, el trabajo por lotes de un tenant puede robar ciclos de CPU, saturar el IO de disco y expulsar de la memoria las páginas de otro tenant. La multitenencia hostil exige fronteras que el kernel haga cumplir, no convenciones que solo respeta una carga de trabajo bien educada.

Namespaces, cgroups y seccomp

En Anested Cloud, cada carga de trabajo de un tenant recibe sus propios namespaces de PID, red y montaje. Los procesos de un tenant literalmente no pueden ver, señalizar ni rastrear los de otro; cada carga de trabajo ve su propia vista privada del sistema de archivos y su propia pila de red. Esto lo impone el kernel de Linux en cada syscall, no un motor de políticas que pueda configurarse mal.

Sobre los namespaces añadimos el control de recursos de cgroup v2 y el filtrado de syscalls de seccomp. Las cuotas limitan el tiempo de CPU, la memoria y el IO de bloque por tenant, de modo que un proceso desbocado se estrangula a sí mismo en lugar de estrangular al host. Los perfiles seccomp rechazan las syscalls que una carga de trabajo no tiene por qué hacer, cortando clases enteras de exploits del kernel antes de que lleguen a código vulnerable.

• Namespace de red dedicado, con su propia interfaz virtual y sus propias reglas de firewall
• Cuotas de cgroup v2 para CPU, memoria e IO de bloque
• Perfiles seccomp que solo permiten las syscalls que la carga de trabajo necesita
• Sistemas de archivos raíz de solo lectura, con montajes escribibles explícitos

Aislamiento de red por tenant

Cada tenant vive en su propia red virtual privada. Las reglas de firewall se generan por tenant y deniegan todo por defecto: no existe ruta entre las cargas de trabajo de un tenant y las de otro, así que el tráfico este-oeste entre tenants es imposible por construcción. Escanear los puertos del vecino desde un VPS de Anested no devuelve ni siquiera puertos cerrados: los paquetes nunca salen de tu namespace de red.

El tráfico público entra por el proxy de borde y por ningún otro sitio. TLS termina en el borde, las peticiones se enrutan a la red de exactamente un tenant, y los servicios internos nunca aceptan conexiones desde fuera de su propio segmento. El resultado es una topología en la que la única superficie alcanzable es la que expusiste deliberadamente.

Qué significa esto para las bases de datos

Los mismos muros se aplican a cada base de datos gestionada PostgreSQL, MongoDB y MySQL que operamos. Cada instancia queda confinada por sus propios namespaces, límites de cgroup v2 y perfil seccomp, así que la consulta lenta o la construcción de índices desbocada de un tenant no puede privar de CPU, memoria o IO a la base de datos de otro. Tu latencia p99 depende de tu carga de trabajo, no de la de tu vecino.

Las cadenas de conexión tienen alcance por base de datos y solo se resuelven dentro de la red del tenant propietario. Incluso una credencial filtrada es inútil desde el segmento de otro tenant, porque los paquetes sencillamente no pueden llegar allí. El aislamiento en las capas de kernel y de red significa que el control de acceso de la base de datos no es tu última línea de defensa: es una entre varias.

Defensa en profundidad, por defecto

No se confía en que ninguna capa sea perfecta. Los hosts se parchean con un calendario progresivo, con migración en vivo cuando es posible; los kernels se mantienen al día frente a CVE conocidas; y cada capa se monitoriza en busca de anomalías, desde denegaciones inesperadas de syscalls hasta tráfico entre namespaces que nunca debería existir. Cada componente interno se ejecuta con el mínimo privilegio necesario, para que el compromiso de un servicio no se propague.

Nada de esto es un extra empresarial. El aislamiento a nivel del kernel, la red por tenant y las cuotas de recursos se aplican a cada carga de trabajo en Anested Cloud, incluido el plan gratuito. Una seguridad que depende de tu plan de facturación no es seguridad; es una página de precios.