Анонсы и прогнозы: Docker с Dynamic MCP, Rust в Linux, тренды.

Срединедельный DevOps! Обсудим прогнозы и ключевые события уходящего года: развитие DevOps-инструментов, Rust в Linux, рост трафика с ИИ и лучшие кейсы цифровизации.

⏺Docker Desktop 4.5 и Dynamic MCP
Docker Desktop – приложение для локальной разработки, которое позволяет разработчику собирать, запускать и администрировать контейнеризованные приложения. Представили экспериментальную функцию Dynamic MCP в версии Docker Desktop 4.5. При её использовании ИИ-агенты находят и подключают MCP-серверы в реальном времени. Dynamic MCP начинает работу при подключении клиента к MCP Toolkit, а шлюз MCP предоставляет агентам набор инструментов (mcp-find, mcp-add и др.), с помощью которых им удается обнаружить, добавить и управлять серверами в ходе работы. Подробнее об особенностях функции читайте тут, а с примером использования – на GitHub.

⏺Эксперимент признан успешным: Rust в проекте ядра Linux
Эксперимент по внедрению Rust в ядро Linux, начатый в версии 6.1 в 2022 году и в котором приняли участие 173 разработчика, официально завершён. Ведущий разработчик Rust для Linux Мигель Охеда опубликовал патч для удаления из документации к ядру предупреждения о характере поддержки. Язык уже используется в производственной среде, поддерживается рядом крупных дистрибутивов Linux. Стоит учитывать, что поддержка Rust пока не охватывает все возможные конфигурации ядра, архитектуры и инструментальные цепочки. Так, часть сценариев, включая смешанные сборки с GCC и LLVM, полноценная поддержку GCC остаётся экспериментальной. Значительный объём работы предстоит как в самом ядре, так и в смежных проектах – upstream Rust, GCC и других компонентах экосистемы. Ознакомиться с комментарием можно здесь.

⏺Cloudflare: 19% годового роста трафика и растущая доля ИИ-ботов
По результатам отчёта Cloudflare за 2025 год наблюдается рост глобального интернет-трафика на 19%. Из ключевых особенностей выделяем автоматизированных агентов и сервисов ИИ, которые составляют значительную часть прироста. Подобные изменения сказываются на структуре трафика и порождают требования к новой, безопасной инфраструктуре. В отчёте представлена информация по усилению угроз безопасности и снижению устойчивости сервисов. Cloudflare зафиксировала 25 крупных распределённых DDoS-атак, которые привели к сбоям и ограничению доступа сервисов. В качестве оптимального решения компания внедрила постквантовое шифрование для 52% TLS 1.3-трафика. Подготовка к будущему, в котором квантовые компьютеры обойдут системы шифрования, началась уже сейчас. Подробности об интернет сервисах, HTTP версиях, IPv6 можете прочесть здесь.

⏺«Лидеры Цифрофизации – 2025»: номинация лучший кейс
Внедрение цифровых технологий в процессы бизнеса и управления не потеряют актуальности в 2026-м. Портал TECH совместно с бизнес-клубом Global при поддержке «Деловой России» и «Ассоциация "Руссофт"» опубликовал результаты рейтинга «Лидеры Цифрофизации – 2025», задачей которого являлось отображение лидирующих российских IT-компаний в сфере финансовых услуг, научно-исследовательской деятельности, инженерии и разработки. Победителем в лидеры номинации «Лучший кейс» стал проект по внедрению 1С, системы ML Sense в ММНИО. В число лидеров вошёл кейс «TargetADS» IT-интегратора Nixys по разработке сервиса проверки качества инвентаря, антифрода с выявлением неревантных показов, кликов, что позволило оптимизировать расход рекламного бюджета. Ознакомиться с результатами рейтинга TECH можно здесь.

#docker #dynamicmcp #rust #linux #devops

Пятничное чтиво от DevOps FM

Сегодня поговорим об инфраструктурных мелочах с большими последствиями.

