Is there a way to restrict untrusted container scheduler?

I have an application which I’d like to give the privilege to launch short-lived tasks and schedule these as docker containers. I was thinking of doing this simply via docker run.

As I want to make the attack surface as small as possible, I treat the application as untrusted. As such it can potentially run arbitrary docker run commands (if the codebase contained bug or the container was compromised, input was improperly escaped somewhere etc.) against a predefined docker API endpoint.

  • Where is my data located when I backup a docker container volume?
  • Connecting to a mysql running on a Docker container ubuntu 16.04
  • How to mount current directory as read-only but still allow changes inside the container?
  • Docker intermittently failing when building image
  • run command, specify N docker containers instances across swarm cluster
  • Permissions error when using cli in Jboss wildfly and docker
  • This is why I’d like to restrict that application (effectively a scheduler) in some ways:

    • prevent --privileged use
    • enforce --read-only flag
    • enforce memory & CPU limits

    I looked at couple of options:

    • selinux
      • the selinux policies would need to be set on the host level and then propagated inside the containers via --selinux-enabled flag on the daemon level. The scheduler can however override this anyway via run --privileged.
    • seccomp profiles
      • these are only applied at a time of launching the container (seccomp flags are available for docker run)
    • AppArmor
      • this can (again) be overriden on the scheduler level via --privileged
    • docker daemon --exec-opts flag
      • only a single option is actually available for this flag (native.cgroupdriver)

    It seems that Docker is designed to trust container schedulers by default.
    Does anyone know if this is a design decision?

    Is there any other possible solution available w/ current latest Docker version that I missed?


    I also looked at Kubernetes and its Limit Ranges & Resource Quotas which can be applied to K8S namespaces, which looked interesting, assuming there’s a way to enforce certain schedulers to only use certain namespaces. This would however increase the scope of this problem to operating K8S cluster.

  • In docker, difference with commit and dockerfile
  • Isolation in Vagrant vs. Docker
  • Bitnami and Docker
  • Use container environment variable in docker run without using bash -c
  • docker nginx stream balancer 404
  • Can't reach containers with new 1.10 DNS SD
  • One Solution collect form web for “Is there a way to restrict untrusted container scheduler?”

    running docker on a unix platform should be compatible with nice Or so I would think at first looking a little more closely it looks like you need somethign like -cpuset-cpus="0,1"

    From the second link , “The –cpu-quota looks to be similar to the –cpuset-cpus … allocate one or a few cores to a process, it’s just time managed instead of processor number managed.”

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.