🔥 Наурыз мейрамы құтты болсын!

Поздравляем с праздником Наурыз всё сообщество и ваших родных. Желаем, чтобы ваша проектная инфраструктура процветала, подрядчики радовали, работа приносила удовольствие, а человеческие ценности и знания предков сохранялись.

Пусть изобилие придет в каждую сферу вашей жизни!

С любовью,
@DevOpsKaz 😛

👀 Trivy взломали снова. И на этот раз — серьёзно

Пока мы отдыхали, стало известно: злоумышленники скомпрометировали официальный GitHub Action aquasecurity/trivy-action — тот самый, которым все сканируют уязвимости в CI/CD.

➖ Что произошло

Атакующие форс-пушнули 76 из 77 тегов версий в репозитории. Если ваш workflow ссылается на action по тегу типа @0.34.2, @0.33.0 или @0.18.0 — вы запускаете вредоносный код. Единственный нетронутый тег — @0.35.0.

Малварь выполняется ДО запуска настоящего Trivy, поэтому визуально всё выглядит штатно.

➖ Что делает малварь

Дампит память раннера, ворует SSH-ключи, AWS/GCP/Azure credentials, Kubernetes service account токены. Классический инфостилер для CI/CD окружений.

➖ Масштаб

Более 10 000 workflow-файлов на GitHub ссылаются на этот action. Потенциально — тысячи проектов под ударом.

➖ Что делать прямо сейчас

1. Проверьте, не используете ли вы aquasecurity/trivy-action по тегу (не по SHA)
2. Если да — считайте CI/CD секреты скомпрометированными. Ротируйте AWS ключи, SSH, K8s токены
3. Перейдите на пиннинг по commit SHA вместо тегов — теги можно перезаписать
4. Пересмотрите permissions в GitHub Actions — используйте принцип минимальных привилегий

➖ Главный урок

Это второй инцидент с Trivy за месяц (первый был с VS Code расширением). Пиннинг по версии не защищает — только полный commit SHA. И да: инструмент безопасности сам стал вектором атаки.

@DevOpsKaz 😛

🔥 Безопасность Kubernetes в 2026 году

В феврале 2026 TeamPCP развернула payload, который перечислял поды и namespace'ы, выполнял команды во всех доступных нагрузках и ставил привилегированный DaemonSet для контроля над кластером. 185 серверов подтверждено. Один скомпрометированный под — и весь кластер в ботнете.

При этом главная проблема — мисконфигурации. Мы написали подробное руководство, где разобрали все слои по модели 4C:

⚪️ Cloud — почему 81% EKS-кластеров до сих пор на устаревшей аутентификации, и что проверить в Yandex Cloud / VK Cloud
⚪️ Cluster — RBAC без cluster-admin, Pod Security Admission вместо мёртвых PSP, защита etcd и API-сервера
⚪️ Container — сканирование образов в CI/CD, подпись через cosign, Seccomp-профили, runtime detection через Falco
⚪️ Code — deny-all Network Policy как стартовая точка, секреты через volumes вместо env, mTLS между сервисами

Также внутри 5 YAML-примеров и чеклист из 20 действий по приоритету.

👉 Читать

@DevOpsKaz 😛

🔥 Supply chain атака на LiteLLM: один pip install — и все секреты утекли

24 марта в PyPI были загружены отравленные версии LiteLLM (1.82.7 и 1.82.8). Простой pip install litellm — и с машин сливались: SSH-ключи, креды AWS/GCP/Azure, kubeconfig, git-токены, все переменные окружения (читай — все API-ключи), история шелла, крипто-кошельки, SSL-сертификаты, секреты CI/CD, пароли от баз данных. Пост Andrej Karpathy об этом посмотрели 62 млн (!) раз, так как его ретвитнул Илон Маск.

⚪️ Что произошло

Группировка TeamPCP сначала скомпрометировала Trivy GitHub Action, через него украла PyPI-токен мейнтейнера LiteLLM и опубликовала вредоносные версии. Малварь внедрили через .pth-файл, который выполняется при старте любого Python-процесса — даже если вы не импортируете библиотеку.

LiteLLM — это ~3,4 миллиона скачиваний в день. Но страшнее другое: это транзитивная зависимость. Если ваш проект зависит от dspy, какого-нибудь MCP-плагина или LLM-оркестратора, который тянет litellm — вы тоже под ударом. Вы могли даже не знать, что litellm у вас установлен.

