Evita la filtración de secretos manteniendo los valores fuera de las definiciones de Compose que se puedan compartir y tratando cada copia de seguridad o exportación de diagnóstico como información sensible hasta que supere un análisis de contenido.
Home Assistant necesita credenciales durante la ejecución, por lo que ningún diseño local las hace invisibles para un administrador con acceso total al host. El objetivo práctico es más limitado: evitar commits accidentales, cargas de soporte, copias de seguridad demasiado amplias y accesos innecesarios a los contenedores. Haz un inventario de dónde entra cada valor en la pila, reemplaza los literales por una fuente de secretos controlada y prueba los artefactos exportados sin mostrar los secretos.
Mapea todos los lugares por los que puede escapar un secreto
Enumera los tokens de API, las contraseñas de bases de datos, las credenciales de MQTT, las URL de webhooks, las claves de cifrado, los certificados privados y las claves de recuperación. Para cada uno, registra su consumidor en tiempo de ejecución, ruta de almacenamiento, propietario del archivo, inclusión en copias de seguridad, estado en el repositorio, exposición en registros y método de rotación. No copies los valores en el inventario.
Los archivos de secretos organizan los valores, pero siguen siendo texto sin cifrar para cualquier cuenta que pueda leer el host. Este límite de acceso al texto sin cifrar implica que la separación reduce principalmente la divulgación accidental, en lugar de impedir el acceso de un atacante con privilegios completos.
Se considera un fallo cualquier valor literal en YAML de Compose, un archivo de entorno bajo control de versiones, un directorio de configuración con permisos de lectura demasiado amplios o una exportación cuyo contenido se desconozca. Suspende el uso compartido y los envíos al repositorio hasta que cada vía de exposición tenga un responsable y una corrección.
Separa los secretos de ejecución de las definiciones de implementación
Reemplaza los literales de Compose por secretos basados en archivos con permisos estrictamente necesarios u otra fuente de secretos compatible con la implementación. Proporciona a cada servicio únicamente los valores que consume, móntalos como de solo lectura cuando sea posible y limita los permisos del host a la identidad de ejecución y a los administradores.
Los valores de entorno pueden aparecer mediante la inspección, el contexto del proceso o los registros, mientras que el montaje de secretos basado en archivos puede limitar qué contenedores reciben una credencial. Los archivos de secretos locales siguen requiriendo un control de permisos.
Valida primero con marcadores de posición, inspecciona la configuración de Compose renderizada para detectar literales accidentales, inicia después un servicio y confirma que solo puede leer el secreto que tiene asignado. Revierte el cambio si provoca que una aplicación repita valores o exige permisos demasiado amplios en el directorio.
Controla el contenido de las copias de seguridad y los paquetes de soporte
Clasifica las copias de seguridad como si contuvieran credenciales, a menos que se haya demostrado lo contrario. Cifra las copias que salgan del límite de almacenamiento de confianza, guarda las claves de recuperación por separado, limita la retención y el acceso, y nunca adjuntes un archivo completo de configuración cuando un fragmento de registro redactado pueda responder a la pregunta de soporte.
Utiliza el flujo de protección de la configuración para conservar la capacidad de recuperación y separar el almacenamiento seguro del material de implementación que se puede compartir.
Antes de publicar, analiza los nombres de archivo y el texto extraído en busca de nombres de claves conocidos, prefijos de tokens, URL privadas, direcciones de correo electrónico, certificados y los hashes exactos de marcadores de prueba controlados. Un análisis limpio es un requisito para publicar, no una prueba de que no pueda existir un formato de secreto desconocido.
Rota las credenciales expuestas y demuestra la ruta de prevención
Si un valor utilizable entró en un repositorio, ticket, chat, enlace público o copia de seguridad no confiable, revócalo o rótalo primero; eliminar la copia visible no invalida las copias ni el historial. Registra el servicio afectado y la hora de rotación sin conservar el valor antiguo.
Crea un secreto canario inocuo, impleméntalo mediante la nueva ruta, genera el renderizado normal de Compose, la copia de seguridad y el paquete de diagnóstico, y luego busca ese secreto en los artefactos. El entorno de ejecución debe recibir el secreto canario, mientras que los artefactos que se pueden compartir no deben exponerlo fuera del límite de la copia de seguridad protegida de forma intencionada.
Detente cuando no haya secretos reales en las definiciones de implementación ni en los repositorios, las copias de seguridad protegidas tengan una ruta de recuperación independiente, los análisis de artefactos sean satisfactorios y las credenciales expuestas se hayan rotado. Escala el caso cuando una integración de terceros registre valores secretos o no pueda consumir una fuente de secretos limitada sin obtener un acceso más amplio al host.
Soporte y Consejos
Más para leer

Cómo optimizar las conexiones de la base de datos de Immich para contenedores simultáneos
No aumentes primero max_connections. Mide las sesiones de Immich, suma la demanda total de todos los contenedores, conserva margen para la administración y ajusta...

Cómo evitar trabajos o importaciones duplicados en Immich
Separa los trabajos repetidos de los recursos duplicados. Usa una única ruta de ingesta canónica, controla los reintentos y los cambios de ruta, y...

Cómo reparar Immich después de que su volumen de base de datos se llene
Nunca elimines el WAL de PostgreSQL para liberar espacio. Detén las escrituras de Immich, conserva el estado de la base de datos, añade capacidad...

