Perfiles de Seguridad

Name: Mentat
Author: Mentat

Mentat implementa una arquitectura zero trust a nivel de infraestructura. Cada workload se asume hostil y se aisla acorde. La plataforma provee cuatro zonas de confianza — cada una con fronteras de seguridad explicitas aplicadas por el kernel, no por convencion.

Modelo de Runtime Zero Trust

Firecracker	Kernel dedicado por workload (KVM/VT-x). Aislamiento mas fuerte — usado para clusters Raft y servicios criticos
Sandbox	Aislamiento con namespaces Linux (PID + mount + UTS + IPC) con limites cgroups v2, pivot_root y TODAS las capabilities eliminadas. Sin daemon Docker. 2MB overhead
Docker Hardened	Ruta de compatibilidad con rootfs read-only, sin capabilities, sin nuevos privilegios, bind mounts restringidos
Docker Legacy	Ruta de migracion para workloads que aun no estan listos para politica estricta
Exec Internal	Procesos a nivel host permitidos solo para componentes internos de confianza

Perfiles Recomendados

security profiles

security:
  profiles:
    firecracker:
      driver: firecracker
      isolation: strong
      allow_privileged: false
      read_only_rootfs: true
      persistent_volumes: allowed
      network_policy: private-by-default
      intended_for:
        - public APIs
        - multi-tenant workloads
        - sensitive internal services

    docker-hardened:
      driver: docker
      isolation: medium
      run_as_non_root: true
      read_only_rootfs: true
      drop_capabilities: ["ALL"]
      no_new_privileges: true
      seccomp: strict
      apparmor: default
      docker_socket: forbidden
      bind_mounts:
        host_system_paths: forbidden
        service_data_paths: allowed
      intended_for:
        - nextjs SSR
        - node services
        - java application servers

    docker-legacy:
      driver: docker
      isolation: transitional
      run_as_non_root: preferred
      read_only_rootfs: preferred
      drop_capabilities: minimal
      no_new_privileges: true
      seccomp: default
      apparmor: default
      intended_for:
        - legacy containerized services
        - migration workloads

    sandbox:
      driver: sandbox
      isolation: strong
      namespaces: [pid, mount, uts, ipc]
      pivot_root: true          # NOT chroot
      capabilities: none        # ALL dropped
      no_new_privileges: true
      cgroups_v2:
        memory: enforced
        cpu: enforced
        pids: enforced
      init_binary: sandbox-init # 15KB static C binary as PID 1
      intended_for:
        - Next.js / React apps
        - Node.js services
        - static web servers
        - any workload that doesn't need a full VM

    exec-internal:
      driver: exec
      isolation: low
      host_access: direct
      allowed_nodes: ["internal-only"]
      internet_exposed: false
      intended_for:
        - agents
        - collectors
        - operational helpers

Como Usarlos

El modelo practico: servicios criticos en Rust y clusters Raft van a Firecracker (kernel dedicado). Web apps y servicios Node.js van a sandboxes (aislamiento por namespaces, sin daemon Docker). Servicios containerizados existentes quedan en Docker hardened. Agentes internos corren como exec. Cada capa aplica zero trust — ningun workload confia en otro.

Ejemplo por Servicio

service.yaml

name: web-frontend
driver: docker
image: registry.example/web-frontend:latest
security:
  profile: docker-hardened
deploy:
  strategy: rolling

---
name: api-gateway
driver: firecracker
image: /opt/mentat/bin/api-gateway
security:
  profile: firecracker

---
name: web-app
driver: sandbox
config:
  rootfs: /opt/apps/nextjs-standalone
  command: /usr/bin/node
  args: ["server.js"]
  memory_mb: 256
  cpu_percent: 50
  max_pids: 32
security:
  profile: sandbox

---
name: node-agent
driver: exec
config:
  command: /opt/bin/node-agent
security:
  profile: exec-internal

Que Debe Significar Docker Hardened

Ejecutar contenedores como non-root cuando el workload lo permita.
Usar root filesystem read-only por defecto.
Eliminar capabilities de Linux de forma agresiva, idealmente todas.
Habilitar no-new-privileges.
Aplicar seccomp estricto y AppArmor o SELinux cuando exista soporte.
Prohibir contenedores privileged y montajes del Docker socket.
Prohibir paths sensibles del host como /var/lib/docker, /var/log y los directorios de estado de Mentat.
Limitar bind mounts a paths de datos explicitamente permitidos.
Exigir un solo puerto expuesto no privilegiado para servicios hardened con ingress.
Mantener docker-legacy completamente fuera del ingress publico.
Aplicar limites de CPU y memoria desde la plataforma.

Forma Comercialmente Honesta

El valor no es que todo se vuelva microVM de un dia para otro. El valor es que Mentat puede orquestar runtimes mixtos bajo un solo control plane imponiendo una postura clara: aislamiento fuerte para servicios criticos, contenedores hardened para aplicaciones existentes y una ruta acotada para compatibilidad legacy.