VaultS3 en mi homelab (Parte 2): un usuario, varios equipos y la clave a salvo

En el primer artículo dejé VaultS3 corriendo en mi Intel NUC sobre un RAID 1, con cifrado en reposo y scripts para encender y apagar la caja de discos. Hasta ese punto todo lo hacía con la cuenta de administrador, que no es lo que uno quiere para el día a día.

En esta segunda parte cuento cómo organicé el acceso desde mis equipos, las restricciones que agregué y cómo respaldé la clave de cifrado, otra vez con los errores incluidos.

Ojo con tu red: uso 192.168.1.x como ejemplo. Tu segmento puede ser otro; verifícalo antes de copiar comandos.

El problema: una persona, varios equipos

Quería usar VaultS3 desde:

• mi MacBook Air M5,
• mi Mac mini M4,
• el MacBook Air M4 del trabajo (un equipo corporativo).

La primera idea “de manual” sería crear un usuario por equipo, pero no tenía sentido: soy una sola persona. Lo que sí quería era poder revocar un equipo sin afectar a los demás, y que el equipo corporativo no viera mis archivos personales.

La solución es la práctica estándar: una identidad por persona y una llave de acceso por equipo.

El alcance de cada llave lo comprobé con pruebas positivas y negativas en los pasos siguientes; no lo doy por hecho solo por la configuración.

Ventajas:

• Si pierdo un portátil, revoco solo esa llave y los otros dos equipos siguen funcionando.
• La auditoría registra el ID de la llave usada en cada operación. VaultS3 no sabe qué equipo es; la relación entre llave y equipo la llevo yo en mi gestor de contraseñas.
• Si el equipo corporativo se ve comprometido, no expone mis datos personales.

Cómo funcionan las llaves en VaultS3

Lo primero fue revisar la ayuda de la CLI que trae la imagen (vaults3-cli). La ayuda general funciona, pero la de cada subcomando no:

$ docker exec vaults3 vaults3-cli user --help
Error: unknown user subcommand: --help

Así que fui a la documentación de la CLI, donde está lo importante:

• Un usuario puede tener varias llaves, y cada llave tiene su propio alcance.
• key create <usuario> --bucket X le da a esa llave acceso completo a esos buckets. Ese acceso se suma a las políticas del usuario; no las restringe.
• --user-policies hace que la llave tenga exactamente las políticas del usuario, y --all-buckets le da todos los buckets.
• Crear o borrar una llave no cambia lo que pueden hacer las demás.
• Las políticas predefinidas son ReadOnlyAccess, ReadWriteAccess y FullAccess.

Un detalle importante de la misma documentación: este alcance independiente por llave requiere VaultS3 4.4.79 o posterior. En versiones anteriores, crear una llave podía darle más acceso del pedido y cambiar el alcance de las otras llaves del mismo usuario (key create se niega a funcionar contra servidores más viejos). Yo uso la 5.0.2, la última publicada en este momento.

La consecuencia de diseño es clave: el usuario no debe tener políticas propias. Si le asigno FullAccess, todas sus llaves, incluida la del equipo corporativo, verían todos los buckets, y la restricción por equipo se anularía.

Paso 1: buckets y usuario

Creé los buckets desde la CLI:

docker exec vaults3 vaults3-cli bucket create personal
docker exec vaults3 vaults3-cli bucket create trabajo

Y el usuario jmmv desde el dashboard (IAM → Create User), sin asignarle ninguna política: el desplegable se queda en “Attach policy…”.

Paso 2: una llave por equipo

Las llaves sí las creé por CLI, porque ahí el alcance por bucket (--bucket) está documentado:

docker exec vaults3 vaults3-cli key create jmmv --bucket personal --bucket trabajo   # MacBook Air M5
docker exec vaults3 vaults3-cli key create jmmv --bucket personal --bucket trabajo   # Mac mini M4
docker exec vaults3 vaults3-cli key create jmmv --bucket trabajo                     # equipo corporativo
docker exec vaults3 vaults3-cli key list

