Как укрепить контейнер
Вопрос
Тебя просят провести ревью безопасности контейнеризованного сервиса. На что посмотришь?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Образ: минимальная база, multi-stage, нет лишних утилит, свежие патчи, скан на CVE в CI
Пользователь: не root, числовой UID, `runAsNonRoot` в Kubernetes
Права: `cap-drop ALL`, без `--privileged`, без `docker.sock`, `no-new-privileges`
ФС: read-only корень, запись только в tmpfs и тома
Секреты: не в образе и не в ENV в git, а через секреты оркестратора или хранилище
Ресурсы и сеть: лимиты памяти, CPU, PID; не публиковать лишние порты
Что могут спросить следом
- Как запустить сборку образов в CI без docker.sock?
- Что такое distroless и как его отлаживать?
- Чем Pod Security Admission помогает в Kubernetes?
Разбор
Иду по слоям. Образ: какая база, есть ли в финальном образе компиляторы, shell, curl, которые не нужны; давно ли он пересобирался; есть ли в CI сканер вроде Trivy, который роняет сборку на критичных CVE. История образа: нет ли секретов в ENV, ARG или слоях. Запуск: от какого пользователя, лучше числовой UID и проверка runAsNonRoot. Права ядра: все capabilities сброшены и добавлены только нужные, нет --privileged, нет смонтированного docker.sock и системных каталогов хоста, включён no-new-privileges. Файловая система только для чтения, запись в tmpfs. Секреты приходят файлами из хранилища или секретов оркестратора. Ресурсы ограничены, включая число процессов. Сеть: опубликованы только нужные порты, внутренние сервисы не торчат наружу. Если это Kubernetes, ещё смотрю securityContext, Pod Security Admission и NetworkPolicy.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.