Интенсив «ИИ-агенты для инженеров» с Артуром Сапрыкиным стартует уже на следующей неделе — собрали ответы на частые вопросы и коротко рассказали, как всё будет

За 9 живых эфиров с Артуром ты разберёшь, как работают автономные coding-агенты — opencode, Aider и Cline, научишься писать собственные MCP-серверы и подключать их к внутренней инфраструктуре, настраивать связку Architect/Editor для экономии на LLM API и генерировать Helm-чарты и Kubernetes-манифесты силами агента. Отдельно разберёте изоляцию AI-процессов в Docker и защиту от Prompt Injection.

Отвечаем на вопросы 👇🏼

🟢 Какой компьютер нужен для интенсива?

Минимум: 8 GB RAM, 20 GB на диске, 4 ядра CPU (x86-64 или Apple Silicon), GPU не обязательна — большинство заданий работают на CPU-инференсе. Из ОС подойдёт macOS 12+, Windows 10/11 с WSL2 или Linux, плюс стабильный интернет для загрузки моделей и работы с облачным агентом.

Комфортный уровень: 32 GB RAM, 40+ GB на диске, 8 ядер или Apple M-series, а для локальных моделей — видеокарта NVIDIA от 8 GB VRAM или Apple M1 и новее.

🟢Нужно ли платить за подписки на нейросети отдельно?

Нет. Все инструменты, которые понадобятся по программе, мы предоставляем сами, а в части заданий будем работать с бесплатными моделями. Доплачивать за доступ к LLM для прохождения курса не придётся.

🟢 Будет ли разбор безопасности?

Да, целый блок посвящён изоляции в Docker, аудиту вызовов и защите от prompt injection.

🟢 Нужен ли опыт работы с AI-агентами до старта?

Нет, интенсив рассчитан на инженеров без опыта именно с агентами. А вот базовые вещи пригодятся: Git на уровне веток и PR, Docker и контейнеризация, понимание CI/CD и Python на уровне простых скриптов.

🟢 Что если пропущу эфир?

Все эфиры записываются, записи остаются у тебя вместе с доступом к чату интенсива — можно посмотреть в своём темпе и задать вопросы Артуру и другим участникам после.

🔥По многочисленным просьбам продлили скидку 10 000 руб. На этой неделе как раз многие решили, что готовы пойти на интенсив. Чтобы дать больше времени на решение, скидка остаётся в силе до 19 июля.

📆Начало занятий — 20 июля
🎁 Скидка 10 000 руб теперь действует до 19 июля. А для участников практикума «LLM для инженеров» дополнительная скидка 3 000 руб.

↘️ Узнать подробности и занять место

✉️ Чтобы получить дополнительную скидку, напиши нашим менеджерам в телеграм, они подробно расскажут о программе и помогут с оплатой.

GitLab CI + Helm: Управление микросервисами

В репозитории 30 микросервисов. Для каждого свой .gitlab-ci.yml. В каждом — по 200 строк повторяющегося кода. Обновление Helm-чарта для нового сервиса — это копирование папки, замена названий и надежда, что ничего не сломается. Деплой в dev, staging и prod — это ручное изменение values.yaml или передача параметров через --set, которые легко забыть.

Знакомая архитектура? Когда микросервисов становится больше десяти, поддержка пайплайнов превращается в отдельную работу. Разработчики начинают копировать конфиги из соседних сервисов, не вникая в детали. В результате в разных сервисах пайплайны ведут себя по-разному, а единого стандарта нет.

Helm добавляет свой слой сложности. Чарты обычно лежат в отдельном репозитории, и обновление версии чарта — это отдельный коммит, который нужно синхронизировать с изменениями кода. Без автоматизации этот процесс ручной и подвержен ошибкам.

🛠Решение - централизация через include

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

Структура центрального репозитория с шаблонами (infrastructure/ci-templates):

.gitlab/
├── templates/
│   ├── build.yml
│   ├── test.yml
│   ├── deploy.yml
│   └── helm.yml
└── jobs/
    ├── build-job.yml
    └── deploy-job.yml

1️⃣ Шаблон для сборки образа (templates/build.yml)

Используем современные правила rules:if вместо устаревших конструкций.