ACCESS KEY            USER              CREATED
----------            ----              -------
mauro-admin           (built-in admin)  -
9c41e07a2b5d83f6e1a4  jmmv              2026-10-08T21:18:09Z
2f7b6d1e0a93c58b4e21  jmmv              2026-10-08T21:16:57Z
d83a5e2c7f1b9046ac3e  jmmv              2026-10-08T21:17:41Z

Cada key create muestra el secreto una sola vez. Lo guardé de inmediato en mi gestor de contraseñas, anotando a qué equipo corresponde cada llave. VaultS3 no permite ponerle nombre a las llaves, así que esa anotación es importante; la fecha de creación ayuda a relacionarlas.

Paso 3: el MacBook Air M5 con su llave

En el primer artículo el perfil de AWS CLI usaba la cuenta de administrador. La reemplacé por la llave del equipo, porque no quiero la llave de administrador en un portátil:

aws configure --profile vaults3      # llave 1 + su secreto
aws --profile vaults3 s3 ls

Error: AccessDenied en ListBuckets

aws: [ERROR]: An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

• Causa: aws s3 ls sin bucket llama a ListBuckets, un permiso a nivel de cuenta. Una llave limitada con --bucket solo puede operar dentro de sus buckets. No es un error: es parte del aislamiento.
• Solución: trabajar siempre indicando el bucket.

aws --profile vaults3 s3 ls s3://personal/
aws --profile vaults3 s3 cp /tmp/prueba.txt s3://personal/
aws --profile vaults3 s3 cp /tmp/prueba.txt s3://trabajo/
aws --profile vaults3 s3 ls s3://prueba/

upload: ../../tmp/prueba.txt to s3://personal/prueba.txt
upload: ../../tmp/prueba.txt to s3://trabajo/prueba.txt
aws: [ERROR]: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

El aislamiento quedó como lo diseñé:

• personal y trabajo: lectura y escritura.
• prueba (el bucket de pruebas del primer artículo): acceso denegado.

Paso 4: limpieza del bucket de pruebas

Borré el bucket prueba y los archivos de prueba desde el dashboard, y verifiqué desde el NUC:

docker exec vaults3 vaults3-cli bucket list
docker exec vaults3 vaults3-cli storage reclaim
sudo ls -la /mnt/caja-raid/vaults3/data

NAME      CREATED
personal  2026-10-08 21:12:46
trabajo   2026-10-08 21:12:55

  Files scanned:    2
  Orphans found:    0 (0 B)

Error: el borrado incompleto

El bucket prueba ya no estaba, pero reclaim escaneó 2 archivos, y las carpetas personal y trabajo tenían la hora de la subida, no la del borrado.

• Causa: había borrado el bucket prueba, pero olvidé borrar prueba.txt de personal y de trabajo.
• Solución: borrarlos y repetir la verificación.

$ docker exec vaults3 vaults3-cli object ls personal
No objects found.
$ docker exec vaults3 vaults3-cli object ls trabajo
No objects found.
$ docker exec vaults3 vaults3-cli storage reclaim
  Files scanned:    0
  Orphans found:    0 (0 B)

storage reclaim sin --apply solo reporta: es una buena forma de confirmar que lo que se ve en el dashboard coincide con lo que hay en disco.

Paso 5: restricción por IP

VaultS3 permite limitar cada usuario a ciertos rangos de IP (IAM → usuario → IP Restrictions (CIDR)). Antes de usarlo había una duda: con Docker en medio, ¿VaultS3 ve la IP real del cliente o la del puente de Docker?

Hice una petición desde el Mac y revisé Audit:

8/10/2026, 4:31:14 p.m.   jmmv   s3:ListBucket   arn:aws:s3:::personal   Allow   192.168.1.197

VaultS3 ve la IP real del Mac, así que la restricción funciona. Agregué 192.168.1.0/24 al usuario jmmv.

La prueba negativa, para confirmar que de verdad bloquea:

1. Cambié la regla a 192.168.1.40/32 (solo la IP del NUC).
2. Repetí la petición desde el Mac. Resultado en Audit:

