Хотел опубликовать статью по этой теме гораздо раньше, ещё когда только нашли январскую CVE, но как-то не сложилось и она у меня в незаконченном виде лежала какое-то время. Безопасность не мой основной профиль, поэтому тут уж совсем базовые вещи, но в контексте как защиты, так и нападения на Jenkins. Всё в рамках продолжающегося цикла. Хотя каких-то общих тем для повествования остается всё меньше и меньше, поэтому быть может в скором времени начну ещё один цикл, но уже по другому инструменту в рамках темы CI/CD.

Тут это, решил начать изучение Python и, как и любой уважающий себя питонист, нужно же срочно свой говнокод на Github залить и всем показать какой молодец. Клоун_эмодзи сами себя не проставят. Если серьезно, то пост больше посвящен тем, кто пользуется AWS и управляет инфраструктурой через Terraform или его аналог. И при этом у него множество разных аккаунтов, между которыми часто приходится переключаться. Собственно, сама утилита, хотя я больше сказал бы, что это скрипт в пару строк, который притворяется утилитой. Более подробно о мотивации и т.д. я описал в README. В первую очередь сделал для себя, поскольку у меня именно такая ситуация, когда на дню приходится между разными аккаунтами делать свитч и со временем меня притомило делать это руками. Но может кому тоже будет полезно🫨

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

Итак, возвращаю статью по Vault, которую удалил ранее. Речь о подсистеме секретов Transit и автоматическом распечатывании Vault как такого. И, как уже отмечал, удалил я её тогда потому, что решил кардинально переработать содержимое. Вот повторно публикую первую подчасть, в которой мы поговорим о самом Transit и его базовом использовании как такого. А через пару дней опубликую вторую подчасть.

Прямое продолжение предыдущей статьи в рамках темы Transit Engine в Vault. В этой подчасти мы поговорим непосредственно о том, как с помощью подсистемы секретов Transit настроить автоматическое распечатывание Vault, а также то, как перевести уже проинициализированный Vault из мануального режима распечатывания на уже вышеупомянутый Transit. Ну и по мелочи поговорим о том, когда стоит использовать Transit, почему двухстороннее распечатывание – это плохо и т.д.

В этот раз статья также будет разбита на две подчасти и обе подчасти будут представлять собой, в основном, сугубо теоретиескую составляющую. А речь пойдет о пространствах имен в Linux. Ранее данная тема уже затрагивалась, когда мы говорили о безопасности в Docker, но здесь подробностей чуть больше выйдет. Через пару дней опубликую вторую подчасть.

Вообще перевод из блога Quarkslab's давно уже в сети, поскольку оригинальная статья была опбуликована ещё в 2021 году, но мне хотелось бы иметь на канале свою интерпретацию данного long read.

Прямое продолжение предыдущей статьи в рамках темы пространств имен в Linux. В этой подчасти мы поговорим обо всех оставшихся пространствах имен, которые ещё не были рассмотрены, а в конце разберем пример, как всё это собирать воедино.

Тут это, с Python продолжаю возиться / разбираться, и в этот раз выжал из себя что-то поинтересней, наверное. Короче, кто регулярно следит за моей не самой продуктивной деятельностью, помнит, что относительно недавно (в феврале, лол) я начал цикл статей по Grafana Stack. Там Loki, Promtail и, собственно, сама Grafana. Было опубликовано три части, в которых рассказывается, как можно круто настроить сборку и отправку логов. Так вот, ещё тогда, во время написания статей, пока разбирался с тем да сем, хотелось иметь под рукой какой-то генератор логов, который будет выдавать и так, и сяк, а не просто вот вам запущенный контейнер, вот вам код 200 по курлу, всем спасибо, всем пока. Формат логов разный хочется пощупать в рамках написания запросов с помощью LogQL, уровень логирования пронаблюдать и т.д.

Собственно, вот что из этого вышло. Я не знаю понадобится ли это кому-то ещё, потому что я, как и в случае с тулой для AWS, в первую очередь писал для себя, и мои потребности данная утилита закрывает на все сто. Вообще это затевалось больше с образовательной целью, потому что пока раскуривал Loki, хотелось ну хоть что-то похожее на реальные данные иметь. Может быть в Интернете и есть что-то похожее, может даже лучше. Честно, я не искал, потому что тут совпал принцип «мне это надо и я могу попрактиковаться, пока это делаю».

