Description
Mounting /var/run/docker.sock and allowing a container to connect gives it direct access to the Docker daemon API. With a typical rootful host daemon, this can provide control over other containers or the host filesystem.
Most applications do not need this access. Making the socket mount read-only does not turn the daemon API into a read-only interface.
Potential impact
A compromised container may create or change other workloads or access host data with the daemon’s authority. The actual scope depends on daemon privileges and socket access controls, but application isolation can be substantially weakened.
Remediation
- Remove unnecessary Docker socket volumes and mounts.
- Use a dedicated builder or separate isolated environment for build and operational automation, allowing only necessary API access.
- Verify required functions after removal, and also minimize host paths and file permissions for ordinary data volumes.
Examples
These examples compare mounts on a host with the Docker socket and data directory present. Prepare image access and application settings for your environment.
Before
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /var/run/docker.sock
type: Socket
This mounts an actual Unix socket with type Socket. If file permissions allow the container to connect, it can use the Docker API.
After
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: k8s.gcr.io/test-webserver
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /data
type: Directory
This mounts a data directory instead of the Docker socket. Host access to /data remains; review its scope, file permissions and whether it can be read-only.