Seguridad

Aislamiento#

Cada servicio corre en su propio sandbox en nodos compartidos:

• gVisor (runtime por defecto) intercepta las syscalls en espacio de usuario, así que el contenedor nunca habla directamente con el kernel del host.
• Kata Containers ejecuta un servicio en una microVM ligera con su propio kernel. Los builds siempre corren en Kata; elígelo para servicios que necesiten un kernel completo (runtimeClass: kata).
• Cada entorno de proyecto es un namespace de Kubernetes con una cuota de recursos. La memoria nunca se sobreasigna; la CPU puede compartirse hasta 3×; la E/S de disco tiene un tope por namespace.
• Solo nuestros componentes de sistema corren con un runtime de contenedores convencional.

Los nodos están en centros de datos de Hetzner en la UE (Finlandia y Alemania); más regiones más adelante. Los datos no salen de la UE.

Red#

• Los namespaces están aislados con una política de red de denegación por defecto: los servicios de proyectos distintos no pueden alcanzarse entre sí; los servicios de entornos distintos del mismo proyecto tampoco.
• El tráfico entrante llega a un servicio solo a través de sus dominios públicos (TLS terminado en el edge) o de un proxy TCP que hayas creado explícitamente.
• El tráfico saliente está abierto salvo el puerto 25 (SMTP): usa una API de correo o el puerto de envío de un proveedor (587) con autenticación.
• Los nodos aceptan conexiones entrantes solo en 80, 443, SSH para operadores y el rango de los proxies TCP.

Secretos y variables#

Los valores de las variables se cifran en reposo con AES-256-GCM; la clave vive solo en el entorno del plano de control, no en la base de datos. Los valores se descifran cuando se renderiza un despliegue y se pasan al nodo por un WebSocket autenticado que el propio nodo abrió (los nodos no tienen puerto de API entrante). El panel muestra los valores a los miembros del espacio de trabajo; la CLI y el servidor MCP los enmascaran por defecto.

Los logs del build y los logs de runtime se guardan tal como tu proceso los escribió: no imprimas secretos.

Cuentas y tokens#

• El inicio de sesión es únicamente con OAuth de GitHub; no hay contraseñas que se puedan filtrar.
• Roles del espacio de trabajo: owner, admin, member. Facturación, tokens y miembros requieren admin.
• Los tokens de API se guardan con hash, se muestran una sola vez, están acotados a un espacio de trabajo con read o write y pueden tener fecha de expiración. Los tokens de proyecto están acotados a un entorno y no pueden leer la facturación ni otros proyectos.
• Cada mutación se escribe en el registro de auditoría del espacio de trabajo con actor, destino e IP.

Autenticación en dos pasos y sesiones#

• Correo. La dirección viene de GitHub y se verifica automáticamente cuando GitHub ya la ha verificado. Si la cambias en Ajustes → Seguridad, enviamos un código de 6 dígitos (válido 15 minutos, 5 intentos). Hasta que la nueva dirección esté confirmada no le enviamos notificaciones, y el crédito de prueba y de referidos queda en espera.
• 2FA (TOTP). Actívala en Ajustes → Seguridad: escanea el código QR con cualquier app de autenticación (Google Authenticator, 1Password, Authy…) e introduce el código que muestra. Recibes 10 códigos de recuperación, que se muestran una sola vez: descarga el .txt o guárdalos en un gestor de contraseñas; cada uno te permite iniciar sesión una vez si pierdes el dispositivo. Activar o desactivar 2FA cierra todas las demás sesiones. Los administradores de la plataforma deben mantener 2FA activada.
• Iniciar sesión con 2FA. Después de GitHub llegas a un segundo paso que pide el código actual (o un código de recuperación). Hasta que lo introduzcas la sesión no puede usar la API.
• Las acciones sensibles vuelven a preguntar. Con 2FA activada, crear tokens de API o de CLI, autorizar un cliente MCP, cambiar el correo, desactivar 2FA, eliminar un espacio de trabajo o un proyecto con volúmenes y cambiar el límite de gasto o la recarga automática piden un código nuevo una vez cada 10 minutos («modo sudo»). Los tokens emitidos a la CLI y a clientes MCP no se ven afectados.
• Sesiones. Ajustes → Seguridad muestra cada navegador con sesión iniciada en tu cuenta con IP, dispositivo y última actividad. Revoca una, o usa Cerrar sesión en todas partes para conservar solo el dispositivo actual. La cookie de sesión es HttpOnly, Secure y SameSite=Lax, y caduca a los 30 días.

Acceso por shell#

skiffly ssh y la pestaña Terminal abren un shell dentro de un contenedor en ejecución de tu servicio. La sesión va de tu cliente a la API por WebSocket con tu token, y de la API al nodo por la conexión propia del nodo; el contenedor nunca se expone a internet. Las sesiones requieren el rol member (y el scope write en el caso de los tokens), se limitan a cinco por usuario y 30 minutos de inactividad, y quedan en el registro de auditoría como service.exec.

GitHub#

Los repositorios privados se clonan con tokens de instalación de corta duración de la GitHub App de Skiffly; no se guarda ningún personal access token. Los pull requests desde forks nunca se despliegan en entornos de vista previa.

Respaldos#

Los volúmenes se respaldan a diario mediante snapshots en almacenamiento de objetos cifrado y alojado en la UE, con retención 7/4/3 (diaria/semanal/mensual); Postgres y MySQL reciben además dumps lógicos en la misma ejecución. Se pueden restaurar en un clic desde el panel, con skiffly backups restore o con la herramienta MCP restore-backup (antes se toma un respaldo de seguridad). Ver Volúmenes y bases de datos.

Reportar#

¿Encontraste algo? Escribe a security@skiffly.dev. Por favor, no hagas pruebas contra los servicios de otros clientes.