8/10/2026, 4:34:40 p.m.   jmmv   s3:ListBucket   arn:aws:s3:::personal   Deny   192.168.1.197   403

3. Restauré 192.168.1.0/24 y el acceso volvió.

No hay riesgo de quedarse por fuera: la restricción es del usuario jmmv; el dashboard lo uso con la cuenta de administrador.

Eso sí: la cuenta de administrador no tiene restricción por IP. Por eso, como conté en la revisión del primer artículo, publiqué el puerto 9000 solo en la IP de la LAN del NUC, y no en todas sus interfaces.

Lo que esto aporta, dicho con precisión: una llave comprometida no debería poder usarse desde una IP de origen fuera de los rangos permitidos. Restringe por la IP que ve VaultS3, no por la identidad del dispositivo: cualquier equipo de mi LAN con una llave válida sí pasa. Reduce la superficie de uso de las credenciales, pero no reemplaza revocar una llave comprometida.

Con las VPN pasa algo parecido: si una petición llega con una IP de origen fuera del rango autorizado, se rechaza. Que eso ocurra o no depende de cómo esté enrutado el tráfico del equipo.

Paso 6: el equipo corporativo

Primero confirmé que el equipo estaba en la LAN y que el NUC respondía:

ipconfig getifaddr en0
curl -s -o /dev/null -w "health=%{http_code}\n" --max-time 5 http://192.168.1.40:9000/health

192.168.1.193
health=200

Configuré el mismo perfil (el endpoint en ~/.aws/config y la llave 3 con aws configure, que la guarda en ~/.aws/credentials) y probé lo importante: que no pudiera ver personal. [CORRECCIÓN: decía “Configuré el mismo perfil (~/.aws/config) con la llave 3”; aws configure guarda las llaves en ~/.aws/credentials, y ~/.aws/config solo guarda la configuración del perfil, como el endpoint. Fuente: documentación de AWS CLI, “Configuration and credential file settings”, https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html]

aws --profile vaults3 s3 ls s3://trabajo/       # vacío, sin error
aws --profile vaults3 s3 ls s3://personal/

aws: [ERROR]: An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Y una prueba de escritura y borrado en trabajo:

echo "test $(date)" > /tmp/t.txt
aws --profile vaults3 s3 cp /tmp/t.txt s3://trabajo/ && aws --profile vaults3 s3 rm s3://trabajo/t.txt && rm /tmp/t.txt

upload: ../../tmp/t.txt to s3://trabajo/t.txt
delete: s3://trabajo/t.txt

En los logs del NUC la denegación se ve así:

level=INFO msg="s3: request refused by policy" reason="access denied: s3:ListBucket on arn:aws:s3:::personal" access_key=9c41e07a2b5d83f6e1a4

Si usas un equipo corporativo, revisa que tu política interna permita guardar credenciales personales en él. Y si tiene VPN corporativa, lo más probable es que mientras esté conectada el tráfico al NUC no salga por tu LAN.

Paso 7: el Mac mini y el misterioso “No route to host”

En el Mac mini todo parecía igual: IP de la LAN, curl al NUC con health=200 y el perfil bien escrito. Pero:

$ aws --profile vaults3 s3 ls s3://personal/
aws: [ERROR]: Could not connect to the endpoint URL: "http://192.168.1.40:9000/personal?list-type=2..."

Era un error de red, no de permisos. Lo extraño era que curl sí llegaba. Descarté proxies y revisé el detalle con --debug:

env | grep -i proxy                # nada
which aws; aws --version           # /opt/homebrew/bin/aws  aws-cli/2.37 Python/3.14 Darwin/25.6 (macOS 26.6)
aws --profile vaults3 s3 ls s3://personal/ --debug 2>&1 | grep -iE 'error|refused|route|timed out|proxy' | head -5

OSError: [Errno 65] No route to host
urllib3.exceptions.NewConnectionError: ... Failed to establish a new connection: [Errno 65] No route to host

Además, en los logs del NUC no aparecía ningún intento desde el Mac mini: la petición ni siquiera salía del equipo.