⚪️ Как нашли

Малварь содержала баг: .pth-файл порождал дочерние процессы, которые при инициализации снова запускали тот же .pth, создавая экспоненциальную форк-бомбу, которая роняла машину. Исследователь из FutureSearch заметил, что у него закончилась RAM после обновления MCP-плагина в Cursor. Если бы атакующие не допустили эту ошибку — обнаружение могло затянуться на дни или недели.

Отравленные версии провисели на PyPI около 3 часов. При таком объёме скачиваний — этого более чем достаточно.

⚪️ Что делать

Проверьте: pip show litellm | grep Version. Если видите 1.82.7 или 1.82.8 — считайте машину полностью скомпрометированной. Ротируйте все секреты: SSH, облачные токены, kubeconfig, API-ключи, пароли БД. Проверьте kube-system на подозрительные поды (node-setup-*).

⚪️ Выводы

Это не единичный инцидент — это третий удар в координированной кампании TeamPCP: сначала Trivy, затем Checkmarx KICS, теперь LiteLLM.

Supply chain атаки — самый страшный вектор в современном софте. Каждый pip install может тянуть отравленный пакет из глубины дерева зависимостей. Классическая инженерная мантра «не изобретай велосипед, используй библиотеку» нуждается в переосмыслении. Пинните версии, проверяйте чексуммы, минимизируйте зависимости.

@DevOpsKaz 😛

🔥 Первый спикер Cloud Native Community Day 3 апреля — Мирас Байгашев, DevOps-инженер в Core 24/7

Если вы работаете с Kubernetes, то знаете боль: аннотации Ingress растут, конфиги становятся непереносимыми между контроллерами, а canary-деплой без костылей невозможен. Плюс Ingress NGINX официально уходит в архив — без обновлений безопасности и багфиксов.

Gateway API — это не просто «Ingress v2». Это другая архитектура: разделение ролей между платформой и командами, нативный traffic splitting, поддержка gRPC и TCP без единой аннотации.

Мирас расскажет:

— как устроены сервисы и ингрессы «изнутри»
— какие конкретные проблемы решает переход на Gateway API
— AI трафик: инференс и межагентное взаимодействие через Gateway API

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

👉 Вход бесплатный — регистрация (login to RSVP)

@DevOpsKaz 😛

🔥 Инструмент для диагностики и observability приложений в Kubernetes

Podtrace работает на базе eBPF, «приклеивается» напрямую к указанному поду (или нескольким) и в реальном времени собирает информацию сразу на нескольких уровнях:

⚪️ Ядро и ОС: TCP/UDP-соединения (RTT, ретрасмиссии, состояние), файловые операции (read/write/fsync + пути), page faults, OOM, scheduling, lock contention, syscalls
⚪️ Прикладной уровень: HTTP, DNS, PostgreSQL, MySQL, Redis, Memcached, gRPC, Kafka, FastCGI/PHP-FPM и TLS-handshake. Всё это через uprobes/kprobes без изменения кода
⚪️ Distributed tracing: автоматически вытаскивает trace-контекст (W3C, B3, Splunk) и коррелирует события между сервисами. Можно экспортировать в OpenTelemetry (OTLP), Jaeger или Splunk HEC.

Дополнительно:

➖ Режим diagnose — собирает данные за заданное время и выдаёт красивый summary-отчёт.
➖ Alerting (webhook, Slack, Splunk) с дедупликацией и rate limiting.
➖ Prometheus-метрики + готовый Grafana-дашборд.
➖ Автоматическое обнаружение USDT-точек в бинарниках.
➖ Редактирование PII по regex-правилам.

⚡️ Всё запускается одной командой, без предварительной настройки подов и sidecar’ов.

@DevOpsKaz 😛

🔥 Второй спикер Cloud Native Community Day 3 апреля — Абдухаликов Асир, DevOps Engineer | SRE | Cloud Engineer

Когда начинается отладка сетевых политик в Kubernetes, traffic shaping или мультикластерная связность, у многих появляются вопросы. CNI (Container Network Interface) — это слой, который решает, как поды вообще разговаривают друг с другом. От выбора CNI зависит: видимость трафика, сетевые политики, производительность и то, что вы сможете сделать с сетью завтра.

Асир разберёт:

