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.

  • Getting Docker linked containers localhost pointing to host localhost
  • permission denied, mkdir in container on openshift
  • Relationship Between a Deis Cluster and Scale command?
  • Need example for sharing data between docker container and docker host
  • What is the relationship between the docker host OS and the container base image OS?
  • Docker service does not start
  • 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 Swarm - Tasks Running On Manager Unreachable
  • How to access web page served by nginx web server running in docker container
  • Running JUnit Tests in parallel with Docker
  • Running Supervisord on Ubuntu in Docker
  • How can I wait for a docker container to be up and running?
  • Bind container port to host inside Dockerfile
  • 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.