👀Что могло пойти не так, но с версией Kubernetes 1.35 будет работать корректно
• Под уверенно занял порт на хосте, а потом мы выяснили, что все процессы внутри работали как root. Хорошо, что теперь это можно настроить.
• Для распределённой задачи требуется 10 рабочих подов, а запустилось только 5. Что с этим делает Kubernetes 1.35?
• Образ на узле, ресурсов хватает, но под не стартует – kubelet проверяет наличие imagePullSecrets.
• Кластер не поднялся после обновления узлов. При чём тут cgroup v1 и релиз 1.35? Читайте в статье.

👀5 ошибок DevOps стартапа (версия 2025)
• DevOps как набор инструментов
Контуры процессов, технический стек внедрены, а совместной ответственности и быстрой обратной связи всё ещё нет.
• Команды работают разрозненно
Разработка, эксплуатация и безопасность живут в своих мирах – потом долго ищут виноватых и чинят одно и то же.
• Гонка за скоростью без прозрачности.
Релизы частые, но без мониторинга и логов проблемы находят пользователи, а не команда.
• Ручные операции там, где давно нужна автоматизация.
Деплой «по инструкции», инфраструктура «на память», подборка ошибок – человеческих и повторяющихся.
• Безопасность на «потом»
Сканирование, политики и контроль доступа подключают после инцидента, когда уже поздно.
Подробности читайте здесь.

👀Побойтесь DevOps-а…
Компания искала DevOps-инженера, чтобы навести порядок в инфраструктуре, и наняла специалиста с полными правами на продовые серверы. Прошло время и сотрудничество прекратили: доступы отозвали, пароли сменили, учётки заблокировали. Спустя пять дней прод внезапно упал: сервисы недоступны, логи выглядели «разорванными», массовая утечка данных. В ходе внутреннего расследования выяснили – до увольнения был создан скрытый пользователь с правами root, через VPN добавлена отложенная cron-задача на уничтожение системы, а после срабатывания последовал шантаж с требованием выкупа. Как всё закончилось? Читайте здесь.

🚀Приятного чтения! Пусть все инциденты сегодня будут только на Habr.

#пятничноечтиво #kubernetes #devops #security

Kubernetes CPU & Memory Requests/Limits – объясняем по-человечески

В Kubernetes YAML разделы requests и limits задают минимальные и максимальные ресурсы пода, и их неверная настройка может вызвать троттлинг CPU, OOMKill и принудительное удаление пода с узла при высоких нагрузках. Грамотная конфигурация этих параметров необходима для корректного шедулинга подов и поддержания стабильности кластера. В статье автор использует сравнение Kubernetes с отелем для наглядного объяснения.

👩‍💻Kubernetes можно представить как отель:
Под = гость отеля
Узел = здание отеля с ограниченным количеством ресурсов

⏺Каждому «гостю» нужно указать:
1. Requests – минимальные ресурсы, необходимые для корректной работы
2. Limits – максимальные ресурсы, которые под может потреблять

⏺Какая роль здесь отведена CPU?
• Request – гарантированное количество CPU, влияет на планирование, но не ограничивая максимум. Под может использовать больше CPU при наличии свободных ресурсов.
• Limit задаёт жёсткое ограничение на потребление CPU. Превышение лимита приводит к троттлингу.

Итак: request = минимальное количество электричества для работы 💡; limit = предел, который выдержит предохранитель ⚡️.

⏺Как настроить requests/limits в Kubernetes

Шаг 1: Измеряем среднее и пиковое потребление CPU/памяти (kubectl top pod, Prometheus/Grafana).

Шаг 2: Requests = Среднее × 1.2 → гарантируем стабильную работу без троттлинга.

Шаг 3: Limits = Пик × 1.3–1.5 → оставляем запас, чтобы под не падал из-за OOM.

⏺Что еще необходимо помнить при задании ресурсов приложению: QoS

Quality of Service (QoS) – это механизм, с помощью которого Kubernetes классифицирует Pods по уровню гарантии ресурсов на основе заданных requests и limits.

