Operación y seguridad

Tenés Portainer funcionando y gestionando entornos. El último tramo de “0 a hero” es operarlo con seriedad: respaldarlo, mantenerlo actualizado, vigilarlo y endurecerlo.

Backups

Toda la configuración de Portainer (usuarios, entornos, registries, stacks, settings) vive en su base de datos dentro del volumen portainer_data. Hay dos formas de respaldarla:

Backup desde la UI

Settings → enviar a la sección de backup: descargás un archivo de backup, opcionalmente cifrado con una contraseña. También podés programar backups automáticos a un bucket S3 compatible. Este es el método recomendado porque produce un backup consistente de la base.

Backup del volumen

Alternativa de bajo nivel: parás el contenedor y respaldás el volumen.

docker stop portainer
docker run --rm \
  -v portainer_data:/data \
  -v "$(pwd)":/backup \
  alpine tar czf /backup/portainer_backup.tar.gz -C /data .
docker start portainer

Restaurar

En el primer arranque de una instancia nueva, la pantalla inicial ofrece Restore from backup: subís el archivo (y su contraseña si está cifrado) y Portainer recupera todo el estado.

Regla de oro: probá la restauración, no solo el backup. Un backup que nunca restauraste es una suposición, no un respaldo.

Actualización y auto-update de parches

Actualizar Portainer es recrear el contenedor con la imagen nueva conservando el volumen (lo vimos en el capítulo 2). Además, las versiones recientes incorporan automatic patch updates: una opción (desactivada por defecto) para que Portainer aplique releases de parche automáticamente, manteniéndose seguro sin intervención. Activala si querés parches al día; dejala apagada si preferís controlar cada upgrade.

Antes de un upgrade mayor, hacé backup. Y nunca actualices Portainer con Watchtower.

Alerting

Desde la 2.39, Alerting es función general (GA). Configurás alertas según condiciones como:

• Un entorno que se cae (offline).
• Un backup fallido.
• Uso de recursos alto.

Las alertas te avisan de problemas de la flota sin tener que mirar el dashboard constantemente.

Fleet Governance Policies

Una de las incorporaciones recientes más potentes: definir estándares de seguridad, acceso y configuración una sola vez y aplicarlos automáticamente a toda la flota. En vez de revisar host por host, declarás la política (qué está permitido, qué configuración es obligatoria) y Portainer la hace cumplir en todos los entornos. Es el salto de “administrar” a “gobernar” a escala. (La disponibilidad y profundidad de estas políticas dependen de la edición y versión.)

Hardening de la instancia

Portainer es una pieza muy sensible: quien lo controla, controla tus hosts. Endurecelo:

flowchart TD
    A["TLS real (proxy + Let's Encrypt)"] --> S["Portainer seguro"]
    B["No exponer 9443 a internet directo"] --> S
    C["Admin fuerte + usuarios acotados"] --> S
    D["Backups cifrados y probados"] --> S
    E["Actualizado (LTS + parches)"] --> S
    F["Acceso al volumen restringido"] --> S

• TLS de verdad: poné Portainer detrás de un reverse proxy con certificado válido; no dejes el autofirmado en producción.
• No lo expongas crudo a internet: idealmente accesible solo por VPN o red interna. Si necesita exposición, que sea a través del proxy y, si podés, con una capa de auth adicional.
• Principio de menor privilegio: usá RBAC (capítulo 12); el admin solo para administrar.
• Protegé docker.sock y el volumen: tienen las llaves del reino. Restringí quién accede al host.
• Mantené LTS + parches: las vulnerabilidades se corrigen en las versiones soportadas.
• Auditá (BE): activity logs para saber quién hizo qué.

Checklist final — de cero a hero

• Portainer corre como contenedor con --restart=always y volumen persistente.
• Acceso por HTTPS real detrás de un reverse proxy.
• Admin con contraseña fuerte; usuarios/equipos con permisos acotados.
• Entornos remotos conectados por agent o Edge según corresponda.
• Apps desplegadas como stacks versionados, idealmente desde Git.
• Registries privados conectados con tokens de mínimo scope.
• Despliegue automatizado con webhooks desde el CI.
• Backups cifrados, programados y restauración probada.
• Versión LTS al día; decidiste sobre auto-update de parches.
• Alerting configurado para offline, backups fallidos y recursos.
• Instancia endurecida: no expuesta cruda, volumen y socket protegidos.

Con esto ya no solo usás Portainer: lo operás en producción con respaldo, seguridad y automatización. De cero a hero. 🐳

---

Anterior → Capítulo 13: GitOps y webhooks · Volver al → Índice