Separo lo que observé, lo que funcionó y lo que supongo:

• Lo observado: curl llegaba al NUC, la AWS CLI fallaba con No route to host, y la petición no aparecía en los logs del NUC.
• Lo que funcionó:
  1. Configuración del Sistema → Privacidad y seguridad → Red local.
  2. Buscar la app de terminal (en mi caso, iTerm2). Ya estaba activada, así que la apagué y la volví a encender.
  3. Cerrar la terminal por completo (Cmd + Q) y abrirla de nuevo.

aws --profile vaults3 s3 ls s3://personal/   # vacío, sin error
aws --profile vaults3 s3 ls s3://trabajo/    # vacío, sin error

• La hipótesis: el permiso de Red local de macOS, que desde macOS 15 se concede por aplicación. curl es un binario del sistema; la AWS CLI de Homebrew corre sobre su propio Python. Mi suposición es que el permiso quedó desincronizado con la identidad de esos binarios (por ejemplo, tras una actualización de Homebrew) aunque el interruptor se veía encendido, y que apagarlo y encenderlo lo regeneró. No pude confirmarlo ni encontré una explicación oficial de Apple. Lo que sí documenta Apple es que las herramientas que se ejecutan desde Terminal (la de Apple) o por SSH quedan exentas de este permiso; iTerm2 no tiene esa exención, y por eso aparece en la lista de Red local. [CORRECCIÓN: precisión añadida; un lector que use la Terminal de Apple no la encontrará en esa lista, porque macOS da acceso a la red local automáticamente a las herramientas ejecutadas desde Terminal o por SSH. Fuente: Apple, TN3179 “Understanding local network privacy”, sección macOS considerations, https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy, consultado el 13/10/2026]

Por eso lo tomo como una pista de diagnóstico, no como una solución garantizada: si después de una actualización de macOS o de un brew upgrade aparece No route to host solo con aws, es lo primero que voy a revisar.

Paso 8: respaldar la clave de cifrado

Con el cifrado activo, si se pierde el .env del NUC, los datos del RAID quedan ilegibles aunque los discos estén sanos. Era el pendiente más crítico antes de subir datos reales.

Ojo: el .env no tiene solo la clave de cifrado, también tiene el secret de la cuenta de administrador. Cualquier copia suya es un secreto de alto impacto.

El plan:

1. Una huella de la clave, para verificar las copias sin mostrar la clave.
2. Una copia en el gestor de contraseñas.
3. Una copia cifrada con GPG en otro equipo: el RAID del Mac mini, que es hardware distinto al NUC.

Y lo que no hacer:

• Guardarla en VaultS3 mismo: si VaultS3 falla, la clave queda atrapada dentro de lo que protege.
• Guardarla sin cifrar en iCloud, Drive o el correo.

La huella

En el NUC:

grep '^VAULTS3_ENCRYPTION_KEY=' ~/Proyectos/vaults3/.env | cut -d= -f2- | tr -d '\n' | shasum -a 256 | cut -c1-16

7a3e91c0d52b6f48

Son los primeros 16 caracteres del SHA-256 de la clave: sirven para comparar, pero no revelan la clave. Uso cut -d= -f2- (con el guion final) para tomar todo lo que va después del primer =: con una clave en Base64 que termine en =, un -f2 la truncaría. La mía es hexadecimal y no tiene ese problema, pero así el comando sirve para cualquier formato.

Copia en el gestor de contraseñas

Desde el Mac, copié el .env al portapapeles por SSH, sin mostrarlo en pantalla:

ssh [email protected] 'cat ~/Proyectos/vaults3/.env' | pbcopy

Lo pegué en una nota segura del gestor, junto con la huella y la fecha, y limpié el portapapeles:

pbcopy < /dev/null

Copia cifrada en otro equipo

Error: Permission denied en el volumen

$ mkdir -p /Volumes/Caja_Raid/backups/vaults3
mkdir: /Volumes/Caja_Raid/backups: Permission denied