• Guaranteed Pods
Под получает строго равные значения request и limit для CPU и памяти. Kubernetes гарантирует, что Pod не будет уничтожен до тех пор, пока не превысит свои лимиты или не будут доступны приоритетные Pods.
• Burstable Pods
Могут использовать ресурсы сверх request при свободных ресурсах узла, но при давлении на узел они уничтожаются после Guaranteed и чаще получают OOMKill.
• BestEffort
Самый низкий уровень QoS: присваивается, если у Pod‑а нет ни requests, ни limits для CPU и памяти. Такие Pods используют остаточные ресурсов узла, и в случае дефицита именно они будут удалены первыми.

🚀Понимание и правильная настройка параметров requests и limits позволяет избежать непредвиденных завершений подов и поддерживать стабильность работы кластера.

#k8s #requests #limits #cpu

Обновленная версия systemd, архитектура Debian и доступ к Docker Hardened Images (DHI)

👀Новостная среда по расписанию. Выкатываем дайджест с основными событиями за прошедшую неделю.

⏺Релиз systemd 259: что представлено в обновлении
Доступна версия системного менеджера systemd 259, комплексной системы инициализации и управления, скелета современных дистрибутивов Linux. В релиз включена частичная поддержка стандартной библиотеки Musl, альтернативной библиотеки C, опция --empower в run0 для выполнения привилегированных действий без перехода на root, динамическая загрузка зависимостей libsystemd (libacl, libblkid, libseccomp и др.), встроенная работа с TAR в systemd-importd и измененный режим хранения журнала. Подробнее о новой версии читайте в статье или переходите на GitHub.

⏺LoongArch (loong64) в Debian: официальная поддержка архитектуры
Более чем через два года после первоначального запуска в Ports, loong64 стала официальной архитектурой в Debian. Разработчики проекта поделились планами на включение архитектурных особенностей в предстоящий релиз Debian 14 («forky»). Адриан фон Биддер сообщил о сборке и импорте начального набора из 112 пакетов для создания начального chroot-окружения и настройки сборочного сервиса buildd. Подробный комментарий Адриана можно найти здесь, а статус buildd от loong64 тут.

⏺Открыто и бесплатно: DHI под Apache 2.0
На портале The New Stack вышла статья о предоставлении свободного доступа к защищенным образам Docker Hardened Images (DHI). DHI минимизируют риски для поставок на уровне контейнеров. Без root-прав, без лишних компонентов, без уязвимостей – и с поддержкой стандарта VEX. По результатам внутренней статистики Docker Hub фиксирует более 20 миллиардов pull-запросов в месяц. Компания стремится предоставить безопасную, готовую к продакшену платформу и установить новый отраслевой стандарт для разработчиков. Подробности о фичах в статье. А получить доступ к полному каталогу DHI и вариантам подписки можно здесь.

#новостнаясреда #docker #dhi #debian

CPU limits в работе с Kubernetes

💬В одном из недавних постов мы рассмотрели, как объяснить особенности Kubernetes CPU & Memory Requests, Limits по-человечески, сегодня обсудим опыт пользователей Reddit в работе с лимитами в проде. Весь тред можете прочесть здесь.

🗣По результатам опроса, в котором приняло участие 247 человек, ~54% используют CPU limits, но с небольшими оговорками:

ThePapanoob
В вопросе не отражены нюансы. Существует множество кейсов и в некоторых действительно нужно применять CPU limits, в других они только мешают работе

lulzmachine

Обычно начинаю без них, но всегда добавляю позже. Всеми способами избегаю «шумных соседей» (поды или контейнеры, которые

потребляют много ресурсов

и мешают другим подам нормально работать на том же ноде)

Xeroxxx

Да, мы используем лимиты в проде. Requests и Limits устанавливаются одинаково. Для скейлинга используем karpenter.

⏺Чуть меньше половины опрошенных не видит смысла в CPU limits при наличии CPU requests:

romeo_pentium

CPU limits становится причиной троттлинга и неиспользованных CPU. Мы всегда можем работать с CPU requests. Преимущество в том, что контейнер не будет использовать CPU request другого контейнера.
Linux kernel троттлит ваш CPU по мере его приближения к лимиту.
Без лимитов производительность выше, и я не нашел преимуществ в их установке.

