🟡 Анонс открытых практикумов на следующую неделю

⚫ Открытый практикум Networks by Rebrain: Система аутентификации, авторизации и учета на сетевом устройстве

↘ Регистрация

Время проведения:

2 декабря (вторник) в 19:00 по МСК

Программа практикума:

🟢AAA: основные теоретические сведения
🟢Настройка локальной аутентификации
🟢Role-Based CLI Access

Кто ведёт?
Андрей Шабалин — тренер Cisco/Huawei, кандидат наук, преподаватель сетевых технологий на онлайн-платформах, инструктор академии Eltex и Астра-Университета. Автор сообщества «Компьютерные сети и сетевая безопасность»

⚫ Открытый практикум Linux by Rebrain: Кластер PostgreSQL

↘ Регистрация

Время проведения:

3 декабря (среда) в 20:00 по МСК

Программа практикума:

🟢etcd
🟢etcd, как добавить ноду в кластер
🟢Patroni
🟢Настраиваем кластер PostgreSQL

Кто ведёт?

Андрей Буранов — системный администратор в департаменте VK Play. 13+ лет опыта работы с ОС Linux. 11+ лет опыта преподавания. Входит в топ-3 лучших преподавателей образовательных порталов.

⚫ Открытый практикум DevOps by Rebrain: Kubernetes: Custom Resource Definition

↘ Регистрация

Время проведения:

4 декабря (четверг) в 19:00 по МСК

Программа практикума:

🟢Как работает API в Kubernetes и что такое ресурсы?
🟢Создаем свой кастомный ScheduledCommand
🟢Описываем контроллер для работы с этим ресурсом

Кто ведёт?

Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.

🤍 После регистрации на любой вебинар мы отправим вам подарок! Вы сможете найти его в ответном письме.

✉ Также у нас есть открытое комьюнити, где мы собрали много специалистов по инфраструктуре, готовых помочь и поделиться опытом. Задать вопрос коллегам и разобраться в сложных задачах можно по ссылке!

Новое видео на YouTube-канале и в VK Видео ➕

Сегодня подготовили для вас запись практикума по DevOps с Василием Озеровым —
«DevOps by Rebrain: Docker Swarm»

Василий — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.

В новом видео:

🟢Развернем собственный Swarm-кластер
🟢Изучим основные ресурсы Docker Swarm и развернем приложение в кластере
🟢Настроим маршрутизацию трафика с помощью Traefik

Выбирайте удобную площадку и прокачивайте свои навыки:

↘ Смотреть на YouTube
↘ Смотреть в VK Видео

Автоматизация и нейросети «убьют» сисадминов? 😱

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

Но вот реальность: настоящего сисадмина не заменит ни один инструмент.

↘️ Почему?

🟢Автоматизация не пишет архитектуру — её придумывают люди.
🟢Нейросети подскажут решение, но не возьмут на себя ответственность за прод.
🟢Даже самый умный скрипт не поймёт контекст бизнеса, риски и нюансы инфраструктуры.

Автоматизация и ИИ — это не враги, это усилители. Они не «убивают» профессию, а поднимают планку.
А те, кто умеет с ними работать, становятся самыми востребованными специалистами.

↘️ Хочешь быть среди тех, кого точно не заменят?
Обучайся в Rebrain — и становись профессионалом, которому доверяют прод и будущее компании.

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Резервное копирование и работа с файловой системой на сетевом оборудовании

↘ Регистрация

Время проведения:

9 декабря (вторник) в 19:00 по МСК

Программа практикума:

🟢Протоколы передачи данных: основные теоретические сведения;
🟢Обновление и создание резерных копий;
🟢Создание архивов и сравнение конфигурационных файлов.

Кто ведёт?
Андрей Шабалин — тренер Cisco/Huawei, кандидат наук, преподаватель сетевых технологий на онлайн-платформах, инструктор академии Eltex и Астра-Университета. Автор сообщества «Компьютерные сети и сетевая безопасность»
---------------------------------------------------------------------------------------

2️⃣ DRBD (Distributed Replicated Block Device)

↘ Регистрация

Время проведения:

10 декабря (среда) в 20:00 по МСК

Программа практикума:

🟢Задачи DRBD
🟢На каком уровне работает DRBD?
🟢Натройка DRBD
🟢Возврат ноды после Split Brain

