Безопасный Docker на Unmanaged VPS начинается не с `docker run`, а с подготовки host-системы. Контейнерная изоляция полезна, но она не компенсирует устаревший Linux, слабую firewall-политику или избыточные privileges внутри контейнеров.
Preflight - сначала подготовьте host
- обновляйте Linux и Docker Engine;
- используйте SSH keys и понятные firewall rules;
- открывайте наружу только необходимые ports;
- включайте persistent volumes в backup plan;
- настройте log rotation и disk monitoring.
обзор безопасности хостинга даёт defense-in-depth контекст, а гайд по инструментам управления сервером полезен для host-level контроля.
Относитесь к image как к dependency
Используйте доверенный registry или publisher. Фиксируйте version или digest там, где важна воспроизводимость. Не стройте production change-control только вокруг плавающего тега `latest`.
Какие privileges не стоит давать без необходимости?
- `--privileged`;
- широкие mounts host filesystem;
- Docker socket внутри обычного application container;
- секреты, встроенные в image;
- host networking только ради удобства.
Compose не заменяет operations policy
Docker Compose описывает services, networks и volumes. Monitoring, backups, update cadence, log retention и rollback всё равно требуют отдельных процессов.
Карта public exposure
| Service | Public? | Типичная схема |
|---|---|---|
| Reverse proxy | да | 80/443 |
| Application container | обычно нет | internal Docker network |
| Database | обычно нет | private/internal network |
SERVER1 Unmanaged VPS подходит командам, которым нужен полный контроль над Docker host. Для общих VM-вариантов смотрите SERVER1 VPS. Если рассматриваете managed-сервис, заранее уточните, входит ли Docker workload в support scope.
Контейнеризация упрощает упаковку и deployment, но не управляет безопасностью и recovery host-системы вместо вас.
Threat model: кто может управлять Docker daemon?
Docker daemon - компонент с очень высокими привилегиями. Пользователь, который может им управлять, способен создавать containers, mount host paths и выполнять другие мощные операции. Поэтому добавление пользователя в группу `docker` - это не просто удобство, а security decision.
Когда стоит рассмотреть Rootless Docker?
Rootless mode запускает daemon и containers внутри non-root user namespace и уменьшает host-level privilege. Он подходит не всем workload автоматически: заранее проверьте networking, low ports, storage drivers и совместимость tooling. Для developer/staging среды это может быть особенно полезно.
Secrets: environment variable не всегда лучший финальный вариант
Не помещайте secrets в image и не храните их в repository. Используйте подходящий runtime secret mechanism или внешний файл с минимальными permissions. Учтите, что environment variables могут случайно появляться в debugging или operational tooling.
Container image - не backup
| Что должно восстанавливаться | Источник восстановления |
|---|---|
| Application image | registry/build pipeline |
| Persistent database data | проверенный backup |
| User uploads | volume/object-storage backup |
| Compose/config | version control / secure config store |
| Secrets | отдельный secret-management process |
Update runbook: «pull и restart» слишком мало
- прочитайте changelog и security notes image;
- сделайте backup невоспроизводимого state;
- запустите новый image в staging;
- проверьте health checks и migrations;
- после production deploy следите за logs, restart count и latency;
- оставьте предыдущий digest для быстрого rollback.
