mirror of
https://github.com/MacRimi/ProxMenux.git
synced 2026-08-02 22:06:31 +00:00
update documentation
This commit is contained in:
@@ -51,27 +51,29 @@
|
||||
"encryption": {
|
||||
"heading": "Cifrado del lado del cliente",
|
||||
"glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. El <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
|
||||
"intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, también es opcional subir a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación). La clave siempre vive en una única ruta canónica del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza en silencio en todas las copias cifradas siguientes.",
|
||||
"intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, subir también a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación) es una decisión sí/no explícita que toma el usuario durante la configuración inicial (y que puede revisar más tarde desde el Monitor). La clave siempre vive en una única ruta canónica del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza en silencio en todas las copias cifradas siguientes.",
|
||||
"keyfileTitle": "Configuración inicial de la clave",
|
||||
"keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: <em>No</em> continúa sin cifrado; <em>Sí</em> pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. <em>Generar una clave nueva</em> ejecuta <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el operador ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con <code>chmod 600</code>.",
|
||||
"keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: <em>No</em> continúa sin cifrado; <em>Sí</em> pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. <em>Generar una clave nueva</em> ejecuta <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el usuario ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con <code>chmod 600</code>.",
|
||||
"modesTitle": "Clave por host o compartida",
|
||||
"modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.",
|
||||
"modesPerHostTitle": "Clave por host (por defecto)",
|
||||
"modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
|
||||
"modesSharedTitle": "Clave compartida (importar la misma en cada host)",
|
||||
"modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
|
||||
"recoveryTitle": "¿Subir la clave a PBS? — la pregunta yes/no",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta — <em>Upload key to PBS?</em> — con dos respuestas. La opción por defecto es <em>No, keep local only</em>: la clave se queda únicamente en la ruta canónica local y el operador gestiona su propia copia offsite (el botón <em>Download keyfile</em> del Monitor la genera bajo demanda). Al elegir <em>Yes, upload</em>, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir <code>pbs-key.recovery.enc</code>. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host.",
|
||||
"recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
|
||||
"recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — <em>Upload key to PBS?</em> — con dos respuestas. <strong>No se sube nada a PBS hasta que el usuario responde Sí.</strong> La opción por defecto es <em>No, keep local only</em>: la clave se queda únicamente en la ruta canónica local, ProxMenux no toca PBS con ningún artefacto de recuperación, y el usuario gestiona su propia copia offsite (el botón <em>Download keyfile</em> en la fila de destino PBS del Monitor la genera bajo demanda). Al elegir <em>Yes, upload</em>, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir <code>pbs-key.recovery.enc</code>. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host. La elección se puede cambiar más adelante desde el Monitor en cualquier momento — el interruptor de escrow inline en la fila del destino PBS conmuta Sí/No y se aplica en el acto (Start uploading, Stop uploading o Update passphrase, según el estado actual).",
|
||||
"blobUploadTitle": "Grupo emparejado en PBS",
|
||||
"blobUploadBody1": "Cuando el modo elegido es <em>Yes, upload</em>, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore, uno con las copias del host y otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: el cifrado ocurre en el propio host con AES-256-CBC y PBKDF2 antes de que se envíe un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado.",
|
||||
"envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
|
||||
"envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el operador dispone de ambas.",
|
||||
"envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el usuario dispone de ambas.",
|
||||
"blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
|
||||
"blobUploadConstraintBody": "Una misma subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave, o no cifra ninguno — no hay opción intermedia. La copia del host tiene que ir cifrada con la clave del host; el sobre de recuperación no puede ir en esa misma subida, porque quedaría cifrado con la clave que precisamente contiene: en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso se hacen dos subidas independientes y aparecen como dos grupos separados: la copia del host va cifrada por PBS con la clave, y el sobre de recuperación va cifrado por ProxMenux con la passphrase antes de subirse. Son dos capas de cifrado distintas que protegen dos activos distintos.",
|
||||
"blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.",
|
||||
"blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
|
||||
"recoverTitle": "Recuperación en un equipo recién instalado",
|
||||
"recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS seleccionado tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo <code>-keyrecovery</code> disponible en PBS, se descarga el snapshot más reciente y se pide al operador la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el operador las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada."
|
||||
"recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS seleccionado tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/<NAME>.enc</code>, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo <code>-keyrecovery</code> disponible en PBS, se descarga el snapshot más reciente y se pide al usuario la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el usuario las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada. Cuando la clave sí está instalada pero no coincide con la que cifró la copia, PBS devuelve un error <code>wrong key — manifest's key XX does not match provided key YY</code>; las mismas tres acciones muestran un panel ámbar estructurado con el fingerprint del manifest destacado en primer plano, para que el usuario pueda identificar qué clave importar para abrir esa copia concreta.",
|
||||
"monitorManagementTitle": "Gestionar la clave desde el Monitor",
|
||||
"monitorManagementBody": "El Monitor expone los controles de la clave de forma inline en cada fila de destino PBS de la página de configuración de copias. La fila muestra tres acciones: <em>Descargar</em> exporta la clave actual al navegador del usuario, <em>Subir</em> reemplaza la clave instalada por una que aporta el usuario (el fichero anterior solo se sobrescribe cuando el nuevo llega correctamente a la ruta canónica), y <em>Eliminar</em> retira la clave del host. El interruptor del sobre de recuperación es un único control inline junto a esas acciones: un radio Sí/No para <em>Upload key to PBS?</em>, un campo de passphrase cuando se selecciona Sí, y un botón Apply contextual que dice <em>Start uploading</em>, <em>Stop uploading</em> o <em>Update passphrase</em> según el estado actual. Todas las acciones pasan por los mismos endpoints Flask que usa el TUI del shell, así que el efecto en disco y en PBS es idéntico independientemente de qué superficie elija el usuario."
|
||||
},
|
||||
"restoreAccess": {
|
||||
"heading": "Recuperación del lado de la restauración",
|
||||
|
||||
Reference in New Issue
Block a user