Кто ведёт?

Андрей Буранов — системный администратор в департаменте VK Play. 13+ лет опыта работы с ОС Linux. 11+ лет опыта преподавания. Входит в топ-3 лучших преподавателей образовательных порталов.
---------------------------------------------------------------------------------------

3️⃣ Сложный коллега: как распознать и остановить скрытый саботаж/токсичность, вернуть команде продуктивность работы

↘ Регистрация

Время проведения:

11 декабря (четверг) в 19:00 по МСК

Программа практикума:

🟢Как распознать токсичность в зародыше — от вечного нытика до тихого саботажника.
🟢Что делать, если коллега постоянно саботирует ваши инициативы, и как перевести его деструктивную энергию в конструктивное русло.
🟢Как провести сложный разговор без скандалов — простая схема из 3 шагов, которая работает даже с самыми несговорчивыми сотрудниками.
🟢Когда стоит бороться за сотрудника, а когда — решиться на увольнение.
🟢 Красные флаги, после которых шансов на исправление нет.
🟢 Почему рядовому сотруднику не нужно молчать — конкретные фразы и техники, чтобы защитить себя и проект без конфликта с коллегой.
🟢Как создать среду, в которой токсичности просто не будет места, — профилактические меры, которые сэкономят вам нервы и время.

Кто ведёт?

Елена Фролкина - лидер с 15-летним опытом построения и управления командами в лидерах рынка и стартапах
---------------------------------------------------------------------------------------

4️⃣ Keycloak Oauth2: Подключение Kubernetes

↘ Регистрация

Время проведения:

12 декабря (пятница) в 19:00 по МСК

Программа практикума:

🟢Подключаемся к Kubernetes через openid-connect.
🟢Настраиваем политики доступа.
🟢Врубаем и проверяем аудит логи.

Кто ведёт?

Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
---------------------------------------------------------------------------------------

✉ Также у нас есть открытое комьюнити, где мы собрали много специалистов по инфраструктуре, готовых помочь и поделиться опытом. Задать вопрос коллегам и разобраться в сложных задачах можно по ссылке!

Привет! 👋
Тот момент, когда делаешь коммит и идешь пить кофе☕️, потому что пайплайн будет идти 15 минут ⌛ — знакомо?

🚴‍♂️Скорость CI — это не просто цифры. Это твое время, фокус и нервные клетки. Медленный пайплайн убивает поток, заставляет контекстно переключаться и просто бесит.

В 90% случаев тормоза — из-за неправильного кеширования. Не тех зависимостей, не там и не так.

💡 Вот как это исправить за 5 минут:

1️⃣ Раздели кеш для зависимостей и сборки

cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/  # или .m2/, vendor/ и т.д.
  policy: pull-push  # загружаем И обновляем

2️⃣ Используй разные ключи для разных веток

variables:
  CACHE_KEY: $CI_COMMIT_REF_SLUG

cache:
  key: ${CACHE_KEY}
  paths:
    - .gradle/caches/

3️⃣ Настрой политику pull для тестов

test:
  stage: test
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
    policy: pull  # только загружаем, не обновляем!
  noscript:
    - npm test

Почему это работает:
• Зависимости скачиваются один раз, а не на каждом запуске
• pull-push на этапе сборки обновляет кеш при изменении зависимостей
• pull на этапе тестов экономит время на запись кеша

Простой чек-лист для твоего пайплайна:
✅ Зависимости кешируются отдельно от артефактов
✅ Используешь policy: pull где можно
✅ Ключ кеша учитывает версии зависимостей (например, хэш package-lock.json)

А если хочешь по-настоящему глубоко разобраться в кешировании, артефактах и оптимизации пайплайнов — приходи практиковаться наш курс по GitLab CI. Там разбираем не только лайфхаки, но и как проектировать пайплайны, которые не тормозят с самого начала.

Оставим ссылку на покупку со скидкой 3000 рублей. Она действует до 9 ноября.

Твой пайплайн все еще идет 15 минут?

Привет! 👋

Знакомо: делаешь новую фичу в отдельной ветке, а проджект или тестировщик просит: «А можно 👀глянуть👀 вживую?». И начинается ад:

