Пятничный деплой

💡 А вы знали, что Trivy Operator может автоматически искать уязвимости в ваших workloads, сканируя используемые образы и предоставляя отчеты с CVE прямо в кластере. Дашборда правда не нашлось, пришлось сгенерить по шустрому — https://github.com/pashtet04/grafana-dashboards/blob/main/trivy-operator.json За короткое время были обновлены большая часть инфраструктурных сервисов CRITICAL ⬇️26% HIGH ⬇️20%

❗️Небольшое уточнение к предыдущему посту: в нём была указана некорректная ссылка на бота. Актуальная ссылка для получения доступа к эфиру: @shortcut_devops_bot

🔍Тестовое собеседование с Head of DevOps уже завтра 11 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика. Как это будет: 📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Александру Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot Реклама. О рекламодателе.

Tuning Linux Swap for Kubernetes: A Deep Dive The Kubernetes NodeSwap feature, likely to graduate to stable in the upcoming Kubernetes v1.34 release, allows swap usage: a significant shift from the conventional practice of disabling swap for performance predictability. This article focuses exclusively on tuning swap on Linux nodes, diving into the critical Linux kernel parameters that govern swap behavior and how they influence workload performance, swap utilization, and eviction mechanisms. https://kubernetes.io/blog/2025/08/19/tuning-linux-swap-for-kubernetes-a-deep-dive

Четверг, а значит время проектов от подписчиков! 🌝 Тем, кто пропустил, что такое четверговые проекты от подписчиков, можно прочитать тут - https://t.me/tech_b0lt_Genona/4983 Слово автору @stekov_me --- Всем привет! Levara — инфраструктура контекста для AI-агентов Levara решает одну из ключевых проблем AI-агентов: потерю контекста между сессиями. Платформа сохраняет факты, решения, события и технические находки в структурированной памяти, а затем возвращает агенту только релевантную информацию — без повторной загрузки всей истории переписки. В одном локальном Go-сервисе Levara объединяет долговременную память, гибридный поиск, временной граф знаний, проверяемое Markdown-пространство и средства выполнения длительных задач. Данные остаются под контролем пользователя: источником истины служат SQL и обычные Markdown-файлы, а поисковые индексы можно восстановить в любой момент. Levara подключается к IDE, AI-агентам и внутренним сервисам через MCP, REST и gRPC. Решение подходит как отдельному разработчику, так и командам, которым нужны общая память проекта, разграничение доступа, аудит и наблюдаемость. Ключевые возможности: - структурированная память по проектам и темам; - гибридный поиск BM25 + HNSW с reranking; - темпоральный граф знаний и отслеживание актуальности связей; - проверяемое Markdown-пространство с версиями, конфликтами и восстановлением; - синхронизация между устройствами; - SQLite для локальной работы и PostgreSQL для командных сценариев; - JWT, API-ключи, ACL и аудит; - Task Runtime для длительных агентных задач с Definition of Done, checkpoint’ами и проверяемыми результатами — в статусе alpha; - метрики, диагностика и инструменты восстановления. Levara — local-first control plane для AI-агентов: долговременная память, точный поиск и проверяемое выполнение задач без зависимости от истории чата. Репозиторий и описание на русском - https://github.com/Stek0v/Levara/blob/main/README_RU.md ---

Управление ключами SSH — вызовы и эволюция подходов В инфраструктуре из 1000 серверов и 100 администраторов счет активным SSH-ключам может идти на тысячи. По умолчанию они не имеют срока действия, поэтому со временем накапливаются и устаревают. Исследования показывают, что в крупных компаниях до 90% ключей не используются и не администрируются, а часть оставшихся предоставляет доступ на уровне root. Отсутствие централизованного управления усугубляет проблему: при увольнении сотрудника его доступы могут забыть удалить, сохранив за ним возможность подключаться к системам. В итоге администраторы оказываются перед трудоемкой задачей контроля и актуализации авторизационных данных. Читать сказ про SSH-сертификаты (CA). @usr_bin_linux

Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining для Kubernetes». В отличие от большинства сканеров (Kubescape, Trivy, Polaris), которые ищут отдельные misconfigurations, данный инструмент строит граф privilege escalation и показывает реальные многошаговые цепочки атаки от любого непривилегированного субъекта до критических: - cluster-admin / system:masters - node-escape (привилегированные поды + hostPath) - доступ к секретам в kube-system Он использует BFS поиск по RBAC + состоянию подов и выдаёт полную цепочку с объяснениями, evidence и remediation. Ключевые возможности: - Модули (всего ~45 правил): RBAC (wildcard, impersonation, bind/escalate и т.д.), Pod Security, NetworkPolicy, Admission Webhooks, Secrets, ServiceAccounts, Least-Privilege (на основе audit logs). - Поддержка живого кластера, snapshot (JSON) и отдельных манифестов. - Отличные отчёты: интерактивный HTML, JSON, CSV, SARIF (для GitHub Code Scanning). - CI-friendly: --baseline, --ci-mode, delta-анализ. - Полностью offline-анализ после скачивания snapshot'а. - Хорошая документация, примеры remediation (kubectl patch, Kyverno/Gatekeeper). Здесь можно посмотреть демо отчет.

