Configuración, contraseñas y Vault

01

1. Qué debe ir en .env

• URL del servicio, selección de modo, zona horaria, nombres de bases de datos y otros parámetros no secretos.
• Referencia completa de la imagen con resumen si el archivo es un componente con control de versiones.
• Interruptores de funciones que la versión admite y valida explícitamente.
• Nunca incluyas tu contraseña real, clave privada, token de acceso, secreto de cliente o nombre de usuario del registro en un archivo con control de versiones de Git.

02

2. Diseño recomendado en el servidor

/etc/sifybox/
├── env/
│   ├── release.env       # image + digest, bez hesel
│   └── site.env          # URL, režimy a nesekretní parametry
└── secrets/              # root:root, adresář 0700, soubory 0400
    ├── db_password
    └── oidc_client_secret

Nota: El archivo .env no es un gestor de secretos. El inicio de sesión en el registro se realiza mediante un asistente de credenciales o un inicio de sesión gestionado de Docker con un token de despliegue; el secreto de Compose en sí mismo no autoriza las descargas de imágenes. Los valores confidenciales permanecen fuera de Git, con permisos mínimos y la rotación descrita.

03

3. Variante de secretos de Docker

Estándar de destino: los nombres de archivo y la compatibilidad con las variables _FILE deben confirmarse mediante el manifiesto de una versión específica.

1. DERS proporcionará una lista de los secretos previstos y un método confirmado para recuperarlos.
2. El administrador crea cada secreto fuera del proceso de pago y establece la propiedad y los permisos.
3. Compose solo adjuntará un secreto al servicio que lo necesite.
4. La aplicación no debe imprimir el valor al iniciarse ni en caso de error de validación.
5. La rotación se realiza de acuerdo con el manual de procedimientos del servicio y se verifica mediante un nuevo inicio de sesión o conexión.

04

4. Variante de HashiCorp Vault

Estándar objetivo: el método de autenticación, renovación de arrendamiento y recarga debe ser confirmado por el servicio y la versión específicos.

1. El servicio o agente de Vault se autentica con una identidad de máquina vinculada a un entorno específico; no utiliza un token personal compartido.
2. Esta política solo permitirá rutas y operaciones específicas necesarias para un servicio determinado.
3. El agente de Vault escribe el secreto en un archivo tmpfs o lo proporciona a la aplicación mediante un mecanismo compatible.
4. La restauración de datos a corto plazo activará una recarga compatible o un reinicio controlado.
5. La auditoría de la bóveda, la auditoría de la aplicación y los registros operativos se correlacionan sin necesidad de escribir el valor secreto en sí.

05

5. Orden de carga y validación

1. Cargar los valores predeterminados integrados en la versión solo para las opciones no secretas.
2. Cargar release.env y site.env.
3. Extraiga los secretos de los archivos o de Vault; el valor secreto nunca tiene un valor predeterminado universal seguro.
4. Si falta un valor obligatorio, finalice antes de comenzar con el nombre del parámetro, no con su contenido.
5. Imprime un resumen de configuración anonimizado: modo, URL de destino, versión y origen del secreto, pero no el secreto.
6. Realice pruebas de conectividad y solo entonces acepte los requisitos operativos.

06

6. Rotación sin reescritura manual

• Cada secreto tiene un propietario, una fuente, una fecha de caducidad y un método de recuperación.
• Los datos de Dynamic Vault tienen un período de arrendamiento y renovación automática.
• Las claves secretas del cliente OIDC se modifican superponiendo los valores antiguos y nuevos, si el proveedor de identidad (IdP) y la aplicación lo permiten.
• La rotación de emergencia tiene su propio procedimiento y es independiente de la persona que realizó la instalación originalmente.
• Tras la rotación, se verifica la función del servicio y la auditoría; el valor anterior solo se invalida tras la confirmación.