➖ как CNI устроен изнутри: что происходит между «под запущен» и «pod-to-pod трафик идёт»
➖ почему Cilium — это не просто «ещё один CNI», а другой уровень наблюдаемости и контроля
➖ eBPF под капотом: как Cilium обходит iptables и что это даёт на практике
➖ сетевые политики без боли: L3/L4/L7 в одном месте

Если вы устали объяснять «что происходит в сети» по логам приложения — этот доклад про то, как видеть трафик напрямую.

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

👈 Вход бесплатный — регистрация (login to RSVP)

@DevOpsKaz 😛

🚀 Подкаст про CI/CD — как раз под обед

Что происходит, когда нужно настроить CI/CD для 10 000 разработчиков, которые коммитят в одну ветку и хотят выпускать релизы каждый час? Звучит пугающе. Однако есть люди, которые построили такое и живут с этим каждый день. Подкаст с этими людьми мы и предлагаем.

👈 Слушать подкаст

Про что:

⚪️Почему обычный CI/CD разваливается, когда команда перерастает сотню человек
⚪️Монорепа на десятки тысяч разработчиков — как не скачивать весь мир себе на диск
⚪️Flaky-тесты и почему это враг номер один для доверия к пайплайну
⚪️Зачем нужна своя билд-система и при чём тут виртуальная файловая система
⚪️Агрессивный откат — это не авария, а штатная стратегия
⚪️Что из практик гигантов можно утащить к себе, даже если у вас не миллион серверов

@DevOpsKaz 😛

🔥 Алгоритмы балансировки нагрузки

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

⚪️Round Robin

Запросы идут по очереди: сервер A → B → C → A → ... Подходит, если серверы одинаковые по мощности, а запросы примерно равной длительности. REST API без состояния — типичный кейс.

⚪️Stickу Round Robin

Это Round Robin с памятью. Sticky добавляет привязку: первый запрос от клиента распределяется по Round Robin, но потом все следующие его запросы идут на тот же сервер. Обычно через cookie или IP. Нужно там, где сессия хранится на сервере — старые PHP-приложения, корзины без Redis, любой стейт in-memory. Если такого клиента пустить на другой сервер, он потеряет сессию и вылетит из-под авторизации.

⚪️Weighted Round Robin

То же, что Round Robin, но с весами. Сервер с весом 0,8 получает 80% запросов. Используют при постепенном масштабировании: новый сервер входит с весом 0,1, растёт по мере проверки.

⚪️IP / URL Hash

Клиент по IP-адресу привязывается к конкретному серверу. Пока IP не меняется — пользователь всегда попадает на один бэкенд. Нужен, если сессия хранится in-memory (старые PHP-приложения, некоторые WebSocket-серверы). У URL Hash та же логика, но хэш считается по URL. Полезно для кэширующих серверов: один и тот же URL всегда идёт на один сервер — кэш не дублируется.

⚪️Least Connections

Новый запрос идёт на сервер с наименьшим числом активных соединений. Работает там, где запросы живут по-разному: один занимает 10 мс, другой — 30 секунд. WebSocket-соединения, SSH-туннели — сюда.

⚪️Least Response Time

Трафик направляется туда, где сервер отвечает быстрее прямо сейчас. Балансировщик замеряет latency в реальном времени. Полезно при неравномерной нагрузке: перегретый сервер получает меньше запросов, пока не восстановится.

Для тех, кто хочет изучить тему подробнее, написали статью — рассказали, какие есть виды балансировки нагрузки, каким проектам подходят, как применять.

👈 Читать статью

@DevOpsKaz 😛

🔥 Третий спикер Cloud Native Community Day 3 апреля — Иван Кабанов, Solutions Architect, Yandex Cloud

Тема доклада: О чем мы говорим, когда говорим об Observability

В докладе Иван разберет, что на практике означает Observability и почему классический стек из разрозненных инструментов (Prometheus, лог-агенты, трейсинг) перестаёт справляться с ростом сложности систем. Поговорим про три столпа — мониторинг, логгинг и трейсинг — и как объединение телеметрии в едином контексте помогает быстрее находить причины инцидентов и работать с SLO.

Разберём, как устроена Observability Platform в Яндексе: какие архитектурные решения позволяют работать с метриками, логами и трейсами в одной системе без ручной «склейки», и как выглядит пайплайн сбора и обработки телеметрии на базе OpenTelemetry.

Отдельно обсудим мониторинг AI/LLM-агентов: какие данные попадают в трейсы и как с помощью OpenTelemetry наблюдать поведение агентов — от латентности и ошибок до качества ответов.

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше.

