CI: проверять ссылки на Secret/ConfigMap и их ключи из манифестов (ловить ссылки на несуществующие источники) #74

New issue

Open

opened 2026-09-20 19:12:39 +00:00 by hermes · 0 comments

hermes commented

2026-09-20 19:12:39 +00:00

(Migrated from git.grachevko.ru)

Зачем

В PR #70 (и затем #73) в hermes был добавлен env HERMES_DASHBOARD_OIDC_CLIENT_SECRET со ссылкой на ключ oidc-client-secret из Secret hermes-oidc. Ключа не существует и не будет: клиент Zitadel создан как User Agent/PKCE, секрет ему не выдаётся. Пока у secretKeyRef стоял optional: true, это молча превращалось в пустую переменную; после правки #73 (optional в схеме чарта нет) та же ссылка блокировала бы старт пода на CreateContainerConfigError. Ошибку нашёл владелец, а не CI.

Это класс ошибок ссылочной целостности: не «значение не по схеме» (это задача #72), а «ссылка на то, чего никто не создаёт». Схема чарта такое не ловит по определению.

Что должно быть

CI валит PR, если манифест ссылается на несуществующий источник/ключ:

env.<KEY>.valueFrom.secretKeyRef {name, key} и env.<KEY>.valueFrom.configMapKeyRef {name, key} — источник с таким именем и ключом должен существовать в репо (Secret/ConfigMap-манифест) или быть одноимённым из ExternalSecret/SealedSecret;
envFrom[].secretRef.name / configMapRef.name — то же;
volumes[].secret.secretName / configMap.name — то же;
для ExternalSecret с явным data: — проверить, что ссылаемые ключи перечислены в его data/dataFrom; для dataFrom.extract источник динамический, проверить нельзя — такие случаи помечать и требовать, чтобы потребляющие ссылки были необязательными, если это возможно.

Критерий готовности

Ветка с secretKeyRef {name: hermes-oidc, key: oidc-client-secret}, у которого нет источника, краснеет в CI.
Ветка с PKCE-конфигурацией (только oidc-client-id) проходит.
Проверка запускается на каждом PR вместе с существующими джобами Flate.

Связано: #72 (валидация values против схемы чарта). Оба чека — часть одного «предполётного» слоя CI, но ловят разные классы: #72 — структуру значений, эта задача — существование объектов, на которые значения ссылаются.

## Зачем В PR #70 (и затем #73) в `hermes` был добавлен env `HERMES_DASHBOARD_OIDC_CLIENT_SECRET` со ссылкой на ключ `oidc-client-secret` из Secret `hermes-oidc`. Ключа не существует и не будет: клиент Zitadel создан как **User Agent/PKCE**, секрет ему не выдаётся. Пока у `secretKeyRef` стоял `optional: true`, это молча превращалось в пустую переменную; после правки #73 (`optional` в схеме чарта нет) та же ссылка **блокировала бы старт пода** на `CreateContainerConfigError`. Ошибку нашёл владелец, а не CI. Это класс ошибок **ссылочной целостности**: не «значение не по схеме» (это задача #72), а «ссылка на то, чего никто не создаёт». Схема чарта такое не ловит по определению. ## Что должно быть CI валит PR, если манифест ссылается на несуществующий источник/ключ: - `env.<KEY>.valueFrom.secretKeyRef {name, key}` и `env.<KEY>.valueFrom.configMapKeyRef {name, key}` — источник с таким именем и ключом должен существовать в репо (Secret/ConfigMap-манифест) или быть одноимённым из ExternalSecret/SealedSecret; - `envFrom[].secretRef.name` / `configMapRef.name` — то же; - `volumes[].secret.secretName` / `configMap.name` — то же; - для `ExternalSecret` с явным `data:` — проверить, что ссылаемые ключи перечислены в его `data`/`dataFrom`; для `dataFrom.extract` источник динамический, проверить нельзя — такие случаи помечать и требовать, чтобы потребляющие ссылки были необязательными, если это возможно. ## Критерий готовности 1. Ветка с `secretKeyRef {name: hermes-oidc, key: oidc-client-secret}`, у которого нет источника, краснеет в CI. 2. Ветка с PKCE-конфигурацией (только `oidc-client-id`) проходит. 3. Проверка запускается на каждом PR вместе с существующими джобами Flate. Связано: #72 (валидация values против схемы чарта). Оба чека — часть одного «предполётного» слоя CI, но ловят разные классы: #72 — структуру значений, эта задача — существование объектов, на которые значения ссылаются.