Ariquitaun

CPU limits обычно приводят к снижению производительности. Нам нужны только CPU requests для гарантии базового уровня производительности на проде.
С памятью дела обстоят по-другому – ООМ приведет к прекращению рабочих нагрузок в самое неподходящее время, а иногда к «убийству» нодов.

th0th

Я преимущественно использую requests, limits очень редко. Я предпочитаю следить за фактическим использованием и обвновлять request по необходимости.
У меня установлены алерты на превышение CPU в нодах, использовании памяти. Мне кажется, безопаснее опираться на систему оповещений, чем на последствия использования лимитов, по типу троттлинга.

Какой алгоритм работы в проде используете вы и ваши коллеги? Делитесь опытом в комментариях👀

#kubernetes #cpu #cpu_limits #cpu_requests

🛡Безопасность в Docker: SBOM и выявление уязвимостей

Сегодня разбираем, как обеспечить безопасность цепочки поставок в Docker на примере практического гайда Shamsher Khan: Advanced Docker Security: From Supply Chain Transparency to Network Defense. Подробно разберем обеспечение прозрачности цепочки поставок с помощью SBOM, спецификации ПО (Lab 07), а подробнее об установке эшелонированной защиты от DDoS и ботов (Lab 08) можете прочесть здесь.

👀Почему тема важна в сообществе?
• В 2021 инцидент с Log4Shell, ошибкой в библиотеке Log4j, указал на большую проблему современной разработки – незнание состава контейнеров.
• Кибератака SolarWinds произошла в том же году, что инцидент выше.

⏺В статье представлены две лабы, задеплоить можно уже сегодня:
1. Обеспечение прозрачности цепочки поставок с помощью SBOM (Lab 07)
2. Эшелонированная защита от DDoS и ботов (Lab 08)

💬Обеспечиваем безопасность цепочки поставок со SBOM (Lab 07)
Рассмотрим Dockerfile:

FROM python:3.11-slim 
COPY requirements.txt . 
RUN pip install -r requirements.txt 
COPY app.py . CMD ["python", "app.py"]

Вопрос знатокам: какие пакеты в этом образе? Без SBOM мы можем догадаться: e.g. Python 3.11, requirements.txt и OS уязвимости.
SBOM позволяет получить полный список всех компонентов, версий и лицензий, сгенерированный за секунды.

🚀На старт, внимание, SBOM
В статье представлен демо-скрипт для выполнения с последовательностью из 12-ти шагов.

💬Шаг 1: установка инструментов.

# Install Syft (SBOM generation) 
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin 

# Install Grype (vulnerability scanning) 
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin 

# Verify installation 
syft version grype version

💬Шаг 2: установка SBOM

From a Docker image
syft nginx:alpine -o spdx-json > nginx-sbom.json

# From a directory
syft dir:./myapp -o cyclonedx-json > myapp-sbom.json

# Multiple formats at once
syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json

💬Шаг 3: выявляем уязвимости

# Scan the SBOM
grype sbom:./nginx-sbom.json

# Or scan image directly
grype nginx:alpine

💬Шаг 4: сравниваем версии SBOM

# Generate SBOMs for two versions
syft myapp:v1.0 -o json > v1.0-sbom.json
syft myapp:v2.0 -o json > v2.0-sbom.json

# Compare (using provided script)
./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json



💬Шаг 5: выявляем уязвимости в SBOM

# Scan the SBOM
grype sbom:./nginx-sbom.spdx.json

# Or scan image directly
grype nginx:alpine

💬Шаг 6: определяем типы уязвимостей по параметрам

# Only show CRITICAL and HIGH
grype nginx:alpine --fail-on high

# Only show CRITICAL
grype nginx:alpine --fail-on critical

# Show only specific severity
grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")'

# Export vulnerabilities to JSON
grype nginx:alpine -o json > vulnerabilities.json