Мест уже нет, но мы обязательно поделимся докладами с сообществом. Следите за новостями — скоро будем делать более масштабные митапы.

@DevOpsKaz 😛

🔥 Какое облако выбрать для бизнеса в Казахстане?

Мы в Core 24/7 провели независимое исследование — и создали гайд, который поможет сориентироваться на рынке облачных провайдеров (отечественных и зарубежных). Заходите, смотрите, сохраняйте в закладки 🫡

👈 Смотреть гайд

Руководство интерактивное — можно выбрать для сравнения 2 или более провайдера или сразу все.

Что внутри:

⚪️Обзор ключевых характеристик
⚪️Сравнение по возможностям и сервисам
⚪️Сценарии применения
⚪️Примерная стоимость

Core 24/7 — сертифицированный партнёр AWS, Azure, GCP, Yandex Cloud, VK Cloud и Oracle Cloud в Казахстане. Мы помогаем бизнесу выбрать облако под их задачу, мигрировать и настроить с максимальной эффективностью.

@DevOpsKaz 😛

🔥 Cloud Native Community Day — уже завтра

Мероприятие пройдёт при поддержке Yandex Cloud Kazakhstan в их алматинском офисе на крыше. Ждем по адресу 3 апреля к 17:00.

Первый спикер — Мирас Байгашев, «Ingress умер, да здравствует Gateway API»

Второй спикер — Абдухаликов Асир, «CNI в Kubernetes, ценность Cilium и как с ним работать»

Третий спикер — Иван Кабанов, «О чем мы говорим, когда говорим об Observability»

⚪️ Расписание:

17:00-17:30 — регистрация гостей + кофе-брейк
17:30-18:10 — спикер 1 + вопросы
18:10-18:50 — спикер 2 + вопросы
18:50-19:30 — спикер 3 + вопросы
19:30-21:00 — афтепати на крыше с пиццей

🎟️ Ждем всех, кто зарегистрировался ранее.

@DevOpsKaz 😛

🔥 Как OpenAI масштабировала систему мониторинга, чтобы справиться с ростом нагрузки

Не устаем повторять, что масштабирование — это не только про инфру, но и про культуру. OpenAI удалось выжить в период взрывного роста благодаря:

⚪️Выбору правильных инструментов
⚪️Жесткой оптимизации
⚪️Отношению к мониторингу как к сервису, который должен быть удобным и эффективным для каждого в компании

Когда ChatGPT стал популярным, OpenAI столкнулась с проблемой: их система мониторинга на базе Prometheus начала давать сбои под весом миллиардов временных рядов (time series).

Что предприняла компания:

➖ Переход на VictoriaMetrics, которая оказалась более эффективной в использовании дискового пространства и ОЗУ по сравнению с альтернативами.

➖ «Наблюдаемость как продукт» помогла команде мониторинга относиться к своим инструментам не просто как к «поддержке», а как к внутреннему продукту для разработчиков.

➖ Если разработчикам сложно строить графики или понимать алерты, система бесполезна. Команда Observability упростила процесс добавления новых метрик, сохранив при этом контроль над их качеством.

➖ Компания осознала, что хранить все данные — слишком дорого и неэффективно. Те метрики, к которым никто не обращался в течение 30 дней, можно безболезненно удалять или перестать собирать.

➖ Использование сэмплирования для логов и трассировок, потому что просто нет нужды сохранять 100% запросов в системе трассировки при таких масштабах. Достаточно сохранять небольшую часть успешных запросов и 100% ошибок.

👈 Читать детальный разбор

@DevOpsKaz 😛

🔥 Новости мира DevOps, которые вы могли пропустить

⚪️ Terragrunt v1.0

Из беты вышел уже популярный open-source инструмент, который представляет собой «тонкую обертку» для Terraform. Terragrunt помогает масштабировать управление IaC, делая код более чистым, поддерживаемым и соответствующим принципу DRY.

⚪️ Tekton стал incubating проектом в CNCF

Это набор готовых инструментов для систем с CI/CD. Tekton помогает строить, тестировать и развертывать в облаках или on-premise. Работает внутри кластеров Kubernetes и не нуждается в физическом сервере.

⚪️ Атака на Trivy — еще не конец

Последствия прошлой атаки все еще ощущаются. Технологические гиганты подвергаются атаке со стороны компрометированного Trivy GitHub Action. На днях злоумышленники похитили исходный код компании Cisco.

