🌟 Вышел WingetUI (UnigetUI) 3.0

⏩13 марта 2024 года состоялся релиз WingetUI (UnigetUI) 3.0. Это графический инструментарий с открытым исходным кодом, который позволяет устанавливать, удалять и обновлять приложения на устройствах Windows с помощью наиболее распространённых консольных менеджеров (CLI) для Windows 10 и Windows 11, включая Windows Package Manager (winget), Scoop и Chocolatey, а также Pip, Npm, .NET Tool и PowerShell Gallery.

⏩Фактически WingetUI превратился в поддержку различных менеджеров пакетов, а не только Winget, что привело к тому, что имя WingetUI сбивает с толку новых пользователей и не отражает основную суть этого приложения. В настоящее время в WingetUI доступно более 14 тыс. пакетов (Winget, Scoop и Chocolatey).
Автор проекта Марти Климент пояснил, что он с каждым днём наблюдает, как пользователи всё чаще путают WingetUI и winget, что вполне ожидаемо, учитывая небольшую разницу между этими двумя названиями. Поэтому WingetUI скоро будет переименован в UnigetUI.

@DevOPSitsec

📌20 полезных, но малоиспользуемых команд Git

Держите, это кликабельный список:
⏩ Git Web — открыть встроенный графический интерфейс
⏩ Git Notes — прикрепить дополнительную информацию к коммитам
⏩ Git Bisect — дебажить как про
⏩ Git Grep — найти что угодно
⏩ Git Archive — сжать проект для шеринга
⏩ Git Submodules — импортировать другие репозитории в ваш
⏩ Git Bugreport — скомпилировать баг-репорт с информацией о системе
⏩ Git Fsck — проверить и восстановить недоступные объекты
⏩ Git Stripspace — удалить пробелы в конце текста
⏩ Git Diff — сравнить изменения между двумя файлами
⏩ Git Hooks — выполнить скрипт при запуске команды git
⏩ Git Blame — показать, кто написал данную строку
⏩ Git Large File Storage — сохранить большие файлы в git
⏩ Git Garbage Collection — оптимизировать git-репо
⏩ Git Show — легко просмотреть любой объект git
⏩ Git Describe — дать читаемое имя на основе последнего тега
⏩ Git Tag — создать метки версий в определенных точках
⏩ Git Reflog — список всех действий, выполненных над репозиторием
⏩ Git Log — просмотреть журнал коммитов и диаграммы ветвей
⏩ Git Cherry Pick — вытащить фичу в вашу ветку
⏩ Git Switch — быстро переключиться между ветками

Пользуйтесь)

@DevOPSitsec

💻 Лучшие практики работы с Kubernetes

Держите, остаётся самое сложное — следовать этим практикам)

📎 А вот полезная статья в тему, где подробно рассказывается о каждом из правил

@DevOPSitsec

💻 Будущее Kubernetes и DevOps: строим прогнозы на 10 лет

Полезная статья, в ходе которой опросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие.

Цель статьи — спрогнозировать будущее на основе тенденций в настоящем.

Вот вопросы, которые освещаются:
⏩Будет ли еще популярен Kubernetes через 5–10 лет? Какие технологии могут прийти ему на смену? Какие вызовы ему придется решать?

⏩Будет ли ещё DevOps? Как изменится его понимание? Как изменится культурный аспект, стоящий за DevOps-практиками? Как могут измениться сами практики?

⏩Какие интересные, необычные Ops'ы могут появиться? Какие задачи они будут решать?

⏩Что станет с Cloud Native-экосистемой и программами внутри нее? Какие проблемы она должна будет научиться решать? Какие новые программы могут появиться в ней? Что станет с облаками? Как они изменятся? Придет ли какая-то другая технология на смену облакам, и если да, то какой примерно она будет?

📎 Статья

@DevOPSitsec

💻 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