В шагах 7 и 8 сравниваем версии SBOM и ищем конкретные пакеты, а в 9 – рассматривает отчёт/журнал SBOM

💬Финальный шаг, 12: интеграция в CI/CD (Azure DevOps)

azure-pipeline.yml

- task: Docker@2
  inputs:
    command: build
    dockerfile: '**/Dockerfile'
    tags: $(Build.BuildId)

- script: |
    syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json
  displayName: 'Generate SBOM'

- script: |
    grype sbom:./sbom.json --fail-on high
  displayName: 'Scan for Vulnerabilities'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: 'sbom.json'
    artifactName: 'SBOM'

👨‍💻В результате, скорость реагирования при обнаружении уязвимостей сокращается с 14 до 2 дней, осуществляется поддержка 3-х форматов (SPDX, CycloneDX, Syft JSON) и гарантируется полное соответствие требованиям – EO 14028.

👩‍💻Делимся репозиториями:
• Syft – установка SBOM
• Grype – выявление уязвимостей
• Docker Security Practical Guide – полный гайд с Lab 07 и Lab 08

#devsecops #SBOM #zerotrust #kubernetes

Как DDoS повлиял на Arch Linux и что нового в релизах Kitty Terminal, Angie?

Последний новостной дайджест… в этом году. Что приготовили обновления последних дней 2025-го?

⏺Arch Linux и DDoS атаки: доступ по IPv6
Arch Linux временно отключил доступ к web-сервисам на домене archlinux.org по IPv4 в ответ на DDoS-атаку. Cайт остаётся доступным по IPv6, и сервисы AUR, Wiki, форум и GitLab продолжают работать. Если основным репозиториям недоступен доступ по IPv4, рекомендуем переключиться на зеркала, перечисленные в pacman-mirrorlist, чтобы продолжить обновления и установки. Подробнее о статусе можете прочесть здесь ,больше о доступе найдете в треде.

⏺Kitty Terminal 0.45 – стабильность и расширенные возможности превью
Состоялся релиз терминала Kitty 0.45. Многофункциональная версия, с поддержкой опции GPU‑accelerated, кроссплатформенного эмулятора ориентирована на стабильность. Исходный код проекта написан на Python, C и Go и опубликован на GitHub под лицензией GNU General Public License v3.0. В версии 0.45 представили опцию choose-files для выбора файлов с интерфейсом, ориентированным на клавиатуру, и поддержкой предварительного просмотра содержимого. Новая версия решения в значительной степени ориентирована на стабильность, в ней исправлены ранее найденные некритичные ошибки. Подробнее читайте здесь.

⏺Веб-сервер Angie 1.11.0, созданный бывшей командой Nginx
24 декабря 2025 года разработчики из компании «Веб-Сервер» выпустили веб-сервер Angie 1.11.0. Форк Nginx получил сертификаты совместимости с российскими ОС «Ред ОС», Astra Linux Special Edition, «Роса Хром Сервер», «Альт» и «ФСТЭК‑версии Альт». В Angie 1.11.0 команда сосредоточилась на observability и надёжности: появился новый модуль метрик для сбора и агрегации в реальном времени с выходом в Prometheus/JSON, что упрощает детекторинг узких мест; параллельно решены проблемы с HTTP/3 и улучшена маршрутизация QUIC через BPF-доработки, а также расширена поддержка ACME (включая ALPN и отчёт о перевыпуске сертификатов в API/Prometheus), что делает работу с TLS более предсказуемой. Подробнее о релизе читайте здесь или в обзоре.

#archlinux #ipv6 #linux #kittyterminal

Дед Мороз заглянул в DevOps FM...

Чтобы поздравить подписчиков с наступающим Новым годом!🎄Как снегурочки-администраторы мы благодарим вас за участие в обсуждениях, пересылки гайдов (и не только) коллегам, внесение правок и коррективов в посты о штурвалах и кораблях 👩‍💻 И говорим спасибо за то, что вы есть!

В 2026 году желаем спокойных смен, реализации самых смелых идей и движения вперёд к поставленным целям!