🔹«Подними на тестовом» → нужно мержить, конфликты, ждать
🔹«Дай доступ к локальному» → настраивать окружение, порты, зависимости
🔹«Скинь скриншоты» → не показывает реальное поведение

🔥 Есть способ лучше 🔥
Review Apps в GitLab — это временные окружения, которые создаются автоматически для каждой ветки и умирают после мержа. Как облачный стенд, который живет ровно столько, сколько нужно.

Вот как это настроить. Без магии, просто копируй:

review:
  stage: deploy
  noscript:
    - echo "Деплоим ветку $CI_COMMIT_REF_SLUG на временный сервер"
    # Твои команды деплоя (kubectl, docker-compose, ansible)
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.your-app.com
    on_stop: stop_review  # что запустить при удалении
  rules:
    - if: $CI_MERGE_REQUEST_ID  # Только для MR

stop_review:
  stage: cleanup
  noscript:
    - echo "Удаляем окружение review/$CI_COMMIT_REF_SLUG"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual  # или automatic для автоудаления

💡Что происходит:

1️⃣ Создаешь Merge Request → пайплайн сам поднимает окружение
2️⃣В MR появляется кнопка с ссылкой на твое живое приложение
3️⃣ После мержа (или вручную) окружение автоматически чистится

Зачем это тебе:
• Показываешь работу клиенту/ПМ/тестировщику без лишних телодвижений
• Тестируешь в реалистичных условиях, а не «на локалке»
• Экономишь ресурсы — окружения живут только когда нужны
• Автоматизируешь рутину — не нужно руками что-то поднимать и чистить

Это не сложно.
Если уже умеешь деплоить приложение (хоть в Docker, хоть на сервер), то добавить Review Apps — дело 15 минут ⏰ конфигурации.

А если хочешь научиться не просто копировать конфиги, а понимать как проектировать такие пайплайны — приходи на курс по GitLab CI. Научим делать не только Review Apps, но и полноценные staging/prod окружения с безопасностью и мониторингом.

Если было полезно, то ставь 🔥

Хей, ребята! 🖖

Часто вижу в проектах JWT как стандарт для аутентификации. Токен есть, но мало кто смотрит, насколько он действительно защищён.

😳 А зря 😳
Потому что типовые ошибки в JWT — это прямая дорога к компрометации аккаунтов.
Не верите?

Давайте проверим ваш токен прямо сейчас.

📌 Шаг 1: Смотрим, что внутри
JWT состоит из трёх частей: header.payload.signature. Просто вставьте свой токен на сайт jwt.io или в расширение DevTools — и сразу увидите:
1️⃣ Алгоритм подписи (alg)
2️⃣ Данные пользователя (payload)
3️⃣ Срок действия (exp)

📌 Шаг 2: Ищем опасные признаки
1️⃣ Алгоритм "none" — самая грубая ошибка. Если в header видите "alg": "none", токен можно подделать, просто удалив подпись.
2️⃣ Слабый секрет — если ключ подписи простой (типа "secret123"), его можно подобрать брутфорсом. Проверить можно через hashcat или онлайн-инструменты.
3️⃣ Отсутствие проверки alg — сервер может принимать любой алгоритм. Попробуйте сменить RS256 на HS256 в header — иногда это срабатывает.

📌 Шаг 3: Практика в Burp Suite
1️⃣ Перехватите запрос с токеном в Burp
2️⃣ Отправьте токен в Decoder
3️⃣ Модифицируйте payload (например, поменяйте "user": "user" на "user": "admin")
4️⃣ Если подпись не проверяется — вы только что нашли уязвимость

Что делать, если нашли проблему?
↘ Никогда 🚫 не используйте алгоритм "none" в продакшене
↘ Генерируйте сложные секреты длиной от 32 символов
↘ Всегда проверяйте алгоритм подписи на сервере
↘ Используйте короткое время жизни токенов (exp)

⚠️P.S. Эта проверка — только верхушка айсберга⚠️
Если хотите не просто находить уязвимости, а понимать их природу и думать как атакующий — смотрите наш практический курс по безопасности веб-приложений.

На курсе разберём:
🔹 Полный цикл пентеста — от разведки до отчёта
🔹 Все уязвимости OWASP Top 10 на реальном стенде OWASP Juice Shop
🔹 Работу с Burp Suite на продвинутом уровне
🔹 Методы защиты на уровне архитектуры, а не просто "заплатки"

