Understand the options to secure the docker.sock.


As in those articles, giving containers the access to docker.sock is a risk.

However there could be cases where we need to deploy a pod such which needs to talk to docker daemon via the socket for monitoring or controlling. For example datadog which mounts the socket via hostPath mount.


OpenShift requires explicit grant of SCC e.g. hostaccess to the service account which runs the pod for the pod to use hostPath, but it is OpenShift proprietary.

I suppose SELinux can be used so that any pods who access the docker socker are required to have a certain label.


I would like to know if my understanding of SELinux label is valid, and what other options would be available.


1 Answer 1


It sounds like you're asking about Kubernetes. PodSecurityPolicy is the Kubernetes upstreamed version of OpenShift's Security Context Constraints (SCC), and can be used to limit access to HostPath volumes. However, there is a known issue with the AllowedPaths implementation, so it is safest to disable HostPath volumes completely for Pods that don't require it. Assuming the docker socket requires root privileges to access, you can also restrict which containers are running as root (don't forget to set no_new_privs, disable AllowPrivilegeEscalation in Kubernetes).

  • kinda out of topic, though for the record: PSP and SCC are two different concepts, though they ensure somewhat the same function. The PodSecurityPolicy type does exist in OpenShift -- and you shouldn't use it. Most outstanding difference being that you'ld grant access to a PSP via a ClusterRoleBinding or RoleBinding, whereas the SCC object definition already includes the list of users/groups/serviceaccounts that may use it.
    – SYN
    Commented Oct 10, 2019 at 11:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .