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

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

Kanalga Telegram’da o‘tish

Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://t.me/s/count0_digest

Ko'proq ko'rsatish
4 748
Obunachilar
+224 soatlar
+97 kunlar
+430 kunlar
Postlar arxiv
Repost from k8s (in)security
CVE-2021-25740 — уязвимость в Kubernetes, которую фактически невозможно полностью исправить патчем (unpatchable), потому что
CVE-2021-25740 — уязвимость в Kubernetes, которую фактически невозможно полностью исправить патчем (unpatchable), потому что проблема заложена в самой архитектуре Kubernetes. Атакующий с правами на изменение Endpoints или EndpointSlices может перенаправлять трафик туда, куда у него обычно нет доступа. Главная опасность в том, что уязвимость позволяет обходить сетевые ограничения и использовать ingress/load balancer как “confused deputy” — доверенный компонент, который выполняет действия от имени злоумышленника. Это превращает даже ограниченные RBAC-права в потенциальный путь к lateral movement внутри кластера. Авторы статьи делают акцент на том, что защититься можно только организационными мерами: жёстким RBAC, admission controllers и мониторингом изменений Endpoints/Services. Очередной хороший пример того, как некоторые проблемы Kubernetes нельзя «закрыть обновлением» — их приходится учитывать как часть threat model всей платформы.

Repost from Data Secrets
Cursor выпустили конкурента GitHub – Origin Репозитории с GitHub можно засинкать напрямую за минуту, также можно создавать репозитории с нуля. Основная идея в том, что Origin должен стать гитхабом для агентов. GitHub архитектурно рассчитан на человеческий темп: один разработчик, одна ветка, PR раз в несколько часов. Агенты же пушат постоянно, и под такой сценарий и делается Origin. Для понимания, Cursor демонстрировали 22.6 коммита в секунду в один репозиторий. Пока никаких фичей для автоматического разрешения конфликтов слияния или обработки параллельных агентов нет, сейчас в продукте только база + привычные агенты. Но есть интересные вещи вроде интеграции Vercel: подключаешь к репе, и каждый PR автоматически получает preview-деплой. https://cursor.com/changelog/origin-code-hosting

Repost from /usr/bin
KEDA как финансовый гардрейл: scale-to-zero, лимиты реплик и автоскейлинг по событиям в Kubernetes В этой статье разбирают KE
KEDA как финансовый гардрейл: scale-to-zero, лимиты реплик и автоскейлинг по событиям в Kubernetes В этой статье разбирают KEDA как практический инструмент для Kubernetes-workloads с непостоянной нагрузкой: очередями, расписаниями, HTTP-пиками и внешними метриками. Материал не про «поставили автоскейлер и сразу сэкономили», а про production-подход: где KEDA действительно помогает, какие параметры нужно ограничивать заранее, как проверять экономику пилота и что может пойти не так при раскатке. @usr_bin_linux

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

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

Repost from DevOps&SRE Library
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 ---

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

Repost from k8s (in)security
Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining
KubesplainingCLI-инструмент для анализа безопасности 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 с выпуском, где вместе с Игор
Спасибо за ваши ответы про отчёты! Ну, и раз уж мы здесь… Возвращаемся в подкаст DevOps Deflope с выпуском, где вместе с Игорем Курочкиным (Enabling.team) разбираем индустрию исследований. Обсудили: • Для кого на самом деле пишут отчёты: для CTO или для работяг. • Почему все отчёты сейчас массово ушли в ИИ-хайп. • Где искать реальные инсайты (спойлер: в поле «Другое»). • И почему лучший способ изучить инструмент — пойти пить пиво с его автором. Слушать: → На любой удобной площадкеНа YouTubeНаш сайт

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

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

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

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

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

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

Repost from k8s (in)security
Небольшое, но важное изменение в 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.