.build_template:
  stage: build
  image: docker:24.0.7
  services:
    - docker:24.0.7-dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_TLS_VERIFY: "1"
# на self-managed раннере в config.toml должен быть volumes = ["/certs/client", "/cache"], иначе клиент не увидит сертификаты и джоба упадёт на TLS. На shared-раннерах GitLab.com это уже настроено.
    DOCKER_CERT_PATH: "/certs/client" 
  script:
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: always

2️⃣ Шаблон для деплоя с Helm (templates/deploy.yml)

.deploy_template:
  stage: deploy
  image: alpine/helm:3.12.0
  script:
    - helm upgrade --install "$CI_PROJECT_NAME" ./chart/ \
        --set image.repository=$CI_REGISTRY_IMAGE \
        --set image.tag=$CI_COMMIT_SHORT_SHA \
        --set environment=$DEPLOY_ENV \
        --namespace $DEPLOY_ENV \
        --create-namespace \
        --wait \
        --timeout 5m
  environment:
    name: $DEPLOY_ENV
    url: https://$CI_PROJECT_NAME.$DEPLOY_ENV.example.com
  rules:
    - if: '$DEPLOY_ENV == "prod" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      when: manual
    - if: '$DEPLOY_ENV == "staging" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      when: on_success

3️⃣ Как теперь выглядит .gitlab-ci.yml внутри микросервиса

Каждый сервис определяет только свои переменные и расширяет (extends) готовые джобы. Обратите внимание на обязательное объявление стадий (stages), включая стадию предварительной подготовки.

include:
  - project: 'infrastructure/ci-templates'
    ref: main
    file: '/templates/build.yml'
  - project: 'infrastructure/ci-templates'
    ref: main
    file: '/templates/deploy.yml'

variables:
  SERVICE_NAME: $CI_PROJECT_NAME

stages:
  - prepare
  - build
  - test
  - deploy

build:
  extends: .build_template

deploy_staging:
  extends: .deploy_template
  variables:
    DEPLOY_ENV: staging

deploy_prod:
  extends: .deploy_template
  variables:
    DEPLOY_ENV: prod

💡Автоматизируем работу с Helm-чартами

Вместо ручного изменения Chart.yaml используем GitLab CI для динамического вычисления версии на основе коммита.

Вариант 🔤: Если чарт лежит внутри репозитория сервиса

Добавляем джобу автоматического обновления версии перед деплоем. Для изменения YAML используем современный синтаксис утилиты yq (v4+).