$ ls -ld /Volumes/Caja_Raid
drwxrwxr-x@ 6 root  wheel  192  1 sept. 11:00 /Volumes/Caja_Raid

• Causa: el volumen APFS tiene la propiedad POSIX activada, y su raíz pertenecía a root:wheel. Mis carpetas dentro sí eran mías, pero no podía crear nada nuevo en la raíz.
• Solución: como es mi equipo y soy el único usuario, cambié el dueño de la raíz, sin -R, para no tocar las carpetas del sistema (.Spotlight-V100, .fseventsd):

sudo chown jmmv:staff /Volumes/Caja_Raid
mkdir -p /Volumes/Caja_Raid/backups/vaults3
chmod 700 /Volumes/Caja_Raid/backups /Volumes/Caja_Raid/backups/vaults3

Error: gpg y ssh peleando por la terminal

Mi primer intento fue encadenar todo en una línea:

$ ssh [email protected] 'cat ~/Proyectos/vaults3/.env' | gpg --symmetric --cipher-algo AES256 -o /Volumes/Caja_Raid/backups/vaults3/env-$(date +%F).gpg
[email protected]'s password: gpg: problema con el agente: Inappropriate ioctl for device
gpg: error al crear frase contraseña: Operación cancelada

• Causa: gpg necesita la terminal para pedir la frase de contraseña, pero ssh la estaba usando al mismo tiempo para pedir la contraseña del NUC. Además, faltaba la variable GPG_TTY, que le indica a gpg en qué terminal preguntar.
• Solución: primero traer el .env a una variable en memoria (sin escribirlo a disco), validar que llegó completo y luego cifrar. Si la lectura por SSH falla, no tiene sentido cifrar un contenido vacío o incompleto:

export GPG_TTY=$(tty)
ENVDATA=$(ssh [email protected] 'cat ~/Proyectos/vaults3/.env') || { echo "Falló la lectura por SSH"; unset ENVDATA; }
if grep -q '^VAULTS3_ENCRYPTION_KEY=.' <<<"$ENVDATA"; then
  printf '%s\n' "$ENVDATA" | gpg --symmetric --cipher-algo AES256 \
    -o /Volumes/Caja_Raid/backups/vaults3/env-$(date +%F).gpg
else
  echo "El contenido no trae VAULTS3_ENCRYPTION_KEY: no se cifra nada"
fi
unset ENVDATA

El contenido nunca se imprime: solo pasa de la variable a gpg.

Para que no vuelva a pasar, dejé GPG_TTY permanente:

echo 'export GPG_TTY=$(tty)' >> ~/.zshrc

La frase de contraseña del archivo .gpg también quedó en el gestor.

Verificación

Un respaldo que no se ha probado no es un respaldo. Comparé la huella de la clave dentro de la copia cifrada con la original.

Error: comandos en el equipo equivocado

Mi primera verificación dio esto en los dos equipos:

e3b0c44298fc1c14

• Causa: corrí el comando del Mac en el NUC y el del NUC en el Mac. Ninguno encontró su archivo, y e3b0c44298fc1c14 es la huella de un texto vacío (el SHA-256 de nada). Si alguna vez ves ese valor, la entrada estaba vacía.
• Solución: cada comando en su equipo.

En el NUC (original):

7a3e91c0d52b6f48

En el Mac mini (copia cifrada):

gpg -d /Volumes/Caja_Raid/backups/vaults3/env-*.gpg | grep '^VAULTS3_ENCRYPTION_KEY=' | cut -d= -f2- | tr -d '\n' | shasum -a 256 | cut -c1-16

gpg: AES256.CFB encrypted data
gpg: cifrado con 1 frase contraseña
7a3e91c0d52b6f48

Las huellas coinciden. Lo que esto demuestra, y lo que no:

• Verificado: la copia cifrada se puede descifrar y contiene exactamente la clave del NUC.
• No verificado: que con esa clave se pueda restaurar VaultS3 completo. Eso es otra prueba, que no hice.

Si no te pide la frase al descifrar, es porque gpg-agent la guarda en memoria unos minutos.

