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.

  • Docker (compose) send to daemon mode without restart
  • Is it possible to access the entry command bash on a running docker container?
  • Docker, nginx and several sites on one server
  • Docker compose with subdirectory and live reload
  • What should WSO2 APIM <localMemberHost> parameter contain in the config and what it is used by the APIM?
  • Is it possible to expose a usb device to a lxc/docker container?
  • 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.

  • Get debug informations from docker container which runs a tomcat server
  • Installing cron via apt-get fails in a docker ubuntu:12.04 container from permissions problems
  • Issues with putting dockerized Postgres OLTP database in read only
  • OpenSSL error on Tornado server
  • Docker and inconsistent IP addresses from host
  • Run SpringBoot-based docker image return error message:Invalid or corrupt jarfile /app.jar
  • 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.