Спасибо за ваши ответы про отчёты! Ну, и раз уж мы здесь… Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling.team) разбираем индустрию исследований. Обсудили: • Для кого на самом деле пишут отчёты: для CTO или для работяг. • Почему все отчёты сейчас массово ушли в ИИ-хайп. • Где искать реальные инсайты (спойлер: в поле «Другое»). • И почему лучший способ изучить инструмент — пойти пить пиво с его автором. Слушать: → На любой удобной площадке → На YouTube → Наш сайт

🔍Тестовое собеседование с Head of DevOps уже завтра 4 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика. Как это будет: 📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Александру Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot Реклама. О рекламодателе.

Самый недооцененный механизм безопасности SSH или почему known_hosts — это не кэш Однажды я поймал себя на простой как два рубля мысли: known_hosts — это вообще не кэш. Это база доверенных идентичностей серверов. Когда SSH спрашивает: вы уверены, что хотите доверять этому серверу? Он сохраняет ваш ответ именно в known_hosts. И потом годами использует этот файл как единственный источник истины, чтобы понимать, разговариваете вы с тем же сервером или с кем-то совершенно другим. Получается интересная ситуация: один из важнейших механизмов безопасности SSH хранится в обычном текстовом файле. В статье разобраны приемы работы с этим файлом и его истинное предназначение. @usr_bin_linux

Мастер-класс по логированию в Linux: архитектура, инструменты и лучшие практики для DevOps и SRE Логирование — это старейшая и наиболее распространенная форма системной телеметрии, и тем не менее она остается одной из самых неправильно понимаемых. Инженеры перегружают систему логами, недогружают, логируют не то, что нужно, не централизуют их или полностью игнорируют ретеншн — до тех пор, пока инцидент в 3 часа ночи не заставит столкнуться с переполненным /var/log или отсутствием логов за нужный период. В современных распределенных системах — кластерах Kubernetes, микросервисах, serverless-функциях — логирование стало значительно сложнее. Один пользовательский запрос может затрагивать десятки подов на нескольких нодах и в разных пространствах имен. Без структурированного, коррелированного и централизованного логирования восстановить последовательность событий практически невозможно. В этой статье весьма подробно разбираются различные уровни логирования от самой генерации логов, до их сбора и хранения. 📱 Telegram | 📲 MAX

Продолжаем делиться интересными докладами по теме Kubernetes Security с прошедшей недавно конференции BSidesSF 2026. Доклад “Sandboxes, Seccomp, and Syscalls: Chasing Isolation in Kubernetes” от Mark Manning посвящён одной из самых сложных тем в Kubernetes — изоляции контейнеров и реальной безопасности sandbox-окружений. Автор подробно разбирает, почему контейнеры сами по себе не являются полноценной границей безопасности, какие ограничения есть у seccomp и где проходит граница между виртуализацией и изоляцией. Особенно интересно, что в докладе рассматриваются не только способы защиты workload’ов, но и реальные сценарии обхода sandbox-механизмов. Доклад будет полезен всем, кто работает с multi-tenant Kubernetes-кластерами и хочет лучше понимать риски container isolation.

Zero-copy in Go: sendfile, splice, and the cost of io.Copy A small file-serving service of mine slowed to a crawl one afternoon after a “harmless” middleware change. CPU on the server box doubled, throughput roughly halved. The diff was a single line: instead of handing a *os.File to io.Copy, somebody had wrapped it in a tiny logging reader to count bytes. That one wrap quietly turned off sendfile(2). This post is about that fast path: what Go does for you for free, how to see it actually fire, and the surprisingly easy ways to lose it. https://segflow.github.io/post/zero-copy-sendfile-splice

SRE Mind map Просто оставлю это тут: https://jtprogru.github.io/The-Way-of-SRE/mindmap/ Заходи, знакомься и накидывай PR/issues с полезностями! #TheWayofSRE #TWoSRE #Github #SRE #DevOps

Анатомия процесса загрузки Linux — от инициализации ядра до systemd Загрузка операционной системы — процесс многоступенчатый и разнообразный. Несколько лет назад я писал о процессе загрузки сервера x86 в режимах Legacy и UEFI, но акцент тогда был именно на «железной» части. Пришло время сместить внимание на программную составляющую. Посмотрим, какие стадии преодолевает ядро Linux, что происходит, и какие «фишки» можно выполнить на старте системы. Подробности в статье. @usr_bin_linux