🗓Старт: 22 декабря
Подробная программа

Проверили свой токен? 🔍

Знакомо ощущение, когда открываешь Burp Suite и теряешься в сотне вкладок? Интерфейс выглядит как кабина пилота, а времени на полноценный пентест нет.

В таких случаях не пытайтесь изучить всё.
Фокус на трёх ключевых функциях, которые решат большинство задач по безопасности веба — от быстрой проверки до поиска критических уязвимостей.

🎯 1. Intercept — видеть всё, что уходит в сеть
Зачем: понимать, что на самом деле отправляет ваше приложение.
Что делать:
1. Включите перехват (Intercept is on)
2. Выполните действие в браузере (логин, поиск)
3. Смотрите "сырой" запрос: куки, заголовки, параметры
⭐️Фишка: меняйте любые параметры на лету. Хотите проверить, что будет если передать user_id=1 вместо user_id=2? Просто отредактируйте и нажмите Forward.

🔁 2. Repeater — тестировать одну точку снова и снова
Зачем: глубоко проанализировать конкретный эндпоинт.
Что делать:
1. Перетащите перехваченный запрос из Intercept во вкладку Repeater
2. Меняйте параметры, заголовки, тело запроса
3. Нажимайте Send и сравнивайте ответы
💡Практический кейс: Проверка на SQL-инъекцию. Добавляете ' или " в параметры и смотрите — не вернулась ли ошибка базы данных в ответе?

⚡ 3. Active Scan — автоматический поиск уязвимостей
Зачем: пусть Burp поработает за вас, пока вы занимаетесь другими задачами.
Что делать:
1. Кликните правой кнопкой по запросу в Proxy → Send to Scanner
2. Выберите Active Scan
3. Через 10-15 минут проверьте вкладку Dashboard → Issue activity

🔥 Что найдёт: XSS, SQLi, уязвимые заголовки, проблемы с CORS, пути к файлам — всё, что можно обнаружить автоматически.

📌 Краткий алгоритм на 10 минут:
1️⃣ Настройте прокси в браузере на 127.0.0.1:8080
2️⃣ Включите Intercept, сделайте действие в приложении
3️⃣ Изучите запрос — нет ли в нём чувствительных данных
4️⃣ Отправьте в Repeater подозрительные эндпоинты
5️⃣ Запустите Active Scan на самый интересный запрос

Этих трёх инструментов достаточно, чтобы провести базовую проверку безопасности за чашку кофе☕️.
Burp Suite — это не только для хакеров, это практичный Swiss Army Knife для инженера, который хочет быть уверен в своём коде.

P.S. Хотите не просто пользоваться инструментами, а понимать, как искать уязвимости системно? Наш курс по безопасности веб-приложений — это не про запоминание кнопок в Burp, а про мышление пентестера.

Старт: 22 декабря

А какими функциями Burp Suite пользуетесь вы чаще всего?

👀 С этими 5 ошибками в GitLab CI сталкиваются все 👀

🔥Разбираем, почему они возникают и как их решать раз и навсегда

Если работаешь с GitLab CI, ты точно знаешь эти боли. Вместо того чтобы гуглить каждый раз, давай разберемся, почему они случаются и как исправить их системно.

1️⃣ «Runner зарегистрирован, но джобы висят в stuck»
Что происходит: Создал раннер, а пайплайн не стартует. В интерфейсе This job is stuck.
Почему так: GitLab отправляет джоб только на раннеры с подходящими тегами. Если в джобе tags:[docker], а у раннера тег linux, они не встретятся.

💡Как решить:
↘ Проверь теги раннера: gitlab-runner list
↘ В .gitlab-ci.yml укажи те же теги в джобе
↘ Убедись, что раннер в статусе active (не paused)
🧠 Системный подход: Пойми механику tags как систему маршрутизации и сможешь проектировать инфраструктуру под разные типы задач.

2️⃣ Docker-in-Diner: connection refused
Что происходит: Пытаешься собрать Docker-образ внутри CI, но получаешь Cannot connect to the Docker daemon.
Почему так: Докер внутри контейнера (DinD) требует особых прав и переменных окружения.

