Ir al contenido
inicio / methods / efficiency-security
Método transversal

Corre decenas de contenedores en un servidor sin renunciar al aislamiento.

KSM memory sharing comprime la densidad en bare metal. Firecracker + LXC aplican aislamiento por contenedor. Inimaginabilidad de URL, segregación de realm y firewall a nivel de host se añaden encima — cualquiera puede fallar, y los demás siguen deteniendo el impacto.

KSM · LXC + Firecracker · AES-256 · espacio de claves URL 2^192 · defensa en profundidad

Compartición de páginas KSMLXC + FirecrackerEspacio de claves URL 2^192AES-256 en reposo
inicio / methods / efficiency-security / density
Densidad KSM

Páginas compartidas, memoria separada.

Kernel Samepage Merging colapsa páginas de memoria idénticas entre contenedores en copias físicas únicas. Una imagen base Debian, un runtime Node, una instalación Postgres — todos los bytes que comparte cada contenedor del servidor se cuentan una sola vez en RAM.

Páginas idénticas deduplicadas

Las páginas RAM con contenido idéntico (librerías comunes, OS base, runtimes compartidos) se fusionan. 30 contenedores Node en un servidor consumen mucha menos memoria que 30× un contenedor.

Aislamiento preservado

Los contenedores no pueden leer la RAM de los demás. KSM es una optimización de almacenamiento — las páginas fusionadas se vuelven copy-on-write. Cualquier escritura crea instantáneamente una copia privada.

Sin trabajo del lado del contenedor

KSM es a nivel de kernel. Las aplicaciones no necesitan saber nada al respecto. El contenedor ve memoria Linux normal; el host ve deduplicación física.

Beneficio dependiente de la carga

El beneficio escala con cuánto comparten los contenedores. Stacks similares = gran dedup. Apps muy diferentes = menos dedup, pero las páginas del OS base siguen fusionándose.

inicio / methods / efficiency-security / isolation
Capas de virtualización

LXC + Firecracker. Namespaces del kernel + micro-VMs.

Hoody usa un modelo de aislamiento de doble capa. LXC proporciona aislamiento de contenedor Linux ligero mediante namespaces. Firecracker añade fronteras de micro-VM asistidas por hardware donde importa una separación más fuerte. El kernel del host está reforzado (base Linux 7.0.2-hoody) con filtrado de syscalls seccomp encima.

Namespaces LXC

Proceso, red, montaje, usuario, PID, IPC — cada contenedor tiene su propia vista del kernel. Mecanismo Linux estándar, probado en batalla a escala.

Micro-VMs Firecracker

Fronteras con virtualización por hardware. La tecnología de aislamiento de AWS Lambda. Aplicada donde un contenedor necesita una barrera más dura que los namespaces solos.

Kernel reforzado

Base Linux 7.0.2-hoody con hardening de seguridad. Los filtros seccomp restringen qué syscalls puede hacer un contenedor.

Baseline bare metal

Los contenedores corren en hardware del usuario. Sin hypervisor compartido con otros tenants. Sin canales laterales de vecinos ruidosos del proveedor cloud por encima de ti.

inicio / methods / efficiency-security / encryption
Datos en reposo

AES-256 en todos los datos que tocan el disco.

Cifrado del filesystem, swap cifrado, archivos temporales cifrados. Desbloqueo remoto vía sub-partición. El disco es texto cifrado; el descifrado ocurre en RAM al arrancar.

Filesystem AES-256

Cada byte escrito en disco está cifrado. Pierde la unidad, no pierde nada legible.

Swap + temp cifrados

Las páginas de swap y los archivos temporales nunca llegan al disco en texto claro. Los volcados de memoria del kernel también están cifrados.

Desbloqueo remoto por sub-partición

El flujo de arranque soporta descifrado remoto por SSH al initramfs. Sin claves de disco almacenadas físicamente con los datos.

inicio / methods / efficiency-security / urls
Inimaginabilidad de URL

