Существует множество утилит для сканирования образов контейнеров, начиная от реализаций с открытым исходным кодом, таких как Trivy (https://oreil.ly/SxKQT), Clair (https://oreil.ly/avK-2) и Anchore (https://oreil.ly/7rFFt), и до коммерческих решений от таких компаний, как JFrog, Palo Alto и Aqua. Во многих реестрах образов контейнеров, например Docker Trusted Registry (https://docs.docker.com/ee/dtr), и в проекте Harbor (https://goharbor.io/) от CNCF, а также в реестрах от основных поставщиков облачных сервисов есть встроенные возможности сканирования.
Пространства имен пользователей позволяют непривилегированному пользователю фактически играть роль суперпользователя в контейнеризованном процессе. Благодаря этому обычные пользователи могут запускать контейнеры с помощью контейнеров, не требующих полномочий суперпользователя,
Каждая виртуальная машина влечет накладные расходы по выполнению всего ядра целиком. Благодаря совместному использованию ядра контейнеры гораздо рациональнее задействуют ресурсы и демонстрируют высокую производительность.
Хотя обычно используется название «контейнеры», правильнее было бы называть их «контейнеризованные процессы». Контейнер остается процессом Linux, работающим на хост-компьютере, просто видит лишь ограниченную часть этого хост-компьютера и имеет доступ только к части файловой системы, а возможно, и к ограниченному контрольными группами набору ресурсов.
Компьютер, на котором производится сборка, интересует нас по двум основным причинам. • Сможет ли злоумышленник, взломавший машину сборки и имеющий возможность выполнять на ней код, добраться до прочих частей системы? Как вы видели в подразделе «Опасности команды docker build» на с. 101, имеет смысл использовать утилиту сборки, не требующую привилегированного процесса-демона. • Может ли злоумышленник повлиять на результаты сборки так, что будут собраны, а потом и запущены образы с вредоносным кодом? Последствия любого несанкционированного доступа, который влияет на инструкции Dockerfile или инициирует сборку непредусмотренных образов, могут оказаться катастрофическими. Например, если злоумышленник может внести изменения в собираемый код, то может и включить лазейки в контейнеры, работающие в продакшене. А поскольку машины сборки генерируют код, который в дальнейшем будет выполняться в кластере, работающем в промышленной эксплуатации, надежная защита их от атак столь же важна, как и для самого кластера. Старайтесь уменьшить поверхность атаки, удаляя ненужные утилиты из машин сборки. Ограничивайте прямой доступ пользователей к этим машинам и защищайте их от несанкционированного доступа по сети, задействуя VPC и брандмауэры.
Программный интерфейс, с помощью которого код из пользовательского пространства выполняет подобные запросы к ядру, называется интерфейсом системных вызовов (system call).
