Files
SnapOtter/apps/docs/es/guide/users-roles.md
T
SnapOtterandGitHub d10d0f544f fix: release QA hardening across processing, media, security, and CI gates (#649)
A release-readiness QA pass over the whole product. The commits split into
defects a user would hit and gates that were reporting green while measuring
nothing.

## Fixes that change behaviour

Rate limiting was bypassable on every install: TRUST_PROXY defaulted to true, so
request.ip came from a client-set header and a forged X-Forwarded-For got past
the login limiter. The default is now a private-network trust list.

A transient Postgres outage stranded in-flight jobs, leaving finished output on
disk with no row pointing at it. A reconciler now resolves those rows and adopts
the bytes rather than dropping the work.

A Redis connection that moved to a new address wedged every read-blocked
consumer, so completions stopped signalling while health still answered 200.
Socket timeouts plus subscriber pings recover it.

Installing more than one AI bundle left the shared venv multi-versioned and
silently broke three tools. The installer now reconciles distributions to one
version each.

Converting an image to JXL at quality 1 through 4 returned a 500, because
libjxl 0.7 rejects the distance those values compute. The quality is floored at
what the encoder honours. A missing ffmpeg was also reported to the user as a
corrupt upload; it now says the engine is unavailable.

RAW uploads reached an unpatched LibRaw on arm64, so it is built from source at
0.22.2, and the release scan was split so it can fail on an unfixed critical
instead of hiding it behind ignore-unfixed.

## Gates that could not fail

Two mutation lanes ran zero mutants because Stryker crawled the gitignored docs
build; coverage discarded its whole report on any failing test; the lint gate
skipped root tests, scripts, and two workspaces; and several generated matrices
counted a host missing ffmpeg as a passing tool. Each now measures what it
claims.

Full evidence and the outstanding release items are tracked locally and are not
part of this branch.
2026-07-27 15:37:30 +08:00

14 KiB

description, i18n_source_hash, i18n_provenance, i18n_output_hash, i18n_hash_version
description i18n_source_hash i18n_provenance i18n_output_hash i18n_hash_version
Gestiona usuarios, roles integrados y personalizados, permisos, claves de API, equipos, sesiones y el registro de auditoría en SnapOtter. bea8955f3aff human c5ce9d432c7d 2

Usuarios, roles y permisos

SnapOtter incluye tres roles integrados, 17 permisos granulares y compatibilidad con roles personalizados con control de acceso opcional por herramienta. Esta página cubre el modelo de autorización completo, el alcance de las claves de API, la gestión de equipos y el registro de auditoría.

::: tip Páginas relacionadas OIDC / SSO | SAML SSO | Aprovisionamiento SCIM | Seguridad y fortalecimiento :::

Usuarios

Crear usuarios

Los administradores pueden crear usuarios a través del panel de administración o el endpoint POST /api/auth/register. Cada usuario tiene un nombre de usuario, un rol, una asignación de equipo y una dirección de correo electrónico opcional.

Administrador predeterminado

En el primer arranque, SnapOtter crea una cuenta de administrador predeterminada. Las credenciales provienen de variables de entorno:

Variable Predeterminado Descripción
DEFAULT_USERNAME admin Nombre de usuario de la cuenta de administrador inicial
DEFAULT_PASSWORD admin Contraseña de la cuenta de administrador inicial

Se requiere que el administrador predeterminado cambie su contraseña en el primer inicio de sesión.

Proveedores de autenticación

Los usuarios pueden autenticarse mediante varios métodos:

  • Local: nombre de usuario y contraseña almacenados en la base de datos de SnapOtter
  • OIDC: cualquier proveedor de OpenID Connect (consulta OIDC / SSO)
  • SAML: proveedores de identidad SAML 2.0 (consulta SAML SSO)
  • SCIM: aprovisionamiento automatizado desde un proveedor de identidad (consulta Aprovisionamiento SCIM)

Desactivar la autenticación

Establece AUTH_ENABLED=false para desactivar por completo la autenticación. En este modo se usa un usuario anónimo sintético con el rol admin para todas las solicitudes. No se requiere inicio de sesión.

::: warning Desactivar la autenticación otorga acceso total de administrador a cualquiera que pueda alcanzar la instancia. Úsalo solo en entornos de confianza. :::

Roles integrados

SnapOtter incluye tres roles integrados. No se pueden modificar ni eliminar.

Administrador

Los 17 permisos. Control total sobre la instancia.

tools:use files:own files:all apikeys:own apikeys:all pipelines:own pipelines:all settings:read settings:write users:manage teams:manage features:manage system:health audit:read compliance:manage webhooks:manage security:manage

Editor

7 permisos. Puede usar todas las herramientas y gestionar todos los archivos y pipelines, pero no puede acceder a las funciones de administración.

tools:use files:own files:all apikeys:own pipelines:own pipelines:all settings:read

Usuario

5 permisos. Puede usar herramientas y gestionar sus propios recursos.

tools:use files:own apikeys:own pipelines:own settings:read

Referencia de permisos

Permiso Descripción
tools:use Usar cualquier herramienta de procesamiento
files:own Ver y gestionar los archivos propios
files:all Ver y gestionar los archivos de todos los usuarios
apikeys:own Crear y gestionar las claves de API propias
apikeys:all Ver las claves de API de todos los usuarios
pipelines:own Crear y gestionar los pipelines propios
pipelines:all Ver y gestionar los pipelines de todos los usuarios
settings:read Ver la configuración de la instancia
settings:write Modificar la configuración de la instancia
users:manage Crear y administrar cuentas de usuario dentro de los límites de autoridad del actor.
teams:manage Crear, actualizar y eliminar equipos
features:manage Instalar y gestionar bundles de funciones de IA
system:health Acceder a los endpoints de estado y disponibilidad
audit:read Ver el registro de auditoría y listar roles
compliance:manage Gestionar el ciclo de vida del RGPD y las funciones de cumplimiento; Las operaciones destructivas del usuario siguen estando limitadas por la autoridad.
webhooks:manage Configurar webhooks salientes
security:manage Gestionar la configuración de seguridad (lista de IP permitidas, imposición de SSO)

Roles personalizados

Los administradores con el permiso security:manage pueden crear roles personalizados a través del panel de administración o la API de roles. Listar roles requiere audit:read.

Crear un rol personalizado

curl -X POST http://localhost:1349/api/v1/roles \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "reviewer",
    "description": "Can use tools and view all files",
    "permissions": ["tools:use", "files:own", "files:all", "settings:read"]
  }'