В качестве благодарности за вашу активность, продолжаем традицию дарить открытки. Если возникнет желание порадовать коллегу в офисе, версия для печати – здесь.

⏺А чтобы было чем заняться на январских, подготовили подборку постов за 2025:
•Использование скрытых каталогов Unix
•Слышали про bundle-uri в Git?
•Стратегии по disaster recovery с Terraform
•Как подготовиться к облачным инцидентам: рассказали подробнее
•Выбор in-memory БД в 2025: Redis, Valkey, DragonflyDB и KeyDB
•Логирование и мониторинг — топ-3 инструмента для DevOps в 2025
•От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

С наступающим Новым годом и до встречи в 2025+1👩‍💻

🖖Всем DevOps! Новогодние салаты кончаются, салюты отгремели, а исполнение желаний требует сил и планирования...с Новым 2026 годом!🎄

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

По результатам опроса коллег из State of DevOps, среднее количество задач на технического сотрудника выросло с 3,76 до 4,15. Жаль, не был замечен рост зарплаты... А если серьезно, на рабочем месте инженер всё больше и швец, и жнец, и на игре дудец. Помимо повышенной нагрузки возникают и другие проблемы. В крупных компаниях все действия и бездействия приходится согласовывать, а в компаниях малого и среднего бизнеса – брать больше задач и обучать джунов. Свои плюсы и минусы есть везде, но как выбрать из двух зол?

👨‍💻Если вы всё ещё в раздумьях, в какой компании можно развить компетенции и не умереть в 2026, пройдите наш тест "Я был рождён, чтобы работать в...", а в комментариях делитесь результатами.

Узнайте, где комфортно работать – тут.

P.S. для C-level и владельцев бизнесов: спасибо за ваш труд, тест – развлекательный, с юмором и стереотипами. Предлагаем поделиться мыслями в комментариях💬

Обновления 2026: Kubernetes 1.35, Debian 13.3, Zena и Argo

👨‍💻Уже среда? По расписанию – первый новостной дайджест этого года.

⏺Функции в Kubernetes 1.35
В начале месяца Kubernetes анонсировали функцию In-Place Pod Resize Graduates to Stable с изменением в CPU-лимитах и запросах. Отслеживайте ресурсы внутри работающего пода, без перезапуска контейнера. Также анонсировали две функции: Toleration операторов для числовых сравнений (alpha), Gt(больше чем) и Lt(меньше чем) spec.tolerations, и управления credential-плагинами для kubectl. Ознакомиться с use-кейсами по альфа-функции здесь а с полным описанием функций бета-версии тут.

⏺Обновленный Debian: исправили ошибки, добавили патчи
Вышло обновление в дистрибутиве Debian Trixie на базе ядра Linux 6.12.63-1 LTS. Команда подчеркивает – релиз не является новой версией и включает обновленный набор пакетов. В версию 13.3 были включены пакеты для ansible, apache, dpdk, flatpak,gnome-shell с upstream-релизами, исправлены ошибки в awfull, calibre, composer и др. Команда устранила комплекс проблем: переполнение целочисленных значений, некорректный анализ переменных окружения, ошибка отказа в обслуживании, инициализации длины буфера шифрования. Ознакомиться со списком пакетов тут, обновления безопасности и общая информация здесь.

⏺Мятный Linux 22.3 – что нового?
Состоялся релиз Linux Mint «Zena» на ядре Linux 6.14 и базе Ubuntu 24.04 LTS, поддержка версии осуществляется до 2029 года (LTS). В обновлении преобразовали инструмент «System Reports», актуальное название «System Information», добавили страницы для просмотра детализированного списка подключённых USB-устройств с типом, идентификатором и группировкой по контроллерам, информацию о PCI-устройствах, PCI ID и используемых драйверах. Также представили функцию управления «System Administration» со страницей «Boot menu», где вы можете задать время отображения и параметры загрузки. Подробнее об обновлении здесь, а инструкцию для сборки на Cinnamon 6.6, Xfce 4.18 и MATE 1.26 найдете тут.

