Description
Writes to a volume mounted at a system path can change executables or configuration and affect container operation. If the volume connects to the host filesystem, the node may be affected too.
mount_path is a path inside the container. A path such as /bin alone does not establish that a host directory is mounted; review the corresponding volume source and actual file permissions.
Potential impact
- Writable system files or configuration can be tampered with, disrupting the application.
- Sharing host files can extend the impact to the node and other workloads.
Remediation
- Remove unnecessary system-path mounts and expose only the required data through minimal paths.
- Set
read_only = truewhere writes are unnecessary. Separately check protection of nested mounts and other access paths. - Review the volume source, file permissions, privileged mode and capabilities together.
Examples
These partial volume-mount examples omit their corresponding volume definitions. The actual sources are unspecified, and the excerpts cannot be deployed as shown. Use a supported image version for deployment.
Before
resource "kubernetes_pod" "app_pod" {
metadata {
name = "terraform-example"
}
spec {
container {
name = "app-container"
image = "nginx:1.7.9"
volume_mount {
name = "system-bin"
mount_path = "/bin"
}
}
}
}
The volume is mounted at /bin inside the container without requesting read-only access. Whether files can be changed or the host affected depends on the source and permissions.
After
resource "kubernetes_pod" "app_pod" {
metadata {
name = "terraform-example"
}
spec {
container {
name = "app-container"
image = "nginx:1.7.9"
volume_mount {
name = "config-volume"
mount_path = "/etc/config"
read_only = true
}
}
}
}
The configuration volume is requested as read-only. The /etc/config path does not itself guarantee safety; check the actual source and nested mounts too.