Los nombres de rol deben tener entre 2 y 30 caracteres, alfanuméricos en minúscula con guiones y guiones bajos.

Límites de administración delegada

Los 17 permisos se pueden delegar a través de roles personalizados, pero un permiso administrativo no hace que ese rol sea equivalente al rol integrado admin. Las mutaciones de usuario autorizadas por users:manage, las operaciones destructivas autorizadas por compliance:manage y la gestión de roles personalizados autorizada por security:manage están limitadas por la autoridad actual del actor:

  • Los roles integrados siguen admin > editor > user; Los roles personalizados están debajo de los roles integrados.
  • Los permisos del objetivo deben estar contenidos en los permisos efectivos del actor. Por lo tanto, una clave API con ámbito no puede ejercer permisos omitidos en su ámbito.
  • El acceso a la herramienta de un rol objetivo debe estar contenido en el acceso a la herramienta del propio actor.
  • Una cuenta deshabilitada se compara con su función original cuando esa función se registra como disabled:<original-role>.
  • Eliminar un rol personalizado también requiere autoridad para asignar el respaldo user incorporado; los miembros discapacitados permanecen discapacitados como disabled:user.

Las credenciales y la configuración globales son más estrictas: emitir o revocar el token SCIM e importar la configuración de la instancia requieren la función admin incorporada con autoridad de administrador efectiva completa.

Permisos a nivel de herramienta

Los roles personalizados pueden restringir opcionalmente a qué herramientas pueden acceder los usuarios. Hay dos modos disponibles:

Modo Comportamiento Requisito de licencia
category Restringir por modalidad (imagen, video, audio, documento, archivo) Ninguno (gratis)
tool Restringir por ID de herramienta individual Requiere la función empresarial per_tool_permissions

Cuando el modo tool está establecido pero la función empresarial no está disponible, SnapOtter se degrada de forma controlada y permite el acceso a todas las herramientas.

{
  "name": "image-only",
  "permissions": ["tools:use", "files:own"],
  "toolPermissions": {
    "mode": "category",
    "allowed": ["image"]
  }
}

Eliminar un rol personalizado

Cuando se elimina un rol personalizado, todos los usuarios asignados a él se reasignan automáticamente al rol user.

Equipos

Los equipos agrupan usuarios para la gestión de almacenamiento y retención. Se crea un equipo Default en el primer arranque.

Campo Tipo Descripción
name cadena Nombre de equipo único (1-50 caracteres)
storageQuota número Límite de almacenamiento por equipo en bytes (funciona sin la edición empresarial)
retentionHours número Eliminar automáticamente las salidas tras esta cantidad de horas (requiere team_retention_overrides, empresarial)
legalHold booleano Impedir la eliminación automática de los archivos de los miembros del equipo (requiere legal_hold, empresarial)

::: info El equipo Default no se puede eliminar. Los equipos que aún tienen miembros no se pueden eliminar. Reasigna primero a los miembros. :::

Claves de API