2^192 combinaciones. La fuerza bruta no es el ataque.

Los IDs de proyecto son 24 caracteres hexadecimales. Los IDs de contenedor son 24 caracteres hexadecimales. Una URL válida requiere ambos. El espacio de claves es 2^192 — a un billón de intentos por segundo, la enumeración tarda más que la edad del universo. La inimaginabilidad es un default de partida, no la única capa.

Espacio de claves del par

2^192

Para enumerar a 1T/s

más que la edad del universo

Capas adicionales disponibles

JWT · Password · IP · Token

El modo abierto por URL es el punto de partida. Bloquea cualquier URL con JWT, HTTP Basic, IP CIDR o bearer token vía /platform/proxy — sin necesidad de código de aplicación.

inicio / methods / efficiency-security / defense
Defensa en profundidad

Seis capas independientes. Cualquier fallo deja cinco más.

La seguridad es un stack, no una puerta. Cada capa es efectiva de forma independiente; juntas hacen que un fallo único sea manejable.

1

Inimaginabilidad de URL

Espacio de claves 2^192 en combos proyecto+contenedor. La URL en sí es el primer secreto.

2

Aislamiento de contenedor

Namespaces LXC + micro-VMs Firecracker. Separación a nivel de kernel.

3

Firewall a nivel de host

Reglas de entrada + salida aplicadas en el host, no dentro del contenedor. A prueba de manipulaciones.

4

Permisos del proxy

Grupos de auth JWT / Password / IP / Token añadidos encima de las URLs.

5

Segregación de realms

Aislamiento de tenants a nivel de API. Tokens con alcance a realms específicos.

6

Cifrado de disco

AES-256 en reposo. Swap cifrado. Arranque con desbloqueo remoto.

inicio / methods / efficiency-security / observability
Observabilidad + MITM

Todo es una solicitud HTTP inspeccionable.

Trazas de auditoría unificadas. Cada acción contra un contenedor es una entrada en los logs del proxy. Cualquier servicio puede ser MITM'd vía hoody-exec o hoody-curl para añadir controles de seguridad IA, logging o rate limits sin modificar el servicio.

Logs de auditoría unificados

Los logs del proxy cubren cada servicio. Consultar, exportar (NDJSON), agregación de estadísticas — todo vía la API de logs de /platform/proxy.

MITM por diseño

Inserta middleware entre cualquier servicio y sus clientes. Usado para puertas de seguridad IA, logging de cumplimiento, rate limiting — sin cambios en el servicio.

Fork de plataforma

Cada usuario puede hacer MITM de la propia API de Hoody para personalizar el comportamiento de la plataforma — sin hacer fork del código.

inicio / methods / efficiency-security / revocation
Revocación instantánea

¿Sospechas una brecha? Elimina el contenedor.

Cada URL de contenedor muere en el momento en que el contenedor es eliminado. Sin propagación DNS. Sin invalidación de caché. Sin tokens obsoletos que rotar. La URL era la superficie; eliminar el contenedor elimina la superficie por completo.

DELETE /api/v1/containers/ID

Una llamada a la API. Autenticada con tu JWT o token del control plane.

La URL deja de enrutar

El proxy elimina la entrada de enrutamiento. El hostname devuelve 404 inmediatamente — no 60 segundos después.

Rearranca en minutos

Crea un nuevo contenedor con un nuevo ID. Nueva URL. La URL anterior está muerta para siempre. Sin credenciales residuales que rotar.

inicio / methods / efficiency-security / empezar
Empezar

La densidad y el aislamiento no son compromisos aquí.

Bare metal. Kernel reforzado. Disco cifrado. Defensa de seis capas. Cada propiedad ya es verdad en tu primer contenedor.

Guía de seguridad

Ver también — /platform/proxy para permisos URL y grupos de auth, /platform/control-plane para gestión de realm/token, /methods/access-network para firewall + egreso.