Как спрятать секреты, внедряя HashiCorp Vault

Выкатываешь релиз, открываешь логи - а там пароль от продовой базы. Или секреты лежат в репозитории, закоммиченные в application.yml. Переменные окружения в CI/CD создают ложное ощущение защищённости: GitLab маскирует их в интерфейсе, но при компрометации раннера все переменные видны в открытом виде.

Статические секреты создают постоянные риски для безопасности. Пароль от базы данных часто не меняется годами, потому что «если поменяем, всё упадёт». И он один на все окружения.

HashiCorp Vault решает эту проблему на уровне архитектуры, полностью исключая человеческий фактор.

Шаг 1. Интеграция с Kubernetes через Agent Injector

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

Добавляем аннотации к поду, и Vault монтирует секреты в его файловую систему:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-example
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "db-app"
        vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/db-app"
        vault.hashicorp.com/agent-inject-template-db-creds: |
          {{- with secret "database/creds/db-app" -}}
          export DB_USER="{{ .Data.username }}"
          export DB_PASSWORD="{{ .Data.password }}"
          {{- end }}
    spec:
      serviceAccountName: app-example
      containers:
        - name: app
          image: app:1.0.0
          command: ["/bin/sh", "-c", ". /vault/secrets/db-creds && ./main"]

⚠️ Важно: Аннотации размещаются строго в spec.template.metadata, а не на самом Deployment. Иначе инжектор просто проигнорирует под.

Медленный старт контейнера
Оптимизация образов Docker и прогон через CI

Сборка пайплайна длится 10 минут, поды стартуют 30 секунд. Образы занимают под гигабайт, каждый новый релиз тянет все зависимости заново. При масштабировании приложение замедляется из-за долгого подъёма контейнеров.

Это следствие неоптимальной сборки образов. Многие используют один Dockerfile, который устанавливает все пакеты, копирует весь исходный код и собирает приложение в одном слое. В результате образ разрастается, слои не кэшируются, каждый запуск требует загрузки гигабайтов из registry.

В CI проблема усугубляется: без кэширования слоёв каждый пайплайн скачивает базовые образы и зависимости заново. Это увеличивает время выполнения и расходует ресурсы.

🛠Решение
Многоступенчатая сборка (multi-stage build) и правильная стратегия кэширования. Разделяем сборку и исполнение: в первой стадии компилируем приложение и собираем артефакты, во второй - копируем только то, что необходимо для работы.

Классический Dockerfile для Go-приложения:

FROM golang:1.26 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
# Флаги -s -w отсекают отладочную информацию, уменьшая бинарник
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o myapp ./cmd/server

# Финальная стадия — distroless содержит ca-certificates и tzdata,
# но не содержит shell и пакетного менеджера
FROM gcr.io/distroless/static:nonroot
COPY --from=builder /app/myapp /myapp
ENTRYPOINT ["/myapp"]

В финальный образ попадает только скомпилированный бинарник и минимальный набор системных библиотек. Размер сокращается с ~800 МБ до ~15 МБ. Под стартует за секунды вместо десятков секунд.

Для интерпретируемых языков (Python, Node.js) принцип аналогичен. Например, для Python создаём виртуальное окружение на этапе сборки, где есть компиляторы для пакетов с C-расширениями, а в финальный образ переносим только готовое окружение без компиляторов и лишнего мусора:

