Есть ли способ ограничить ненадежный планировщик контейнеров?

У меня есть приложение, которое я бы хотел предоставить, чтобы запускать краткосрочные задачи и планировать их как контейнеры докеров. Я думал об этом просто через docker run.

Как я хочу, чтобы поверхность атаки была как можно меньше, я рассматриваю приложение как ненадежное. Таким образом, он может потенциально запускать произвольные команды docker run (если кодовая база содержала ошибку или контейнер был взломан, вход был неправильно экранирован где-то и т.д.) Против предопределенной конечной точки API докеры.

Вот почему я хотел бы каким-то образом ограничить это приложение (фактически планировщик):

предотвратить --privileged использовать
применить флаг --read-only
обеспечить соблюдение ограничений памяти и процессора

Я посмотрел пару вариантов:

SELinux
- политики selinux должны быть установлены на уровне хоста, а затем распространены внутри контейнеров с помощью флага --selinux-enabled на уровне daemon. Однако планировщик может переопределить это значение через run --privileged.
профили seccomp
- они применяются только во время запуска контейнера (флаги seccomp доступны для docker run)
AppArmor
- это может (снова) быть переопределено на уровне планировщика через --privileged
флаг docker daemon --exec-opts
- для этого флага действительно доступен только один параметр (native.cgroupdriver)

Похоже, что Docker предназначен для доверия планировщиков контейнеров по умолчанию. Кто-нибудь знает, является ли это конструктивным решением?

Есть ли какое-либо другое возможное решение с текущей версией Docker, которую я пропустил?

Я также посмотрел на Kubernetes и его Limit Ranges и Квоты ресурсов, которые могут быть применены к пространствам имен K8S, который выглядел интересным, предполагая, что есть способ заставить определенные планировщики использовать только определенные пространства имен. Это, однако, увеличило бы масштаб этой проблемы для работы кластера K8S.

Ответ 1