Un detalle a tener en cuenta: el log de VaultS3 menciona per-bucket encryption key management. Mi primera deducción fue que las claves de cada bucket se guardaban en vaults3.db, cifradas con la clave maestra. vaults3 diagnose lo descarta: el modo activo es el de clave estática.

enabled subsystems:
  - encryption: SSE-S3 (static key)
  - rate limiting

Según la documentación, el modo de claves por bucket hay que activarlo aparte. Aun así, cualquier respaldo de los datos debería incluir la carpeta metadata/, porque ahí vive el índice de los objetos (vaults3.db). [CORRECCIÓN: decía que, según una deducción sin confirmar, las claves de cada bucket se guardaban en vaults3.db; vaults3 diagnose muestra el modo SSE-S3 (static key), y la documentación indica que el modo de claves por bucket requiere per_bucket: true. Se conserva la recomendación de respaldar metadata/, porque el índice de objetos es un archivo BoltDB. Fuentes: salida de vaults3 diagnose del autor (13/10/2026); docs/CONFIGURATION.md y README de Kodiqa-Solutions/VaultS3, consultados el 11/10/2026]

Clientes gráficos

No todo tiene que ser por CLI:

• El dashboard de VaultS3 (http://192.168.1.40:9000/dashboard/), con navegador de archivos y arrastrar y soltar. Como el puerto está publicado solo en la IP de la LAN, ya no responde en localhost desde el propio NUC. Ojo: lo uso con la cuenta de administrador, así que ahí no aplican el aislamiento por llave ni la restricción por IP. Todas las pruebas de aislamiento de este artículo las hice por la API S3, con las llaves de cada equipo.
• Cyberduck (gratuito) o Mountain Duck, para montar un bucket como disco en Finder.
• Transmit, ForkLift o Commander One.

Dos detalles para configurarlos con este montaje:

1. El endpoint es HTTP, sin TLS. En Cyberduck hay que usar el perfil “S3 (HTTP)”.
2. Las llaves no pueden listar buckets. Muchos clientes intentan listar todo al conectarse y muestran un error. Hay que indicar la ruta del bucket en la conexión (por ejemplo /personal) o crear un marcador por bucket.

Para archivos grandes o carpetas completas, la CLI (aws s3 sync) o un cliente dedicado son más confiables que el navegador, porque reintentan y reanudan.

Monitoreo

El NUC ya reporta a mi Hub de Beszel, que conté en este artículo. El contenedor vaults3 aparece automáticamente en la tabla de contenedores, con su historial de CPU, memoria y red, sin configurar nada en VaultS3.

Límites del montaje

Para que nadie se lleve una idea más optimista de la cuenta:

• El RAID 1 no es un respaldo. Protege contra la falla de un disco, no contra borrados, ransomware ni la pérdida de la caja.
• La restricción por IP no reemplaza la revocación. Si sospecho que una llave se filtró, la borro; la regla de IP solo reduce desde dónde se puede usar.
• Respaldar la clave no es lo mismo que probar una restauración. Verifiqué que la clave se recupera intacta; no hice una restauración completa de VaultS3.
• El dashboard usa la cuenta de administrador, que no tiene restricción por IP. La mitigación es que el puerto solo escucha en la LAN.

Errores y soluciones

Resultado

Con esto, VaultS3 quedó listo para el uso diario:

• Un usuario y tres llaves, una por equipo, cada una con su alcance.
• El equipo corporativo limitado al bucket trabajo.
• Las llaves limitadas a IPs de origen de la LAN, con la restricción probada y registrada en la auditoría.
• La clave de cifrado respaldada en el gestor de contraseñas y cifrada en otro equipo, con la copia verificada por huella (no una restauración completa).
• La cuenta de administrador fuera de los portátiles.

Lo que más me dejó este proyecto es el hábito de probar el caso negativo: que el candado impida arrancar sin RAID, que la llave corporativa no vea personal, que la regla de IP realmente bloquee y que el respaldo de la clave realmente se pueda descifrar. Ver el Deny en la auditoría da mucha más tranquilidad que asumir que la configuración está bien.