Для тех кто будет, если будет, использовать её, в README вся необходимая информация есть. Здесь только отмечу, что умеет писать как в std (out и err на выбор), так и в файл в системе, можно выставлять разные уровни логирования, разные форматы логов (JSON, logfmt и т.д.), ну и мелочь всякая, по типу как часто будет генерировать новые сообщения. Даже текст покрасить можно при желании. Есть ещё пару идей по расширению функциональности, но основное, что хотел, сделал. Запускается из коробки как в Docker, так и бинарем можно. И через Python само собой.

А, ну и статьи по Grafana Stack на ревью кину, потому что с тех пор там Loki 3.0 вышел, агента уже сто раз успели поменять переименовать и т.д. И в целом к циклу надо бы вернуться. Такие дела.

Собственно, сама статья, во время которой полыхнуло. Вновь перевод из блога, потому что сохраненки сами себя не разгребут, да и данная тема плотно дополняет мои предыдущие статьи на предмет того, как устроена сеть в Docker. Их также можно найти на канале по этим ссылка: 1 и 2.

Что-ж, после некоторого отсутствия попробую восстановить переодичность своих публикаций. В этой статье хотелось бы рассмотреть тему контейнерных кодов выхода в таких ПО, как Docker и Kubernetes. Местами информация будет повторяться потому, что некоторые коды имеют одинаковый результат выхода вне зависимости от среды использования. Тогда как в других случаях могут присутствовать незначительные отличия. Так или иначе, в рамках Docker я постарался описать всё с теоритеческой стороны, а для Kubernetes – с практической, добавив соответствующие примеры для каждого из кодов.

Какое-то время назад я публиковал статью по тулам для Docker, которые уместны для пользовательского применения. И вообще распинался про рубрику в формате лайт заметок, где можно будет сделать обзор (чуть больше, чем просто ссылка на GitHub) на тот или иной инструмент. Собственно, вот вторая часть. Частично снова про TUI для управления Docker, но есть и пара сторонних инструментов, такие как Hadolint и Dive. Напоминаю про первую часть. В будущем хочу сделать такую же подборку и по другим инструментам, о которых пишу статьи.

Третий день от DeepSeek'а в интернетах прохода нет

1. Задрочили DeepSeek с Тяньаньмэнь и Винни-Пухом

Будто это реально будет влиять на выполнение повседневных задач. Тем более что та или иная цензура есть во всех подобных сервисах.

2. "Злые китайцы собирают наши данные"

Я понимаю, что сливать данные в США поприятнее конечно может быть, но концептуально это ничем не отличается. "Сливать" в Китай может быть даже и лучше, потому что депортаций из третьих стран в Китай я знаю мало, а депортаций в США из третьих стран знаю много.

Открою секрет: если вы реально переживаете за какие-то там свои данные, то вам не надо пользоваться никакими облачными ИИ, кроме selfhosted (и DeepSeek, к слову, можно развернуть локально)

3. Сегодня пошла новая история, про то что дескать всё "украли" у OpenAI. Ну украли и украли.

Даже если так, то будто промышленного шпионажа и подобных вещей до этого не было в истории человечества.

Гореть, соглашаться и несоглашаться можно в комментах ❤️

Давно хотел посмотреть как оно живется в Jenkins, так что сегодняшней темой будет обзор на плагин Amazon EC2 и его возможность создавать агентов прямо из Jenkins. Не думаю, что такой подход много кто использует, потому что как по мне минусов (или сложностей) больше, чем плюсов, но право на своё существование более, чем заслуживает. В общем рассмотрим подготовительный этап, пробежимся по самомум плагину и в конце настроем агента, который будет создаваться прямо по запуску Pipeline и уничтожаться после его выполнения.

Осторожно: у плагина много параметров, так что можно задушиться при прочтении, ведь я сделал описание практически для каждого из них.

Будем считать это промежуточным постом перед следующей статьей. Ранее я неоднократно что-то постил по таким темам, которые посвящены как Docker, так и контейнерам в целом. В частности, некоторые статьи были связаны и с безопасностью в том числе. Вообще при написании той или иной статьи я стараюсь использовать множество различных источников. И так уж сложилось, что пока возился с материалами в контексте вышеупомянутых тем, собралась пачка интересных и не очень, старых и новых, ссылок и статей. Я не любитель публиковать какой-то сторонний пост, скупо предлагая пойти посмотреть, а там ещё и какой-то треш без детального объяснения будет, как этим грешат некоторые. Но подборку в виде одного поста на канале держать удобнее, чем десяток постов в сохраненках за последние N-месяцев 🙂 + предоставленными ресурсами я пользовался (во время написания предыдущих статей) и они действительно хороши в массе своей. В общем пройдемся по пунктам.


