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.

  • Logstash crashes as soon as it starts
  • What does “build artifact” mean in the context of a dockerized development environment?
  • Apache in Docker won't deliver sites
  • Error trying to install Ansible in Jenkins image
  • using a maven docker plugin to commit and save an image on maven release
  • Docker build time arguments
  • 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.

  • docker-compose volumes_from equivalent with version 3
  • Dockerizing an existing Project
  • Cannot delete file from docker instance
  • How do I run Docker on Google Compute Engine?
  • Configure Dancer from environment variables?
  • Can't run rake db:create in Dockerfile with docker-compose
  • 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.