update_chart_version:
  stage: prepare
  image: alpine:3.18
  variables:
    GIT_DEPTH: 0          # без этого в клоне не будет тегов для git describe
  script:
    - apk add --no-cache yq git
    - |
      RAW=$(git describe --tags --always --dirty 2>/dev/null || true)
      VERSION=${RAW#v}     # убираем префикс v: v1.2.3 -> 1.2.3
      # если тега SemVer-вида нет (только хэш) — берём базовую версию
      if ! echo "$VERSION" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+'; then
        VERSION="0.0.0-${CI_COMMIT_SHORT_SHA}"
      fi
      echo "Chart version: $VERSION"
      yq -i ".version = \"${VERSION}\"" chart/Chart.yaml
    - cat chart/Chart.yaml
  artifacts:
    paths:
      - chart/Chart.yaml

Вариант 🔤: Если чарты хранятся в отдельном общем репозитории

Настраиваем автоматический пуш обновлений в репозиторий чартов. Вместо устаревшего gitlab-ci-token для авторизации в GitLab безопаснее и актуальнее использовать oauth2.

update_helm_repo:
  stage: deploy
  image: alpine/git:2.40.1
  script:
    # HELM_CHARTS_TOKEN — Project/Group Access Token репозитория helm-charts
    # со scope write_repository. Задать в Settings -> CI/CD -> Variables
    # (Masked + Protected). Имя пользователя для такого токена — oauth2.
    - git clone https://oauth2:${HELM_CHARTS_TOKEN}@gitlab.com/infrastructure/helm-charts.git
    - cd helm-charts
    - mkdir -p $SERVICE_NAME
    - cp -r ../chart/* ./$SERVICE_NAME/
    - git config user.email "ci@example.com"
    - git config user.name "GitLab CI"
    - git add .
    # коммитим только при наличии изменений, чтобы не ломать пайплайн пустым коммитом
    - git diff-index --quiet HEAD || git commit -m "Update $SERVICE_NAME to $CI_COMMIT_SHORT_SHA"
    # -o ci.skip, чтобы пуш не запускал бесконечный пайплайн в репозитории чартов
    - git push -o ci.skip origin HEAD:main
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

📌Важно: для кросс-репозиторного пуша CI_JOB_TOKEN не подходит — он даёт клонирование и доступ к API, но не право git push в чужой репозиторий (частичная поддержка появилась только в GitLab 19.1 и требует отдельной настройки allowlist на стороне целевого репозитория). Штатное решение — Project Access Token (или Group/Deploy Token) со scope write_repository, созданный в репозитории helm-charts с ролью не ниже Developer. Токен кладётся в CI/CD-переменную HELM_CHARTS_TOKEN (Masked + Protected). Имя пользователя в URL для access-токена — oauth2 (именно gitlab-ci-token используется только с CI_JOB_TOKEN).

😎 Практический план внедрения

1. Создать отдельный репозиторий для CI-шаблонов. Вынести в него общие этапы сборки, тестирования и деплоя.
2. В каждом сервисе заменить локальный громоздкий .gitlab-ci.yml на подключение шаблонов через include.
3. Унифицировать структуру Helm-чартов во всех сервисах. Использовать общую базу для values.
4. Настроить автоматическое вычисление версии чарта на основе git-тега или хэша коммита.
5. Разделять окружения через переменные: staging деплоится автоматически, а prod — строго вручную через when: manual.

Результат: в каждом сервисе всего 20–30 строк конфигурации вместо 200. Новый сервис добавляется за 5 минут: копируется лаконичный шаблон, меняется название, запускается пайплайн. Изменения в логике деплоя теперь раскатываются на все сотни сервисов одновременно — простым обновлением центрального шаблона.

Хочешь освоить GitLab CI и Helm на практике? 🔥Открывай демодоступы бесплатно🔥:

🔹GitlabCI & Helm & Kubernetes - полный кейс: CI/CD, Helm-чарты, деплой в Kubernetes.
🔹Gitlab CI -пайплайны, артефакты, кэширование, оптимизация и интеграции.
🔹Helm - создание чартов, управление зависимостями, сложная шаблонизация.

Blue Team vs Red Team. Почему защищаться сложнее, чем атаковать

Red Team эффектно закрывает отчёт: нашли SQL-инъекцию, обошли WAF, забрали Domain Admin за два часа. У Blue Team задача менее зрелищная — закрыть 47 критических уязвимостей, 12 из них в проде, и успеть до дедлайна на исправление.

Правило здесь неравное. Атакующему достаточно одной дыры, а защите нужно закрыть все. Практикум BlueTeam учит находить слабые места в инфраструктуре раньше атакующих и защищать то, что уже развёрнуто — контейнеры, Kubernetes, веб-приложения, Active Directory.

В программе:

🟢Настройка безопасного окружения Docker и runtime-мониторинга в Kubernetes с помощью Falco
🟢Автоматизация процессов Vulnerability Management и сканирования инфраструктуры с Nessus/GreenBone
🟢Анализ исходного кода и контейнеров на наличие уязвимостей в CI/CD конвейере
🟢Выявление и эксплуатация уязвимостей веб-приложений из списка OWASP Top 10
🟢Проведение аудита безопасности Active Directory, выявление векторов атак и повышение привилегий
🟢Защита инфраструктуры Active Directory

↘️ Подробнее о программе

Финальный проект

Аудит безопасности гибридной инфраструктуры целиком. Нужно просканировать уязвимости веб-приложения, настроить защиту контейнеров в K8s, найти слабые места в Active Directory и собрать отчёт с планом устранения критических угроз.

Практикум уровня Middle, 65 уроков, 240 часов практики. Понадобятся базовые навыки администрирования Linux и Windows, понимание TCP/IP, DNS и основ Docker.

🎁 До 19 июля действует скидка 10 000 рублей для новых участников

↘️ Купить практикум со скидкой

Если ты сисадмин, DevOps-инженер или начинающий специалист по ИБ и хочешь закрывать дыры быстрее, чем их находят — этот практикум для тебя 🤍

🔥Разбор задачи по траблшутингу "Nginx Reverse Proxy"

Вы её решали — кто-то справился блестяще, кто-то упёрся в стену, а кто-то нашёл неочевидный костыль и задумался: «А правильно ли я сделал?»

Сегодня, 17 июля в 19:00 МСК, мы разберем эту задачу вместе с экспертом, который покажет свой путь поиска проблемы: от первых логов до финального решения.

👨‍💻 Наш эксперт — Юрий Береговой
Senior-разработчик, совмещающий бэкенд на Java/Spring с профессиональным управлением инфраструктурой (Kubernetes, Terraform, Ansible, Jenkins, AWS/GCP) и обожающий нестандартные задачи, где прокачка идёт через реальный опыт.

На вебинаре он:
- покажет 🔥свой собственный процесс диагностики🔥 — как он читает логи, проверяет гипотезы и принимает решения;
- ответит на ваши вопросы в прямом эфире.

🎁 Бонус для участников траблшутинга
Все, кто решал задачу с 9 июня (независимо от результата), получат специальный промокод на скидку.
Просто напишите нашему менеджеру — и он отправит вам промокод. Успевайте!

🎲 И конечно, розыгрыш призов среди всех зарегистрировавшихся — участвуйте и забирайте подарки!

🗓 Когда: Сегодня = 17 июля 2026, 19:00 МСК
🔗 Регистрация обязательна

Приходите — будет не просто полезно, а по-настоящему хардкорно. Увидимся! 👀

В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире.

Урок называется «Основы coding-агентов: архитектура, запуск и первый ReAct-цикл». Разберём, чем автономный агент отличается от обычного автодополнения кода вроде Copilot, и почему это не одно и то же.

На занятии пройдём:

🟢что такое агент и в чём разница между уровнями автономности
🟢анатомию агента и ReAct-цикл: как он рассуждает (Reason) и действует (Act)
🟢установку и первый запуск opencode на чистой машине
🟢управление контекстным окном: лимиты, счётчики токенов, что делать при деградации контекста

После занятия ты будешь понимать архитектурные отличия автономных агентов от систем автодополнения кода, сможешь сам установить и запустить opencode в рабочем окружении и разберёшь логи tool calls в verbose-режиме, чтобы дебажить действия агента.

Практика: разворачиваешь виртуальную машину, ставишь opencode, запускаешь агента в verbose-режиме и поручаешь ему написать Python-скрипт с тестами, а потом разбираешь вывод ReAct-цикла: что агент думал и какие инструменты вызывал.

📆 До понедельника остались считаные дни. Если ещё не занял место, самое время присоединиться.

↘️ Узнать подробности и занять место

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

1️⃣ Введение в протокол IPv6
↘ Регистрация

Время проведения:
21 июля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢IPv6: основные теоретические сведения
🟢Виды IPv6-адресов
🟢Базовая настройка IPv6 на маршрутизаторах Cisco и Eltex

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ Для чего усложнять работу с дисками? Знакомство в LVM
↘ Регистрация

Время проведения:
22 июля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Что такое LVM
🟢Плюсы LVM
🟢Базовая работа с LVM

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

3️⃣ DockerCustom Image
↘ Регистрация

Время проведения:
23 июля 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Кейсы, где свой образ реально помогает: зависимости, утилиты, сертификаты, агенты, базовые настройки
🟢Что класть в образ, а что оставить в env, secrets или runtime-конфигурации
🟢Практика: собираем свой образ, уменьшаем размер через multi-stage build и пушим в registry

Кто ведёт?
Кирилл Ряховский — практикующий DevOps-инженер с 8-летним опытом в инфраструктуре и автоматизации (Linux, K8s, CI/CD, IaC), прошедший путь от системного администратора до разработки.

Анализ логов в реальном времени: От syslog до EFK с фильтрацией

Приложение упало в 2 часа ночи. Разработчик пишет в чат: «Смотри логи». Ты заходишь на сервер, выполняешь kubectl logs — но под уже перезапустился, и логи пропали. В классической инфраструктуре мы привыкли полагаться на локальный syslog или journald, но когда логи разбросаны по десяти разным хостам или сотне эфемерных контейнеров, поиск ошибки превращается в лотерею. Открывать каждую машину по SSH и на ощупь перебирать файлы ротируемых логов с помощью grep и awk — тупиковый путь. Найти баг, который произошел строго между 23:00 и 23:05 на конкретном эндпоинте, в таких условиях практически невозможно.

Централизованный сбор логов решает эти проблемы раз и навсегда. В классическом стеке EFK (Elasticsearch, Fluentd, Kibana) обязанности разделены максимально эффективно:

🔹 Fluentd — собирает, парсит и фильтрует данные;
🔹 Elasticsearch — хранит и индексирует их;
🔹 Kibana — дает удобный UI для поиска и аналитики.

Шаг 1️⃣ Настройка Fluentd и фильтрация

Fluentd запускается как DaemonSet в Kubernetes или как агент на хостах. Он собирает стандартный вывод контейнеров или читает системные файлы.

Вот базовый конфиг, который собирает логи Nginx, парсит их «на лету» и фильтрует, отсекая лишние успешные запросы (200 OK), чтобы не забивать хранилище:

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/nginx/access.log.pos
  tag nginx.access
  <parse>
    @type nginx
  </parse>
</source>

# Фильтруем: исключаем из отправки логи со статус-кодом 200
<filter nginx.access>
  @type grep
  <exclude>
    key code
    pattern /^200$/
  </exclude>
</filter>

<match nginx.access>
  @type elasticsearch_data_stream
  host elasticsearch-service
  port 9200
  # пишем в data stream, а не в датовый индекс. только так работает ILM-rollover
  data_stream_name nginx-logs
  data_stream_template_name nginx-logs
  data_stream_ilm_name logs-policy
  <buffer>
    flush_interval 5s
  </buffer>
</match>

Если приложение сыплет многострочными ошибками (стектрейсами), обычный tail разобьет их на отдельные строки. Чтобы этого не произошло, настраиваем мультилайн-парсер:

<parse>
  @type multiline
  format_firstline /^\d{4}-\d{2}-\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3}) (?<level>[A-Z]+) (?<message>.+)/
</parse>

Для контейнеров обязательно включаем обогащение метаданными Kubernetes. Это добавит в каждый лог контекст: namespace, имя пода и лейблы.

<filter kubernetes.**>
  @type kubernetes_metadata
</filter>

Шаг 2️⃣ Оптимизация Elasticsearch (ILM)

Без управления индексами Elasticsearch быстро съест весь диск, а поиск станет невыносимо медленным. Настраиваем Index Lifecycle Management (ILM) политику, чтобы вовремя перемещать старые данные на дешевые диски и удалять их:

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "0ms",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

PUT _index_template/nginx-logs
{
  "index_patterns": ["nginx-logs*"],
  "data_stream": {},
  "priority": 200,
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-policy",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

🎁 До -30% на ВСЕ практикумы в честь грядущего дня сисадмина

У нас в Rebrain это уже традиция на день сисадмина устраивать распродажи. В этот раз скидка до 30% будет действовать до 28 июля, 23:59 мск. Если давно поглядываешь на практикум и ждёшь повод — вот он.

Самые популярные практикумы сейчас:

🟢 DevOps-инженер [ экономия 48 000 ₽ ]
🟢 Системный администратор [ экономия 40 200 ₽ ]
🟢 Linux Basics [ экономия 22 500 ₽ ]
🟢 Kubernetes (Base + Admin) [ экономия 34 500 ₽ ]
🟢 Linux Advanced [ экономия 27 000 ₽ ]
🟢 Прикладной LLM для инженеров [ экономия 19 500 ₽ ]
🟢 Linux: Анализ производительности и тюнинг [ экономия 9 000 ₽ ]
🟢 Повышение привилегий в Linux [ экономия 7 500 ₽ ]
🟢 Zabbix [ экономия 9 000 ₽ ]
🟢 Container Security [ экономия 9 000 ₽ ]
🟢 Proxmox [ экономия 9 000 ₽ ]
🟢 Patroni [ экономия 9 000 ₽ ]

Скидки действуют и на остальные программы, полный список доступен на платформе или на нашем сайте🤍

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

↘️ Смотреть все практикумы со скидкой

⌚Распродажа будет проходить до 28 июля. Сейчас отличный момент, чтобы разобраться в Kubernetes, подтянуть Linux или освоить новые технологии 🤍

🎁 А при полной оплате скидка увеличивается до 35% - это самый выгодный вариант. Промокод на дополнительную скидку можно запросить у нашего менеджера в телеграм.

Показываем фрагмент первого эфира интенсива «ИИ-агенты для инженеров» с Артуром Сапрыкиным 👀

На видео база, без которой дальше никуда: как LLM вызывает инструменты read, search, shell, edit и git, и что модель получает на каждом шаге: задачу, файлы, историю, результаты вызовов. Отдельно разобрали permissions и compaction: они защищают проект от опасных действий и не дают контексту разрастись до бесконечности.

Дальше больше 🔥

Присоединиться к интенсиву можно и сейчас, запись первого занятия уже открыта участникам.

↘️ Присоединиться к интенсиву

Настройка Network Policies в Kubernetes для изоляции сервисов

Кластер работает, все поды зелёные, приложения отвечают. Потом приходит пентестер или, хуже того, реальный злоумышленник. Оказывается, что любой под в кластере может достучаться до любого другого. База данных, которая должна быть закрыта от внешнего мира, доступна из каждого неймспейса. Redis, который держит кэш пользовательских сессий, можно просканировать из случайного пода-нарушителя.

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

Network Policies решают эту проблему. Это механизм, который позволяет определить, какие поды могут общаться друг с другом, а какие - нет. NetworkPolicy работает на уровне L3/L4 (IP/порты) и фильтрует входящий (`ingress`) и исходящий (`egress`) трафик.

Важный нюанс: NetworkPolicy - это API-объект, спецификацию которого должен принудительно исполнять ваш CNI-плагин. Cilium и Calico - поддерживают политики из коробки. Популярный Flannel - нет. Если CNI не поддерживает NetworkPolicy, вы можете создать сколько угодно таких объектов, но они просто будут игнорироваться.

Первым делом проверяем, какой CNI управляет сетью:

kubectl get pods -n kube-system -l k8s-app=calico-node
# или проверяем наличие Cilium
kubectl get pods -n kube-system -l app.kubernetes.io/name=cilium-agent

1️⃣Главный принцип: Deny by Default
Основной подход при работе с Network Policies - deny by default, allow explicitly (запрещено по умолчанию, разрешено только явно). Вместо того чтобы пытаться точечно блокировать опасные направления, мы сначала закрываем вообще всё, а затем аккуратно открываем нужные доступы.

Создаём политику, которая полностью блокирует весь входящий и исходящий трафик для всех подов в неймспейсе production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # Пустой селектор выбирает ВСЕ поды в данном неймспейсе
  policyTypes:
  - Ingress
  - Egress

podSelector: {} указывает, что правило применяется ко всем без исключения подам в неймспейсе production. А пустые блоки ingress и egress (так как мы их не описали ниже) означают полный запрет.

После применения этой политики поды в production оказываются в полной изоляции. У них перестают работать даже DNS-запросы, потому что это тоже исходящий (`egress`) трафик. Исправляем это.

Шаг 2️⃣: разрешаем DNS-резолв
Добавляем политику, которая позволит подам отправлять DNS-запросы к CoreDNS. Без этого приложения не смогут разрешить имена соседних сервисов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {} # Применяется ко всем подам в production
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
         matchLabels:
           k8s-app: kube-dns

    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Здесь мы используем встроенный системный лейбл kubernetes.io/metadata.name: kube-system. Он автоматически присваивается неймспейсам в Kubernetes, что избавляет нас от необходимости маркировать kube-system вручную. PodSelector позволяет задать конкретный поды с dns и открыть трафик только к ним.


Шаг3️⃣: точечный доступ (Связываем Frontend и Backend)
Теперь разрешаем нашему фронтенду обращаться к бэкенду. Нам нужно настроить Ingress-правило для бэкенда:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080