Статьи:

1. How does Docker ACTUALLY work? – лонгрид по Docker. В целом +/- то же, что я обозревал в своем цикле статей, но в сжатом виде + больше ссылок на смежные / сторонние темы. Может для кого-то такой формат является более предпочтительным.

2. Docker Security Step-by-Step Hardening – ещё один лонгрид, но уже больше про безопасность и харденинг Docker. Думаю вы видели эту ссылку раньше, так как многие каналы постили её с момента появления. Там поверхностно, но объемно. Рекомендую.

3. Docker Escape – тоже лонгрид в формате тезисной подборки различных сценариев по повышению привилегий в контейнере для последующего побега. Есть ряд доп. ссылок на различные тулы. Некоторые способы уже неактуальны или не так эффективны, но это если вы Docker обновляли регулярно🙃


Сайты:

1. CloudSecDocs – всем (наверное) известный клаудсекдок. Там тезисно, но тоже много всякого понаписано было. И не только по контейнерам. Сейчас вроде как автор подзабил, но полезным от этого ресурс быть не перестаёт.

2. HackTricks Docker Security – огромнейшая Wiki по безопасности в целом, но ссылка ведет конкретно на тему Docker Security. Там очень много информации по Socket, Capabilities, Escape from Containers и вот эти все крутые штучки. Для некоторых статей брал материал непосредственно отсюда.

3. Container Security Site – ещё один очень крутой ресурс, который целиком и полностью посвящен безопасности контейнеров. Как со стороны защиты, так и со стороны атаки + пачка всяких общих моментов. Крайне рекомендую.


Практика:

1. https://github.com/aleksey0xffd/docker-escape – проект на Github с лабами по атакам на контейнеры в контексте использования Capabilities. Под этот репозиторий есть также вебинар от Алексея Федулаева, где он подробно всё рассказывает.

2. https://gitlab.com/invuls/pentest-projects/dockerescapelabs
– ещё один репозиторий по атакам, но за него ничего конкретного сказать не могу, так как не довелось ещё опробовать. Однако README для каждой лабы достаточно вменяемо описано.

3. https://github.com/vulhub/vulhub – тут можно найти различные ПО уязвимых версий, запускаемые в Docker. Смежно с вышеперечисленным, но приемлемо, если вы хотите проэксплуатировать в разрезе контейнерной темы.

4. https://labs.play-with-docker.com – всем известный (во всяком случае не раз видел в смежных каналах) ресурс по практическому изучению Docker. Бонусом идет и ссылка на теорию, где также всё неплохо расписано.

5. https://containerlab.dev/ – это вообще к теме мало относится, но интересный сайт, посвященный запуску сетевых лаб с использованием контейнерных сред. Позволяет определять и запускать виртуальные сети с помощью контейнеров, что упрощает процесс тестирования и разработки сетевых решений. Естественно, что потом это также можно туда-сюда в контексте безопасности.


Есть ещё пачка другая ресурсов по кубам, но его я пока на канале не обозревал в рамках своей шизохронологии, так что повременим с этим 😶‍🌫. Ну и делитесь в коментах, если ещё есть чего на примете у кого.

Так, давненько не было про Vault. Правда в этот раз тема достаточно плевая, но не менее важная. Поговорим про сущности и алиасы, как для юзеров, так и для групп. Всё достаточно тривиально, поэтому без лишних комментариев.

Честно говоря, давно я такую духоту во время написания не испытывал. В какой-то момент даже пожалел, что зашел на территорию безопасников и всего, что с этим связано. Хотя тут ничего такого из ряда вон и не было представлено. В общем в этот раз поговорим про подписание образов: немного теории для начала, а потом обзор на два, как мне кажется, самых популярных или распространенных инструмента для подписи образов (DCT не в счет). Без каких-либо интеграций, потому что сама статья и так вышла больше, чем я планировал, но вот как-то так.

Ранее я как-то публиковал уже цикл статей по упаковке в образ приложений, написанных на Python. Теперь речь дошла и до JS. Конкретно в этой подчасти рассмотрим процесс упаковки для статически собранного приложения, а в следующей – для динамически собранного, если так можно выразиться. И я не так сильно углублялся в разницу между размерами получаемых образов (уже сто раз это было рассказано во всех предыдущих частях), сколько старался сделать упор на самом языке. Хотя не то чтобы с JS я прям много работал, так что какие-то очевидные вещи мог и пропустить.

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

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