⏺Argo CD Agent: управление кластерами и приложениями
Red Hat объявили о выходе Argo CD Agent совместно с релизом Red Hat OpenShift GitOps 1.19. Пользовательский интерфейс и API разворачиваются в централизованной control plane, а ключевые компоненты, такие как application-controller, – локально в каждом кластере. В релизе представлены два режима работы: управляемый и автономный. Для обеспечения отказустойчивой EDS ввели два компонента. Principle передает команды, статусы между Control hub и агентами управляющих кластеров, а Agent обеспечивает масштабируемость. Подробности обновления здесь, инструкция по установке агента тут.

#дайджест #kubernetes #linux #gitops #argocd

🎙️Слушаем пятничную подборку подкастов в DevOps FM!

⏺Flox, Nix, and Reproducible Software Systems от Software Engineering Daily. В новом выпуске затронули проблему воспроизводимости и безопасности в современной разработке ПО и обсудили, как подход Nix к управлению пакетами и зависимостями повышает воспроизводимость и безопасность, а также роль Flox в проектах. Болл предложил варианты деплоя без классических больших Docker-образов, поднял вопросы мультиархитектурных разрешений зависимостей (разрешение «closures» и групп пакетов) и их ограничения на практике. Узнать детали – здесь.

⏺We Broke Our EKS Cluster Autoscaler with the AL2023 Migration от Kube FM. Барт Фарелл разбирает инцидент, который возник при миграции EKS на Amazon Linux 2023. Почему после обновления AMI автоскейлер потерял AWS-права в кластере, как корректно внедрить IRSA (IAM Roles for Service Accounts), проверить зависимость конкретных подов от IAM-ролей нодов и очистить устаревшие IAM-разрешения, чтобы сократить атаки после миграции – слушайте тут.

⏺ Engineering Around Extreme S3 Scale with R. Tyler Croy от Last week in AWS. Р. Тайлер Крой, инженер Scribd, рассуждает с Кори Куинном о проблеме хранения миллиардов объектов в облачном объектном хранилище S3 и. Как организовать работу, когда простые задачи обходятся компании в 100 000 долларов. В подкасте услышите тезисы о распределении бюджета на инфраструктуру в облаке, опыт Scribd, накопленный за 18 лет на рынке. Крой настаивает – стандартные решения больше не работают при большом потоке вводных данных, нужно генерировать новые. Подробности – здесь.

Приятного прослушивания и пятниц без инцидентов🛡

#подкаст #devops #kubernetes #eks

Ко8мар в n8n: 𝗖𝗩𝗘-𝟮𝟬𝟮𝟲-𝟮𝟭𝟴𝟱𝟴

🚀Всем DevOps! Сегодня речь пойдёт о безопасности. Cyera Research Labs опубликовала отчет о CVE-2026–21858, коротко «Ni8mare», уязвимости CVSS 10.0. Пользователь Марио Кандела задеплоил кастомную ловушку в Beelzebub, чтобы отследить попытки взлома в n8n. Ниже – разбираем spray-атаку на n8n и даём рекомендации по её устранению. Полностью статью читайте – тут.

👀В чём суть проблемы?
Некорректная обработка HTTP-запросов в n8n Form Webhook.

Обычный флоу: пользователь загружает файл через форму, у запроса тип Content-Type: multipart/form-data . n8n использует Formidable для безопасного анализа загрузки, хранит файлы в случайной временной директории.
Флоу с уязвимостью: если злоумышленник меняет Content-Type на application/json, n8n использует другой парсер (`parseBody()`), который напрямую заполняет req.body.files значениями, и пользователь может взять над ними контроль.

Полная цепочка эксплуатации от Cyera здесь.

Журнал атаки:
⚫️7 января 2026: отчёт
Cyera Research Labs опубликовала подробный отчёт о Ni8mare уязвимости, которая позволяет выполнять неавторизованный удаленный код на локально развернутых экземплярах n8n.

⚫️9 января 2026, 06:58:32 UTC Начало конца
⏺Фаза 1: разведка


User-Agent: python-requests/2.32.5