Небольшое, но важное изменение в Kubernetes 1.36: поле Service.spec.externalIPs официально объявлено deprecated. Эта функция существовала с первых версий Kubernetes и позволяла “привязывать” внешний IP к сервису, но все эти годы считалась небезопасной из-за риска MITM-атак и CVE-2020-8554. Команда Kubernetes прямо говорит, что externalIPs — это “insecure by default”. В будущих релизах поддержку уберут полностью из kube-proxy, а пользователям предлагают мигрировать на LoadBalancer, NodePort или Gateway API. Если вы не используете externalIPs, переживать не о чем. Но если используете — пора планировать миграцию: начиная с 1.36 – deprecated, а полное удаление ожидается примерно к версии 1.43.

Linux Incident Response: системный подход. Часть 1 Большинство материалов по Linux IR сводятся к спискам команд: посмотреть процессы, сеть, пользователей, cron, логи. Проблема в том, что сами по себе команды мало что дают, если нет порядка их применения, ограничения live response, смысл полученного вывода и вообще — методологии, базиса работы. Этот материал исправляет такие упущения. Он будет разбит на две части. В этой статье обсуждаются принципы расследования, изоляции, подготовки инструментария, начала анализа и исследования сети и процессов. 📱 Telegram | 📲 MAX

PatchMon PatchMon — это платформа, которая предоставляет единый интерфейс для мониторинга, обновления и защиты всего парка Linux-систем с поддержкой агентов FreeBSD и Windows. Легковесный агент осуществляет исходящую связь с сервером PatchMon по расписанию — входящие порты на контролируемых хостах не требуются — обеспечивая видимость состояния пакетов. Репыч на Гитхаб @usr_bin_linux

 Вышел релиз 0.33.1 SRE Learning Platform - крупнейшее обновление по Istio за всю историю проекта: полноценный курс для самостоятельного изучения + 4 новые практические лабы. Если готовитесь к экзамену ICA или эксплуатируете Istio в проде - это для вас - НОВОЕ: - курс по Istio для самостоятельного изучения 32 главы, разбитые на две части: • Часть 1 - подготовка к экзамену ICA • Часть 2 - лучшие практики для прода Каждая глава связана с практической лабой - учитесь на деле, а не только на теории. Изучать можно как на русском, так и на английском - 4 новые лабы по Istio: • Лаба 32 - gRPC: балансировка нагрузки по запросам, именование портов, ретраи и таймауты • Лаба 33 - производительность и эксплуатация control plane: discovery selectors, Sidecar scope, golden signals istiod, OPA Gatekeeper • Лаба 34 - защита и модель угроз: STRICT mTLS, default-deny, контроль egress, RBAC для Istio CRD, NetworkPolicy • Лаба 35 - мультикластерный mesh: multi-primary, multi-network, общий CA, east-west gateway, межкластерный discovery ⚙️ Улучшения: • ping_pong теперь работает по gRPC (Echo + Health + reflection) со встроенным gRPC-клиентом / генератором нагрузки • Debug-образы ставят kubectl-k8i через krew с автодополнением в shell; scratch/alpine-образы теперь кросс-компилируются нативно (BuildKit BUILDPLATFORM), а не под QEMU Платформа бесплатная и с открытым исходным кодом. Ставьте звезду, форкайте и учитесь ⭐️ https://github.com/ViktorUJ/cks Отличного настроения и пусть ваш прод живёт без падений! #Istio #ServiceMesh #Kubernetes #SRE #DevOps #CloudNative #ICA #gRPC

⚡️ Linux может читать сетевые пакеты почти напрямую В Linux можно открыть raw socket и увидеть пакеты, которые приходят на сетевую карту. Без Wireshark. Без libpcap. Без лишних инструментов. Пример из скрина делает простую вещь: 1. создаёт socket уровня AF_PACKET 2. просит у ядра все Ethernet-пакеты через ETH_P_ALL 3. в бесконечном цикле читает их через recvfrom 4. печатает размер каждого пакета То есть программа буквально говорит ядру: “Отдавай мне всё, что видит сетевой интерфейс.” И Linux отдаёт. Почему это круто? Потому что так становится понятно, что Wireshark - это не магия. Он тоже получает низкоуровневый трафик от системы, просто красиво его разбирает и показывает. Обычно разработчик работает с сетью на высоком уровне: HTTP → TCP → socket А raw socket позволяет спуститься ниже: Ethernet frame → IP packet → TCP/UDP → payload На таком уровне видно, что реально летит по сети: заголовки, размеры пакетов, служебные данные и весь сырой трафик. Это один из тех примеров, после которых Linux networking перестаёт быть чёрным ящиком.