Securing Docker Socket

As in Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL, CoreOS by default does not have docker group and tries to prevent accesses to the docker socket by limiting accesses to root to be secure.

A Kuberneses pod which is a Docker container process will not run as root by default, and also SELinux labels will prevent the pods/containers from accessing the docker socket. Check with the pod process with ps -Z and the docker socket with ls -Z to verify the labels.

Allowing the access to Docker socket from a container is a security risk, but if it is mandatory to do so for some reason, one way is to run the pod as privileged using security context, and make the pod process run as root (with risks).

    securityContext:
      privileged: true

Not sure with tectonic but OpenShift by default prevents using hostPath mount and tectonic may have similar. Another stuff look into is the service account used for the pod and the role/bindings to the account.

For run Docker in a Docker, you have 2 options - DooD (Docker out of Docker) and DinD (Docker in Docker). I think you need a first because you need access to events on a host machine.

Here is a good article about both schemes.

Example of pod's configuration:

apiVersion: v1 
kind: Pod 
metadata: 
  name: idn-docker 
spec: 
  containers: 
  - name: idn-docker
    image: sample/id-docker:latest
    volumeMounts: 
      - mountPath: /var/run 
        name: docker-sock 
volumes: 
  - name: docker-sock 
    hostPath: 
        path: /var/run 

You can use a containers section from an example in your deployment because of its structure in template section is the same Pod template as a separate pod configuration.

But, please keep in mind, that solution will have some limitations:

Pod Networking - Cannot access the container using Pod IP.

Pod Lifecycle - On Pod termination, this container will keep running especially if the container was started with -d flag.

Pod Cleanup - Graph storage will not be clean up after pod terminates.

Scheduling and Resource Utilization - Cpu and Memory requested by Pod, will only be for the Pod and not the container spawned from the Pod. Also, limits on CPU and memory settings for the Pod will not be inherited by the spawned container.