@DevOpsKaz 😛

🔥 Вакансия в CORE 24/7 для специалистов технической поддержки (L1-инженеров)

Компания Core 24/7 — лидер в сфере DevOps-аутсорсинга Средней Азии. Мы растем, и для развития первой линии технической поддержки ищем начинающих специалистов. Прокачаетесь на практике — и двери в DevOps станут открыты.

Алматы, офис
Заработная плата: до 200 000 тг.
Можно без опыта
График: сменный (1/3, с 8:00 до 20:00)
Испытательный срок: 3 месяца

❗️ Cамый главный профит — это отличный старт карьеры бок-о-бок с командой, которая делает DevOps для госсектора, стартапов и IT-гигантов Средней Азии.

⚪️Задачи:

• Регистрация и обработка обращений пользователей в системе заявок
• Разрешение инцидентов и поддержка пользователей по регламентам
• Подготовка и ведение документации: инструкции для решения проблем
• Мониторинг дашбордов и управление алертами для выявления критических изменений
• Обработка запросов, эскалация критических инцидентов при необходимости
• Своевременная реакция в чатах и обратная связь клиентам в течение 15 минут

⚪️Требования:

• Базовые знания ОС Linux и администрирования IT-инфраструктуры
• Умение работать в стрессовых ситуациях и принимать решения
• Грамотная устная и письменная речь
• Готовность к сменному графику работы
• Умение быстро находить информацию для решения задач (google, stack overflow, chatgpt)
• Желание обучаться и развиваться

⚪️Приветствуется, но не обязательно:

• Техническое образование (высшее, средне-специальное или среднее).
• Опыт работы с GitLab/GitHub CI/CD
• Знания AWS, Ansible или Kubernetes
• Навыки настройки SSL и работы с сетевым оборудованием

⚪️Мы предлагаем:

• Обучение с нуля и постоянное наставничество
• Программы повышения квалификации в сфере SRE/DevOps
• Сертификацию по ключевым направлениям (Kubernetes, AWS, Red Hat и др.)
• Компенсацию за тренажерный зал
• Премии за успешную работу
• Регулярные тимбилдинги
• Возможности для профессионального и карьерного роста

Если вы хотите расти в ИТ и стать частью команды профессионалов, отправляйте свое резюме. Мы ждем вас!

Писать сюда:

👈 aissabekova@core247.io
👈 @issaika

🔥 Сервер алертов в бинарнике на 23 МБ

Мы знаем, что многие мечтают о self-hosted платформе для алертов и командного общения специально для DevOps/SRE-команд. Готовые решения (Mattermost, Matrix, Gotify, ntfy) требуют слишком много инфраструктуры, либо не дают ACK (подтверждения), либо приходится переписывать ботов под себя.

Представляем Pusk — работает на своём сервере, без внешних зависимостей.

Особенности:

➖ принимает алерты из мониторинга
➖ позволяет их подтверждать одной кнопкой (и автоматически глушит в Alertmanager)
➖ шлёт push-уведомления даже когда браузер закрыт
➖ имеет встроенный командный чат
➖ миграция существующих ботов — буквально одна строка кода.

Pusk сам определяет способ доставки: webhook, relay или очередь getUpdates. Работает и без внешнего интернета. Единственное исключение — Web Push.

В итоге получился алертинг с ламповым чатиком: принял webhook, показал дежурному, дал нажать ACK, коллега принял. Один бинарник, без внешних сервисов, частично совместим с Telegram Bot API (13 методов из 80+).

👈 Посмотреть на GitHub

Пользуйтесь и делитесь с коллегами 🫡

@DevOpsKaz 😛

⚡️ AppSecFest 2026 — крупнейшая конференция по безопасности приложений уже 15 мая

📍 Алматы | Farabi Hub

Уже в третий раз AppSecFest собирает в одном зале инженеров, DevSecOps-практиков, разработчиков и лидеров IT, чтобы говорить о реальных вызовах безопасности и находить решения, которые работают в продакшене.

Что вас ждет:

➖ реальные кейсы DevSecOps и AppSec
➖ разборы атак, уязвимостей и инженерных решений
➖ инструменты и подходы, которые можно внедрить сразу
➖ живое IT-комьюнити и нетворкинг с сильнейшими специалистами рынка
➖ интерактивы и активности на площадке