💡Как решить:

services:
  - name: docker:dind
    alias: docker
    command: ["--tls=false"]
variables:
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""

↘ Плюс не забудь добавить privileged: true в конфиг раннера при регистрации.
🧠 Системный подход: Пойми разницу между изолированными окружениями и научишься выбирать подход (DinD, Kaniko, Socket) под задачу.

3️⃣«Кеш не работает, зависимости качаются каждый раз»
Что происходит: Вроде настроил кеширование, но npm install или go mod download выполняются каждый раз с нуля.
Почему так: Ключ кеша меняется при каждом коммите (например, $CI_COMMIT_SHA), поэтому GitLab не находит старый кеш.

💡 Как решить:

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

Для кеширования зависимостей лучше использовать хэш lock-файла:

cache:
  key: $CI_COMMIT_REF_SLUG-$CI_PROJECT_DIR/package-lock.json

🧠 Системный подход: Научись проектировать стратегии кеширования, понимать lifecycle кеша и экономить часы времени сборок.

4️⃣ Секрет случайно попал в логи
Что происходит: В логах пайплайна видишь свой $DEPLOY_TOKEN или другой секрет.
Почему так: GitLab не может автоматически маскировать секреты, если они попадают в stdout.

💡 Как решить:
↘ Создай переменную в Settings → CI/CD → Variables с флагами Masked и Protected
↘ Никогда не делай echo $TOKEN — вместо этого проверяй наличие: if [ -n "$TOKEN" ]; then echo "Token is set"; fi
↘Используй set -euo pipefail для отладки, но затем убирай

🧠 Системный подход: Разберись с практиками безопасной работы с секретами, поймешь, как GitLab обрабатывает переменные под капотом.

5️⃣ «У меня локально работает, а в CI падает»
Что происходит: Тесты проходят на локальной машине, но в пайплайне валятся с ошибками подключения.
Почему так: В CI сервисы доступны не по localhost, а по своим сетевым алиасам.

💡 Как решить:

services:
  - postgres:14
  
test:
  noscript:
    - PGHOST=postgres psql -U postgres -c "SELECT 1"  # не localhost!

🧠 Системный подход: Научись проектировать воспроизводимые окружения и поймешь принципы контейнерной сети в CI.

------------------------------
Эти 5 проблем — симптомы. Корень — в непонимании как GitLab CI работает изнутри.

На курсе GitLab CI мы учим не просто «как исправить», а:
🔹 Предсказывать проблемы до их появления
🔹 Строить ментальную модель работы пайплайнов
🔹 Принимать инженерные решения — какой подход выбрать под задачу
🔹 Отлаживать системно — от чтения логов до анализа архитектуры

Стартуем 22 декабря. Подойдет, если уже работаешь с веб-проектами и хочешь прокачать автоматизацию.
До 10 декабря включительно цена 22 000 рублей потом 25 000.

По ссылке можешь купить программу.

🏁 ДЕНЬ СТАРТА: ПОГНАЛИ РЕШАТЬ! БЕСПЛАТНО!

Сегодня 10 декабря! Пора закатать рукава и погрузиться в детали сломанного Systemd.

Переходите на страницу траблшутинга → регистрируйтесь, если не успели → и начинайте решать!

Ваша задача уже ждёт:
1. Нужно разобраться, почему Go-приложение отказывается работать как служба, хотя вручную — всё запускается.
2. Где та самая коварная строчка в конфиге? Где прячется проблема с правами или изоляцией?

❗️❗️❗️ Что делать прямо сейчас: ❗️❗️❗️
↘Внимательно изучите условие задачи - вот прямая ссылка на задачу, если уже зарегистрировались. Все детали и подсказки уже там.
↘Приступайте к диагностике. Проверяйте логи, анализируйте юнит, тестируйте гипотезы.
↘У вас есть 5 дней — до 15 декабря включительно — чтобы найти решение и отправить его.

🔥 А 15 декабря Василий Озеров проведёт подробный разбор задачи:
✅ Покажем правильное решение и все шаги диагностики.
✅ Объясним ключевые ошибки и как их избежать.
✅ Ответим на ваши вопросы по решению.

Не откладывайте! Самые интересные инсайты часто приходят в процессе глубокого копания.