1. Ключи, шифры, сообщения: как работает TLS – по праву можно считать даже не лонгридом, а чуть ли не целой книгой по данной теме. Не ручаюсь наверняка, но как мне кажется в нашем сегменте Интернета более подробного описания на русском и не сыскать. Крайне рекомендую, если хотите действительно разобраться в этом вопросе.

2. A Readable Specification of TLS 1.3 – лонгрид уже на английском, в котором акцент больше сделан конкретно на версии TLS 1.3. Можно сказать, что это предвзятая копия оригинального RFC, но со своими дополнениями, картинками и прочим.

3. The Illustrated TLS 1.2 Connection – данный ресурс не про почитать, а про посмотреть. Наглядный пример того, как происходит процесс установления TLS-соединения. Можно сказать, что изображено всё побайтово. Очень полезно, если вы не хотите сидеть в Wireshark и его аналогах.

4. The Illustrated TLS 1.3 Connection – тот же ресурс, только уже про версию TLS 1.3. В остальном всё идентично.

В целом у данного ресурса есть ещё визуализация для QUIC и DTLS, кому интересно – можете ознакомиться. Ну и оставляйте комментарии, если знаете что-нибудь ещё в похожем ключе.

ИИ пишет — мозг молчит: первое исследование с ЭЭГ от MIT доказало, что ChatGPT снижает активность мозга
https://www.ixbt.com/news/2025/06/19/ii-pishet--mozg-molchit-pervoe-issledovanie-s-jejeg-ot-mit-dokazalo-chto-chatgpt-snizhaet-aktivnost-mozga.html

Группа исследователей из MIT Media Lab и нескольких других американских университетов провела первое масштабное исследование, напрямую связавшее использование нейросетей с изменениями в работе мозга и способностью усваивать информацию. Результаты демонстрируют: при написании текстов с помощью ChatGPT мозг активируется заметно слабее, а написанное хуже запоминается. Учёные подчёркивают — речь идёт не просто о корреляции, а о доказанной причинно-следственной связи.

В эксперименте участвовали 54 человека в возрасте от 18 до 39 лет. Все они были носителями английского языка и не имели опыта профессионального копирайтинга. Участников разделили на три группы. Первая писала эссе с помощью ChatGPT, вторая использовала традиционный Google-поиск (без доступа к AI-ответам), третья полагалась только на собственные знания. Темы эссе были близки к тем, что встречаются в тестах SAT, например: «Следует ли измерять успех только через карьеру?» или «Имеет ли неудача ценность?».
. . .
Результаты оказались однозначными. Участники, писавшие с помощью ChatGPT, демонстрировали самую низкую нейронную активность в ключевых областях, отвечающих за внимание, рабочую память и контроль. ЭЭГ фиксировала снижение активности в альфа- и бета-диапазонах, а также уменьшение связности между лобными и теменными участками мозга. В то же время участники, писавшие без помощи нейросети, показывали более активное и устойчивое включение мозга на протяжении всей сессии.

Разница особенно проявилась в четвёртой сессии. Те, кто сначала использовал ChatGPT, а потом писал без него, сохраняли низкую вовлечённость: мозг словно «отвыкал» от работы. Участники хуже запоминали написанное — в среднем только 28% могли воспроизвести хотя бы одно предложение из собственного эссе. У тех, кто всё время работал без ИИ, этот показатель был вдвое выше.
. . .
Исследователи описывают этот эффект как когнитивный долг — уменьшение умственного участия в моменте снижает способность к обучению и формированию устойчивых навыков в дальнейшем. Иными словами, ChatGPT действительно помогает упростить процесс письма, но делает его более поверхностным с точки зрения мозговой активности и долгосрочного запоминания.

Авторы подчёркивают: нейросети — не зло и не угроза, но их регулярное использование требует осторожности, особенно в образовании. «LLM могут быть полезны как поддержка, но не как костыль. В противном случае они ослабляют именно те когнитивные функции, ради которых мы и учимся», — резюмируют исследователи.

Анонс на сайте MIT
Your Brain on ChatGPT
https://www.media.mit.edu/projects/your-brain-on-chatgpt/overview/

Сайт исследования
Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task
https://www.brainonllm.com/

Исследование (положу так же в комменты)
https://arxiv.org/pdf/2506.08872

ЗЫ Жду комментарии про калькуляторы, Гугл, ручки и что там принято ещё писать в таких случаях 🌝