Is there a way to restrict untrusted container sch

Question

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.

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.

Answer 1

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."