Давно хотел посмотреть как оно живется в 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

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

Салют!

Хочу обратить ваше внимание на один аспект и чтобы вы, по возможности, поделились своим мнением, потому что хочется прийти к какому-то новому логическому началу и финальному завершению. Но сперва преабмула, чтобы пояснить текущее положение дел: те из вас, кто всё же читал мой канал, в той или иной степени, могли заметить, что последний пост был в начале лета, а последняя опубликованная статья в привычном формате ещё раньше. Отсутствие какой-либо деятельности связано было с двумя причинами -- загруженность (в меньшей степени) и развитие AI (в большей степени). Ко второму я и сам сильно присосался за последние полгода. Что я имею ввиду и как это с каналом связано? Не то чтобы это хваставство, но мой канал имеет особенность, которая заключается в том, что здесь никогда не было и не будет рекламы (даже если 100500 подписоты налить за наносек -- исключение только личная рекомендация), здесь нет и не будет каких-то безвкусных постов с ссылкой на гитхаб в стиле "о, круто, сам не пользовался, но опубликую пост ради поста", не будет тут и новостного шума, ибо таких каналов и не счесть. Основной смысл канала изначально заключался в самостоятельном написании / создании статей с целью изучения ряда технологий, которые всегда были бы актуальны (насколько это возможно в IT) и при этом оставались бы понятны как новичку, так и тому кто хочет расширить кругозор по той или иной теме. Идея эта зародилась в результате огромного числа мусорного контента на Хабре, Медиуме и т.д. и т.п. Сейчас не буду сильно углубляться в свою неприязнь к этим ресурсам. Дело в другом.

С ростом AI (от ChatGPT до Claude Code в терминале) лично мое число случаев поиска каких-то статей или информации сократилось, не побоюсь этого сказать, почти до нуля. Тут важно отметить, что именно какие-то пользовательские статьи, а не официальная документация того же AWS или ещё чего. Я просто перестал видеть в этом какой-либо смысл, потому что благодаря AI я получаю сразу информацию по делу, и благодаря своему опыту я могу понять, надо мне это или нет или правильно AI что-то сделало или нет. Это я к тому, что могу предположить некое бурление на предмет того, хорошо это или плохо, правильно или неправильно и т.д. Что тот же Claude Code обучился то изначально на статьях в том числе из инета, которые я как бы хейчу. Это все да. Но мне плевать. В моем случае есть инструмент и он позволяет мне быстрее найти готовое решение, а не как раньше. А искать инфу я не очень люблю, ибо при написании тех же статей приходилось перелопачивать говны мегабайтов, чтобы собрать это все во что-то осмысленное и выдать в виде более-менее структурированной статьи. Короче я тупа устал листать гисты и треды с выискиванием того самого решения, а думать самому... ну камон, в 2025 году то. Подключите меня уже как батарейку и отдайте сознание на аутстаф.

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

Итак, спасибо, в первую очередь, всем проголосовавшим и тем, кто оставил комментарий с собственным виденьем ситуации. В общем случае, субъективно, полагал, что % тех, кто полностью подсел на иглу AI будет выше. Изначально я всё же догадывался, что попал в некий пузырь в связи с активным интересом в этом направлении, но хотелось какого-то подтвреждения извне 🙃

В связи с этим хочу провести ещё один и последний на данный момент опрос, в котором было бы неплохо выяснить, о чем интереснее всего вам было бы почитать, если мы рассуждаем в контексте сугубо технически-образовательных статей на этом канале. С сохранением того стиля, развития и разбора технологии от А до Я, как это было в случае с Jenkins, Vault и т.д. Просто мне кажется, что пул технологий или направлений стоит расширить. Или может больше интересны какие-то частные моменты, как в случае с контейнеризацией. В общем любое мнение по данному вопросу приветствуется, потому что в голосовании по пунктам я только обозначу свой приоритет, но в целом к любым вариантам интересным готов.