有没有办法限制不受信任的容器调度程序？

我有一个想要授予特权的应用程序，可以启动短期任务并将其作为Docker容器进行调度。我当时只是想通过 docker run 来做到这一点。

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.

我想使攻击面小到可能的话，我认为该应用程序不受信任。这样，它可以针对预定义的Docker API端点运行任意 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:

• 防止-特权使用


• 强制-只读标志


• 强制执行内存操作； CPU限制

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

我查看了几个选项：

• selinux
  
  
  
  
  • selinux策略需要在主机级别设置，然后在内部传播通过守护程序级别上的-启用了selinux的标志来打开容器。但是，调度程序仍然可以通过 run --privileged 来覆盖此设置。
  
  
  • 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标志可用于 docker run ）
    
    
    • these are only applied at a time of launching the container (seccomp flags are available for docker run)
    
    
    • 可以（再次）通过-privileged
    
    
    • this can (again) be overriden on the scheduler level via --privileged
    
    
    • 此标志实际上只有一个选项（ native.cgroupdriver ）
    
    
    • only a single option is actually available for this flag (native.cgroupdriver)

    默认情况下，Docker被设计为信任容器调度程序。
    有人知道这是否是一项设计决定吗？

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

    在我错过了最新的Docker版本的情况下，还有其他可用的解决方案吗？

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

    我还查看了Kubernetes及其限制范围& 资源配额，可以应用于K8S命名空间，看起来很有趣，假设有一种方法可以强制某些调度程序仅使用某些命名空间。

    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.