Description
A direct mount of a sensitive host directory can let container processes read or modify host files, depending on file permissions and mount settings. Paths containing backups, system configuration or production data need particular care.
Bind mounts are useful for sharing data, but an unnecessarily broad path can turn a container compromise into disclosure or damage to host data.
Potential impact
- A container may access confidential host files beyond its needs.
- Writable mounts can permit modification or deletion of important data and configuration.
Remediation
- Remove unnecessary host mounts and narrow required mounts to specific files or dedicated directories.
- For read-only needs, use
:roorread_only: trueon the long-syntax mount. Read-only access does not prevent disclosure. - When moving to a Docker named volume, prepare data migration and permissions, then verify backup, recovery and application behavior.
Examples
Replace backup-service with the actual backup image. The examples use different storage locations.
Before
version: "3.9"
services:
backup:
image: backup-service
volumes:
- /var/lib/backup/data:/data
The host backup path is mounted directly at /data. This is a read-write mount by default, so process file permissions also matter.
After
version: "3.9"
services:
backup:
image: backup-service
volumes:
- backup-data:/data
volumes:
backup-data:
A separate named volume is used. Existing host data is not migrated automatically, and the volume’s contents and access permissions still need protection.