💻 Wasm vs Docker containers vs Kubernetes vs serverless: битва за первенство

Держите годную статью
О чём она:
⏩WebAssembly (Wasm) — новая технология, которая может заменить контейнеры в некоторых сценариях использования.

⏩Wasm имеет преимущества в размере, скорости, безопасности и переносимости.

⏩Контейнеры имеют экосистему, такую как Kubernetes, которая предоставляет множество инструментов и сервисов.

• Wasm может стать жизнеспособной альтернативой контейнерам, если создаст свою экосистему или станет частью экосистемы Docker и Kubernetes.

⏩Wasm может быть использован в serverless-сервисах и на edge-устройствах, где существуют проблемы с размером, скоростью, безопасностью и экосистемой.

⏩Выбор использования Wasm зависит от конкретных потребностей и сценариев использования.

📎 А вот сама статья

@DevOPSitsec

🖥 Как устроены конвейеры CI/CD 💻

Схема взаимодействия контейнерных технологий в рамках работы с привычными инструментами может быть представлена так:

1️⃣Утилита podman с помощью Libpod API обращается к библиотеке libpod, которая вызывает низкоуровневый container runtime (по умолчанию утилиту runc)
containers/podman
Podman Commands

2️⃣Утилита docker с помощью Docker API вызывает сервис dockerd
docker/cli
Docker CLI reference
Docker architecture
Docker API

3️⃣Сервис dockerd вызывает сервис containerd
Dockerd reference

4️⃣Сервис containerd вызывает низкоуровневый container runtime (по умолчанию утилиту runc)
containerd/containerd
Containerd Scope and principles

5️⃣Сервис kubelet с помощью протокола CRI вызывает сервис container runtime (например, containerd или crio)
Container Runtime Interface
Container Runtimes
CRI: the Container Runtime Interface

6️⃣Сервис containerd вызывает низкоуровневый container runtime (по умолчанию runc)
Containerd CRI

7️⃣Сервис cri-o вызывает низкоуровневый container runtime (по умолчанию runc)
cri-o/cri-o

8️⃣Утилита OCI container runtime (по умолчанию runc):

🔘runc с помощью библиотеки libcontainer создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups)
opencontainers/runc
runc man
opencontainers/runc/libcontainer

🔘crun создает контейнер по runtime-spec, взаимодействуя с подсистемами ядра Linux – пространствами имен (namespaces) и контрольными группами (cgroups)
containers/crun

@DevOPSitsec

🖥 Уязвимость в runc, позволяющая выбраться из контейнеров Docker и Kubernetes

⏩В инструментарии для запуска изолированных контейнеров runc, применяемом в Docker и Kubernetes, найдена уязвимость CVE-2024-21626, позволяющая получить доступ к файловой системе хост-окружения из изолированного контейнера. В ходе атаки злоумышленник может перезаписать некоторые исполняемые файлы в хост-окружения и таким образом добиться выполнения своего кода вне контейнера.

⏩Уязвимость устранена в выпуске runc 1.1.12. В runtime LXC, crun и youki, альтернативных runc, проблема не проявляется.

⏩В случае использования инструментариев Docker или Kubernetes атака может быть совершена через подготовку специально оформленного образа контейнера, после установки и запуска которого из контейнера можно обратиться к внешней ФС. При использовании Docker имеется возможность эксплуатации через специально оформленный Dockerfile. Уязвимость также может быть эксплуатирована в случае запуска в контейнере процессов командой runc exec через привязку рабочего каталога к пространству имён хостового окружения

⏩Уязвимость вызвана утечкой внутренних файловых дескрипторов. Перед запуском кода внутри контейнера в runc выполняется закрытие файловых дескрипторов при помощи флага O_CLOEXEC. Однако, после последующего выполнения функции setcwd() остаётся открытым файловый дескриптор, указывающий на рабочий каталог и продолжающий оставаться доступным после запуска контейнера. Предложено несколько базовых сценария атаки на хост-окружение, используя оставшийся файловый дескриптор

⏩Например, атакующий может указать в образе контейнера параметр process.cwd, указывающий на "/proc/self/fd/7/", что приведёт к привязке к процессу pid1 в контейнере рабочего каталога, находящегося в пространстве монтирования хост-окружения. Таким образом, в образе контейнера можно настроить запуск "/proc/self/fd/7/../../../bin/bash" и через выполнение shell-скрипта перезаписать содержимое "/proc/self/exe", которое ссылается на хостовую копию /bin/bash.

📎 Читать подробнее

@DevOPSitsec

🖥 5 советов, как ускорить сборку образа Docker

⏩Совет 1. Можно ли избежать создания образов?

Использование Docker не обязательно должно быть принципом «все или ничего». Вы можете использовать Docker для развертывания и создания образов для продакшн, но вам не обязательно использовать его в разработке.


⏩Совет 2. Структурируйте инструкции Dockerfile как перевернутую пирамиду.

Каждая инструкция в вашем Dockerfile приводит к созданию слоя изображения. Docker использует слои для повторного использования работы. Слои кэшируются и их не нужно пересобирать, если:
— Все предыдущие слои не изменяются.
— В случае инструкции COPY: файлы/папки не изменяются.
— В случае всех остальных инструкций: текст команды не изменяется.


⏩Совет 3. Копируйте только те файлы, которые необходимы для следующего шага.

Представьте, что у нас есть следующий фрагмент Dockerfile:

RUN mkdir /code
COPY code code/
RUN pip install code/requirements.txt

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

Вот как мы могли бы избежать повторного запуска этапа установки при каждом изменении кода:

RUN mkdir /code
COPY code/requirements.txt code/
RUN pip install code/requirements.txt
COPY code /code

⏩Совет 4. Скачивайте меньше файлов.

Во-первых, проверьте, не загружаете ли вы зависимости разработки, которые вообще не нужны вашему образу.

Ещё нужно помнить про поведение менеджера пакетов на уровне ОС. Например, `apt`который используется в Ubuntu и Debian, по умолчанию устанавливает «рекомендуемые» пакеты.
Вы можете избежать этого, добавив к apt-get install флаг --no-install-recommends


⏩Совет 5. Используйте BuildKit с новой функцией монтирования кэша.

BuildKit — это новый механизм сборки образов, который можно использовать вместо стандартного Docker. С ним вы получаете больше параллелизма и эффективности кэширования, плюс новые интересные функции

📎 Читать подробнее

@DevOPSitsec

📌Лучшие практики по безопасности при использовании Docker

Держите рекомендации по безопасной работе с образами и контейнерами
⏩ PDF

@DevOPSitsec

🖥 Как использовать Node.js с Docker

⏩Как мы знаем Node.js позволяет создавать быстрые и масштабируемые веб-приложения, используя JavaScript и на сервере, и на клиенте.
Ну и для того, что приложение предсказуемо работало и там, и там, мы используем Docker, конечно же.

⏩Эта статья поможет структурировать знания о сборке контейнеров с помощью Docker, поможет освежить азы основы с образами и не только.
Уверен, будет полезно, держите

📎 Статья

@DevOPSitsec