💻 Helm-чарты “из коробки” упрощают установку, но часто игнорируют безопасность: сервисы могут быть доступны извне без авторизации,что даёт злоумышленникам полный доступ к данным и управлению приложениями.

В статье от Microsoft вы узнаете, как дефолтные конфигурации Helm-чартов для Apache Pinot, Meshery и Selenium приводили к инцидентам. Исследователи призывают проверять конфигурации, мониторить состояние кластеров и не полагаться на установки “по умолчанию”.

#devops #helm #security

Helm исполнилось 10 лет!

🔅Это повод вспомнить, как всё начиналось.

Идея родилась во время хакатона: за полтора дня Мэтт Бутчер создал CLI-утилиту для взаимодействия с Kubernetes, Джэк Норман разработал серверный прототип менеджера пакетов k8space, а Римантас Моцевичюс подготовил первый чарт — набор шаблонов YAML.

19 октября 2015 года был сделан первый коммит. Так появился внутренний проект Helm Classic, который объединили с Google Deployment Manager. После этого появился Helm, знакомый нам сегодня.

За десять лет инструмент прошёл путь от прототипа до полноценной экосистемы с поддержкой:
• чартов (пакетов с шаблонами YAML)
• системы репозиториев и версионирования
• шаблонизации и параметров конфигурации
• управления релизами и откатами
• интеграции в CI/CD

В 2018 году проект вошёл в состав CNCF и продолжил развиваться как одно из ключевых решений для cloud-native инфраструктур.

О названии.
🖼️Выбор был сделан не случайно: helm – «штурвал». Kubernetes казался штормовым морем, а инструмент – помощником в управлении.

Для тех, кто любит погружаться в историю – советуем прочесть очерк сооснователя, путь от альфы до v4 Beta Glory.

Хороших выходных и спокойного дежурства! ⚓️

#devops #kubernetes #helm

От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
⏺Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update

2. Разворачиваем базовое окружение для инфраструктуры:

cub space create infra

3. Устанавливаем Helm-чарт через ConfigHub:

cub helm install --space infra \
  --use-placeholder=false \
  --namespace monitoring \
  prometheus prometheus-community/kube-prometheus-stack \
  --version 79.6.1

• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

⏺Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod
2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

⏺Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

⏺Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only

Prod

cub unit get --space prod prometheus --data-only

Получаем готовый YAML, а не шаблон или переменную.

⏺Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*registry.compromised.com.*'"

Поиск образов

cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*quay.io.*'"

👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops