Kubernetes
Кластер забирает секреты штатным оператором
Wardhold не просит ставить свой оператор. External Secrets Operator умеет работать с произвольным HTTP-источником, а наш ответ с самого начала спроектирован под этот контракт — поэтому интеграция это манифест, а не код.
SecretStore и ExternalSecret
apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: wardhold spec: provider: webhook: url: "https://app.wardhold.ru/api/v1/secrets/billing/db/payload" headers: Authorization: "Bearer {{ .token }}" result: jsonPath: "$" secrets: - name: token secretRef: name: wardhold-token key: token
Секрет кластера с токеном обязан нести метку external-secrets.io/type: webhook — это требование оператора, вскрытое реальным прогоном, а не документацией.
Что проверено на живом контроллере
Первичная выдачаработает
Оператор получает плоский JSON и раскладывает пары в обычный Secret кластера.
Ротацияработает
После создания новой версии оператор обновляет Secret по своему интервалу обновления; приложение видит новое значение штатным механизмом кластера.
Аудитработает
Каждое обращение оператора — строка в журнале Wardhold с идентичностью сервисного аккаунта, а не безымянный запрос из кластера.
Что важно настроить сразу
- Отдельный сервисный аккаунт на кластер и роль
payloadViewerтолько на нужные секреты - Короткий срок жизни токена и его замена по расписанию — новая версия секрета с токеном ломает только один манифест
- Интервал обновления подбирается под лимиты запросов: частый опрос десятками ExternalSecret — самый простой способ упереться в них
- Манифесты-примеры лежат в поставке в каталоге
deploy/examples/eso/
Подключаем кластер вместе
Пришлите, как у вас сейчас доставляются секреты в поды, — покажем, что меняется в манифестах и что остаётся как есть.