💥 подарки от партнеров: Derscanner, MUK:IBM, Sonatype, R-team

👈 Зарегистрироваться

@DevOpsKaz 😛

🔥 Инженер-дирижёр: что реально изменилось с приходом ИИ

Компания Диасофт собрала CTO, DevOps-инженеров и операционных директоров — и спросила: что работает, что нет, и в кого превращается инженер. Вот ключевые мысли.

⚪️ ИИ = воодушевлённый джун, который прочитал тонну кода. Типовые задачи можно отдавать смело. Редкие фреймворки, нетиповая архитектура — ИИ тормозит процесс, а не ускоряет.

⚪️ Конвейер важнее модели. Мы отходим от представления «ИИ делает разработку» в сторону «правильной специализированной модели на каждом этапе конвейера». Юнит-тесты — одна модель, документация — другая, расшифровка встречи с заказчиком — третья.

⚪️ Высоконагруженный продакшен лучше не трогать. Для внутренних инструментов, где падение сервисов не позорит нас перед клиентами ИИ меняет многое. Для внешних prod-систем риски пока не оправданы.

⚪️ ИИ про прошлое. Он знает то, что уже было. Инженер нужен, чтобы думать про то, чего ещё нет: закладывать последствия, предугадывать нестандартное поведение, проектировать логику наперёд.

⚪️Порог входа не снизился — сместился. Раньше нужно было уметь писать код. Теперь нужно уметь управлять оркестром агентов: чувствовать, где модель уйдёт в галлюцинации, где срежет угол, где вообще не применима.

⚪️ «Доверяй, но проверяй» — не метафора. Представьте, что автопилот для малой авиации собрали с помощью ИИ — и вроде работает. Поставили бы на самолёт без проверки? Нет. Также и в нашей сфере.

А вот что на эту тему думает Ильяс Мустафин, СТО JetFinance:

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

ИИ съедает всю случайную сложность реализации, но суть задачи и выбор архитектуры никуда не исчезает. Наоборот она становится заметнее и дороже. Потому что вариантов стало больше, а последствия плохих решений наступают быстрее.

И это уже видно в работе. Команды легко генерируют новые фичи, потому что «это легко автоматизировать». А через месяц выясняется, что поддерживать никто толком не готов. Техдолг растет так же быстро, как и объем кода.

@DevOpsKaz 😛

🔥 Доклады с Cloud Native Community Day 3 апреля

3 апреля мы провели четвертый митап в рамках инициативы Cloud Native — готовы поделиться докладами с вами.

⚪️Мирас Байгашев, «Ingress умер, да здравствует Gateway API»
⚪️Абдухаликов Асир, «CNI в Kubernetes, ценность Cilium и как с ним работать»
⚪️Иван Кабанов, «О чем мы говорим, когда говорим об Observability»

Фото с мероприятия здесь.

Следите за новостями — следующий митап уже скоро.

@DevOpsKaz 😛

🔥 Vault: секреты, которые администратор прочитать не может

У HashiCorp Vault есть фундаментальная проблема, о которой редко говорят вслух: администратор может прочитать любой секрет, к которому имеет доступ хоть кто-то ещё. Да, есть аудит-логи. Но только если за ними следят, и только если их не выключили.

Казалось бы, решение простое — хранить конфигурацию доступов в Git, проводить ревью и применять через CI/CD. На практике это иллюзия безопасности:

➖ Администратор GitLab может изменить список апруверов
➖ Владелец репо может сделать force push без ревью
➖ Если CI-система имеет токен на изменение конфигурации Vault, достаточно найти этот токен — и вы внутри

Всегда есть один человек или один сервис, компрометация которого даёт полный доступ.

❗️Есть и правильное решение — Vault умеет управлять собой изнутри.

Вот как работает подход:

⚪️Конфигурация хранится в Git как Terraform-файлы
⚪️Коммиты подписываются несколькими PGP-ключами через Git Notes — это кворум
⚪️Vault-плагин периодически проверяет репозиторий и применяет конфигурацию только если подписей достаточно
⚪️Токен доступа к Vault хранится внутри самого Vault как «неизвлекаемый» секрет — никакой CI его прочитать не может
⚪️State Terraform хранится тоже внутри плагина — никакого внешнего S3 не нужно

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

👈 Плагин — open source
👈 Полная статья с примерами конфига и кода — на Хабре

@DevOpsKaz 😛