Description
Mounting the Docker daemon socket into a container and allowing its process to communicate with it provides access to host container-management functions. Depending on daemon permissions, this can allow host file access or privileged container creation, so ordinary applications should not receive this access.
The actual impact depends on the socket’s presence, process permissions and daemon configuration. Not every Kubernetes container runtime uses a Docker socket.
Potential impact
- A compromised application can use the Docker API to access other containers or host resources.
- Powerful daemon permissions can weaken container isolation and lead to node compromise.
Remediation
- Remove unnecessary Docker socket host_path volumes and volume_mount entries. Do not assume that a read-only mount prevents Docker API operations that change state.
- If build or administration tasks require daemon access, isolate them from ordinary services and restrict permitted operations and identities. Enforce restrictions on host mounts and privileged execution through policy.
Examples
The before example connects a volume and mount on a node with an actual Docker socket. The image does not require socket access. Use a maintained image for deployment.
Before
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
volume {
name = "docker-socket"
host_path {
path = "/var/run/docker.sock"
type = "Socket"
}
}
container {
image = "nginx:1.7.9"
name = "example"
volume_mount {
name = "docker-socket"
mount_path = "/var/run/docker.sock"
}
}
}
}
After
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
Explanation:
- Before: The host Docker socket is mounted in the container. Actual process access permissions also matter.
- After: The unnecessary socket volume and mount are removed.