# Стадия сборки. здесь есть компиляторы для пакетов с C-расширениями
FROM python:3.13-slim AS builder
WORKDIR /app
RUN apt-get update && apt-get install -y --no-install-recommends build-essential \
    && rm -rf /var/lib/apt/lists/*
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Финальная стадия. чистый slim без компиляторов
FROM python:3.13-slim
WORKDIR /app
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY app.py .
CMD ["python", "app.py"]

Теперь настраиваем кэширование в GitLab CI, чтобы не пересобирать зависимости при каждом коммите. Воспользуемся современным движком docker buildx, который умеет работать с кэшем напрямую в удаленном реестре (registry) без лишних движений вроде docker pull и docker tag:

stage: build
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
    DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    DOCKER_CACHE: $CI_REGISTRY_IMAGE:cache
  script:
    # Логинимся в registry. без этого не пройдёт ни --push, ни --cache-to
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    # Инициализируем buildx-билдер с драйвером docker-container (умеет писать кэш в registry)
    - docker buildx create --use
    # Собираем образ, читая удалённый кэш и сохраняя новые слои в него же
    - docker buildx build
        --cache-from type=registry,ref=$DOCKER_CACHE
        --cache-to type=registry,ref=$DOCKER_CACHE,mode=max
        --tag $DOCKER_IMAGE
        --tag $CI_REGISTRY_IMAGE:latest
        --push .

Docker проверяет манифест удаленного кэша. Если в Dockerfile не изменились строки, влияющие на слой (например, requirements.txt или `go.mod`), тяжелые этапы установки зависимостей просто пропустятся.

Когда Argo CD не синхронизирует состояние

Развернул приложение через Argo CD, всё зелёное, синхронизация прошла успешно. Через час заходишь - висит статус OutOfSync. Непонятно, кто и что изменил. Вроде бы репозиторий не трогали, но кластер думает иначе.

Или другая ситуация: разработчик запушил изменения, Argo CD их подхватил, но деплой завис, потому что какой-то ресурс уже существует и его нельзя обновить. А на следующий день выясняется, что кто-то из коллег выполнил kubectl apply вручную, и теперь состояние кластера расходится с Git-репозиторием.

🤔 Главная проблема - непонимание источника истины. В GitOps источник истины - это Git-репозиторий. Любое изменение в кластере, сделанное в обход Git, создаёт рассинхрон. Argo CD это видит, но не знает, что с этим делать, если политики не настроены правильно.

🛠Решение - корректная настройка политик синхронизации

Для каждого приложения в Argo CD можно определить, как именно оно должно синхронизироваться с репозиторием. Вот пример конфигурации с тремя ключевыми параметрами:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: false        # Не удалять ресурсы, которых нет в Git
      selfHeal: true      # Автоматически возвращать состояние из Git при дрифте
    syncOptions:
    - CreateNamespace=true

🔹 `selfHeal: true` - самый важный параметр для борьбы с «ручными» правками. Он автоматически возвращает кластер к состоянию, описанному в Git, если кто-то изменил ресурс через kubectl edit или apply. Без этого параметра любое ручное вмешательство оставит приложение в статусе OutOfSync.
🔹 `prune: false` - осторожная настройка на этапе миграции. Мы запрещаем Argo CD удалять из кластера ресурсы, которые не описаны в Git. Это защита от случайной потери данных. Включать prune: true (что является стандартом для честного GitOps) стоит тогда, когда вы полностью уверены в чистоте своих манифестов.
🔹 `- CreateNamespace=true` - опция в syncOptions, которая указывает Argo CD автоматически создать целевой namespace в кластере, если его еще не существует. Избавляет от лишних ручных шагов.

😎Масштабируем подход: паттерн App-of-Apps
Для больших проектов используется паттерн App-of-Apps (приложение приложений). Это подход, при котором одно главное («рутовое») приложение Argo CD управляет набором других дочерних приложений.

Важно: Корневое приложение должно разворачивать дочерние манифесты строго в тот namespace, где работает сам контроллер Argo CD (обычно `argocd`), иначе система их не распознает.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/infra.git
    targetRevision: HEAD
    path: apps/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd  # Обязательно указываем namespace Argo CD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Каждое дочернее приложение в директории apps/ описывается собственным YAML-файлом и может иметь свои уникальные политики. Например, для баз данных можно оставить prune: false, а для легковесного фронтенда - prune: true.

Дополнительно внутри дочерних ресурсов можно использовать Sync Waves (волны синхронизации), чтобы управлять очередью развертывания. Например, сначала гарантированно поднять базу данных, а только потом - зависимый бэкенд:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Ресурсы с меньшим значением волны (включая отрицательные числа) запускаются и проверяются на готовность раньше остальных.

Практический план внедрения
1. Соберите манифесты: определите все ресурсы, которые должны управляться через Argo CD, и перенесите их в Git.
2. Настройте политики безопасности: начните с selfHeal: true и prune: false для продакшена, чтобы защитить данные. На стейдже сразу включайте prune: true.
3. Подключите уведомления: настройте Argo CD Notifications в Slack или Telegram, чтобы мгновенно узнавать о сбоях синхронизации.
4. Внедрите App-of-Apps: централизуйте управление всеми сервисами кластера через один корневой репозиторий.
5. Оптимизируйте Webhooks: настройте webhook от GitHub/GitLab к Argo CD, чтобы синхронизация начиналась мгновенно при пуше, не дожидаясь стандартного 3-минутного опроса (polling).
6. Договоритесь на берегу: обучите команду главному правилу GitOps — никогда не менять ресурсы в кластере напрямую. Только через git commit и git push.

Если нарушить этот принцип, Argo CD либо молча перезапишет ваши изменения (при `selfHeal`), либо оставит кластер в перманентном рассинхроне. Единственный правильный подход: commit в Git, а не apply в консоли.

Чтобы освоить GitOps на практике, включая работу с Helm-чартами, настройку мультикластерного деплоя и управление конфигурациями, 🔥открывай демодоступы бесплатно🔥 и начинай погружаться в технологию:

* Argo CD - установка, настройка, App-of-Apps, интеграция с Helm
* Git - продвинутая работа с репозиториями, ветвление, стратегии слияния
* Helm - создание чартов, управление зависимостями, шаблонизация

route:
  group_by: ['alertname', 'namespace']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: default
  routes:
  - matchers:
    - severity = critical
    receiver: pagerduty
  - matchers:
    - severity = warning
    receiver: slack

receivers:
- name: default
- name: pagerduty
  pagerduty_configs:
  - routing_key: <your-routing-key>
- name: slack
  slack_configs:
  - channel: '#alerts'
    api_url: <webhook-url>

Важный момент - группировка. Параметр group_by: ['alertname', 'namespace'] объединяет похожие алерты в одно компактное уведомление. Вместо десяти отдельных сообщений в Slack о том, что разные поды упали в одном сис-окружении, вы получите всего одно емкое оповещение.

Также не забывайте про Inhibition rules (правила взаимоподавления). Если узел (`NodeNotReady`) стал недоступен, все алерты о падении конкретных подов на этом узле должны подавляться автоматически. Нет никакого смысла читать спам о смерти пяти контейнеров, если упал весь сервер, на котором они были запущены.

Практический план внедрения
1️⃣ Установить kube-prometheus-stack через Helm с кастомным values-файлом.
2️⃣ Отключить или переопределить избыточные стандартные правила, оставив только критический минимум. Добавить свои правила через additionalPrometheusRulesMap.
3️⃣ Настроить recording rules для тяжёлых графиков, которые выводятся на главные экраны.
4️⃣ Сконфигурировать Alertmanager: задать маршрутизацию по severity, настроить группировку и правила подавления (inhibition).
5️⃣ Подключить каналы уведомлений (`receivers`): Slack/Telegram для предупреждений, PagerDuty или Opsgenie — для ночных критических звонков.
6️⃣ Включить нотификации в тестовом режиме на пару дней и откалибровать пороги срабатывания.
7️⃣ Постепенно добавлять новые алерты, но только тогда, когда старые перестали давать ложные срабатывания.

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

🔥Открывай демодоступы бесплатно и начинай разбираться:
🔹 Kube Prometheus Stack - полный стек мониторинга на практике: Prometheus, Alertmanager, Grafana, ServiceMonitor, PrometheusRule.
🔹 Grafana - визуализация, продвинутые дашборды, алертинг и интеграции.