Злоумышленник запрашивает /rest/settings для определения n8n-версии. Пользовательская ловушка предоставляет информацию – 1.120.0 (уязвимая)

⏺Фаза 2: spray-атака (06:58:33–06:58:35 UTC)
В течение нескольких секунд была запущена spray-атака на несколько endpoint-ов с идентичными вредоносными нагрузками



Content-Type: application/json
User-Agent: python-requests/2.32.5
{
  "data": {},
  "files": {
    "f-t8ebu1": {
      "filepath": "/etc/passwd",
      "originalFilename": "z0nojfcn.bin",
      "mimetype": "application/octet-stream",
      "size": 43492
    }
  }
}



⏺Анализируем payload
Точное совпадение с CVE-2026–21858. За 3 секунды 17 endpoint-ов подверглись атаке.

Ni8mare не даёт спать: уязвимость не требует аутентификации, легко воспроизводима и может привести к последующей полной компрометацией инстанса n8n. Censys оценивает 100.000 инстансов в сети как потенциально уязвимые. Есть ли среди них ваш?

⏺Что делать уже сейчас?
1. Немедленно обновитесь до версии 1.121.0 или более поздней
2. Закройте публичный доступ к n8n
3. Запрашивайте аутентификацию ко всем Form-ам и Webhook-ам
4. Отслеживайте логи на наличие Индикаторов Компроментации (IoCs): сетевые, HTTP-паттерны запроса, Sigma-правила

👩‍💻 Подборка полезного:
•CVE-2026–21858 — GitHub Advisory
•Конфигурация Beelzebub n8n honeypot

#devsecops #cybersecurity #vulnerability #cve

Релизы и безопасность

Срединедельный DevOps! Поговорим о том, как Cozystack 0.41 добавляет MongoDB и улучшает стабильность Kubernetes, а MX Linux 25.1 возвращает поддержку dual-init-a.

⏺Cozystack v0.41.0: MongoDB
Вышел релиз версии Cozystack. В v0.41.0 добавили поддержку системы управления БД MongoDB. Она располагается наряду с PostgreSQL, MySQL и Redis. К ключевым особенностям относим интеграцию с хранилищем бэкэндов Cozystack, настраиваемые CPU, встроенный экспорт метрик для мониторинга. Чтобы развернуть MongoDB через Cozystack дашборд используйте первый и второй workflow. Также, в новой версии представлены улучшения в работы хранилища, патчи для piraeus-server, рефакторинг проверки RWX на уровне года, повышение стабильности работы Kubernetes за счет увеличения значений resourcesPreset apiServer по умолчанию до large и увеличения порог startup-probe для kube-apiserver. Подробнее о релизе – тут.

⏺Опасайтесь VoidLink
На портале Checkpoint Research опубликовали отчёт о мультифункциональном вредоносном ПО китайского происхождения (см. тут). VoidLink включает 37 плагинов, среди которых есть модули для устранения следов, выхода из контейнеров, сбора SSH-ключей, токенов и API-ключей. Фреймворк ориентирован на cloud- и container-first-среды и способен стабильно работать в Kubernetes и Docker, адаптируя поведение под окружение. Используются LD_PRELOAD, загружаемые модули ядра (LKM) и eBPF. Подробнее - здесь.

⏺Бесконечность не предел: MX Linux 25.1 «Infinity»
Релиз MX Linux 25.1, Debian-based дистрибутива. Все сборки поставляются с ядром Linux 6.12 (Debian-ветка), за исключением Xfce-AHS, где используется ядро 6.18 с патчами liquorix. В AHS-сборках также обновлён Mesa до версии 25.3.3. Включены все обновления Debian до Debian 13.3 и все актуальные обновления из репозиториев MX. В релизе анонсировали возвращение поддержки dual-init (systemd + sysvinit) в едином ISO-образе, что сокращает количество сборок, systemd теперь обновляется через Debian, а не через отдельный MX-пакет, что упрощает поддержку. Для желающих установить – инструкция тут.

#devops #cozystack #mxlinux #kubernetes #platformengineering