Administración

Seguridad de la instalación

Aislamiento de Docker, secretos, sesiones, protección de salida, distribución y límites actuales.

En esta página

Esta página reúne los controles de seguridad de la instalación en la versión 3.7 y los límites actuales, para la evaluación de su equipo de seguridad de la información.

Aislamiento del Docker del servidor

La API nunca recibe el socket de Docker. Un servicio separado, docker-guard, sin red, es el único con ese acceso y solo permite la gestión de los modelos locales:

  • Solo los contenedores de esta instalación, nunca los de otro proyecto Compose.
  • Contenedores creados únicamente a partir de las imágenes de runtime conocidas, con las etiquetas y la red de esta instalación y volúmenes con nombre propios.
  • Acceso a dispositivos limitado a las GPU NVIDIA o a /dev/dri, y solo en los contenedores de modelo.
  • Sin modo privilegiado, sin montajes del servidor, sin red del servidor y sin capacidades adicionales.
  • Los contenedores de la propia plataforma no pueden detenerse ni eliminarse a través de él.

Cada rechazo queda registrado en el log de docker-guard.

Secretos y credenciales

  • Cada instalación genera su propio APP_SECRET y credenciales exclusivas para PostgreSQL, Redis y MinIO. En producción, se rechazan los secretos cortos (menos de 32 caracteres) o débiles.
  • Los archivos generados por la instalación solo pueden ser leídos por su propietario.
  • Las claves de proveedores y las credenciales de integraciones se cifran en la base de datos con XChaCha20-Poly1305, vinculadas al alcance y al nombre de cada secreto.
  • Las contraseñas se almacenan con hash Argon2.
  • Los secretos nunca llegan al navegador.

Autenticación y sesiones

  • Inicio de sesión local con contraseña de al menos 12 caracteres y bloqueo temporal tras fallos repetidos.
  • SSO OIDC con Microsoft Entra ID, Google Workspace o cualquier proveedor OIDC; la autenticación multifactor queda a cargo del proveedor de identidad.
  • Cuenta root fuera del SSO, recuperable en el servidor con una clave de un solo uso verificada sin conexión.
  • Sesiones en cookie HttpOnly y SameSite=Strict, con Secure detrás de HTTPS.

Consulte Usuarios, roles y acceso.

Protección de salida

Las URL que un usuario puede influir pasan por una protección contra SSRF: las direcciones privadas, de loopback, link-local, CGNAT y de metadatos de nube se bloquean, salvo habilitación explícita en APTABIT_SSRF_ALLOWED_HOSTS. Las llamadas de integración no siguen redirecciones. Consulte Integraciones.

Red y TLS

El proxy de la plataforma atiende HTTP en un único puerto (8080 por defecto). El TLS se termina en el balanceador o en el proxy inverso de la organización. La CLI confía en las autoridades de certificación del sistema, lo que permite operar detrás de proxies corporativos que inspeccionan HTTPS.

Distribución e integridad

  • El script de instalación verifica la CLI con el manifiesto de versión firmado por Aptabit (Ed25519). aptabit self-update realiza la misma verificación antes de reemplazar el binario.
  • Las imágenes provienen de un registry privado, con credenciales de corta duración que Aptabit Manager emite para una licencia activa, mediante una solicitud firmada con la identidad de la instalación.
  • Cada imagen recibida lleva una declaración de procedencia firmada por Aptabit Manager que identifica quién la recibió.
  • Cada instalación tiene un par de claves Ed25519 generado en la propia máquina; Aptabit Manager guarda solo la clave pública.

Datos en reposo

Los documentos, tablas, vectores y archivos permanecen en el PostgreSQL, el MinIO (o servicio S3) y el Milvus de la instalación. Los secretos los cifra la plataforma; el cifrado de los volúmenes y del almacenamiento de objetos lo proporciona la infraestructura de la organización, en el disco o en el servicio S3.

Límites actuales

  • Cada instalación se ejecuta en un único servidor. La alta disponibilidad depende de PostgreSQL, Redis, S3 y Milvus gestionados externamente.
  • El aislamiento entre organizaciones lo realiza la aplicación, con una organización por instalación; la base de datos no utiliza row-level security.
  • El registro de auditoría no se borra en las depuraciones ni puede editarse por la API, pero la base de datos no impone inmutabilidad técnica.
  • Los backups de la CLI son locales y no están cifrados. Consulte Operación.

Planificado: HTTPS integrado con emisión automática de certificados, integración con gestores externos de secretos, SBOM de cada versión y operación en Kubernetes.

© 2026 NVIDIA and the NVIDIA logo are trademarks and/or registered trademarks of NVIDIA Corporation in the U.S. and other countries.

Documentaciónv3.7