Los usuarios pueden generar claves de API para el acceso programático. Cada clave usa el prefijo si_ y se muestra una sola vez en el momento de la creación.

Permisos con alcance

Las claves de API pueden llevar opcionalmente un array permissions. Cuando se establece, los permisos efectivos de una solicitud son la intersección de los permisos del rol del usuario y los permisos con alcance de la clave. Esto significa que una clave de API nunca puede escalar más allá de los propios permisos del usuario.

curl -X POST http://localhost:1349/api/v1/api-keys \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CI pipeline key",
    "permissions": ["tools:use", "files:own"],
    "expiresAt": "2027-01-01T00:00:00Z"
  }'

Caducidad

Las claves aceptan una marca de tiempo expiresAt opcional. Las claves caducadas se rechazan en el momento de la autenticación.

Registro de auditoría

SnapOtter registra los eventos relevantes para la seguridad en un registro de auditoría estructurado, almacenado en la tabla de base de datos audit_log.

Ver el registro de auditoría

GET /api/v1/audit-log?page=1&limit=50&action=LOGIN_FAILED&from=2026-01-01T00:00:00Z&to=2026-12-31T23:59:59Z

Requiere el permiso audit:read. Admite paginación (page, limit) y filtros (action, ip, from, to).

Auditoría de operaciones de herramientas

::: warning Los eventos TOOL_EXECUTED no se registran de forma predeterminada. Son de participación voluntaria mediante cualquiera de dos vías:

  1. Establecer la configuración de administrador auditToolOperations en true.
  2. Tener una licencia activa con la función audit_export (disponible tanto en los planes team como enterprise).

Sin una de estas, las ejecuciones individuales de herramientas no se registran en el registro de auditoría. :::

Exportar

GET /api/v1/enterprise/audit/export?format=csv&from=2026-01-01T00:00:00Z

Requiere el permiso audit:read y la función empresarial audit_export (disponible tanto en los planes team como enterprise). Admite los formatos CSV y JSON, filtrados por action, actorId, targetType, targetId, from y to.

Firma resistente a la manipulación

Cuando está habilitado, cada entrada del registro de auditoría se firma con un HMAC derivado de DATA_ENCRYPTION_KEY. Esto requiere:

  1. Establecer DATA_ENCRYPTION_KEY en tu entorno.
  2. Habilitar la configuración de administrador tamperResistantAudit.
  3. Una licencia empresarial con la función tamper_resistant_audit.

Retención

Establece AUDIT_RETENTION_DAYS para purgar automáticamente las entradas antiguas. El valor predeterminado es 0, lo que significa que las entradas se conservan indefinidamente.

Referencia de eventos

Evento Categoría
LOGIN_SUCCESS, LOGIN_FAILED Autenticación
OIDC_LOGIN_SUCCESS, OIDC_LOGIN_FAILED Autenticación
SAML_LOGIN_SUCCESS, SAML_LOGIN_FAILED Autenticación
LOGOUT Autenticación
USER_CREATED, USER_UPDATED, USER_DELETED Gestión de usuarios
PASSWORD_CHANGED, PASSWORD_RESET Gestión de usuarios
MFA_ENROLLED, MFA_DISABLED, MFA_VERIFIED, MFA_VERIFY_FAILED MFA
MFA_CHALLENGE_ISSUED, MFA_RECOVERY_USED, MFA_RESET MFA
ROLE_CREATED, ROLE_UPDATED, ROLE_DELETED Roles
API_KEY_CREATED, API_KEY_DELETED Claves de API
SETTINGS_UPDATED, IP_ALLOWLIST_UPDATED Configuración
FILE_UPLOADED, FILE_DELETED Archivos
TOOL_EXECUTED Herramientas (participación voluntaria)
SCIM_USER_PROVISIONED, SCIM_USER_UPDATED, SCIM_USER_DEPROVISIONED SCIM
SCIM_GROUP_SYNCED SCIM
LEGAL_HOLD_APPLIED, LEGAL_HOLD_RELEASED Cumplimiento
GDPR_EXPORT_INITIATED, GDPR_USER_PURGED, GDPR_TEAM_PURGED Cumplimiento
CONFIG_EXPORTED, CONFIG_IMPORTED Configuración

Gestión de sesiones

Las sesiones se basan en cookies, controladas por SESSION_DURATION_HOURS (predeterminado: 168 horas / 7 días).

Los cambios de rol invalidan las sesiones

Cuando un administrador cambia el rol de un usuario, todas las sesiones activas de ese usuario se eliminan. El usuario debe iniciar sesión de nuevo para adoptar sus nuevos permisos.

Salvaguardas

  • Protección del último administrador: el último administrador que queda no puede ser degradado a un rol inferior. La API devuelve un error si lo intentas.
  • Prevención de autoeliminación: los administradores no pueden eliminar su propia cuenta a través de la API.