fix(observability): конфиг Alertmanager читается контейнером — гейт падал на своих же правах (#3078) #3127

Merged

lekss361 merged 1 commit from fix/3078-alertmanager-config-perms into main

2026-08-27 10:01:38 +00:00

lekss361 commented

2026-08-27 09:59:13 +00:00

Owner

Чинит красный деплой метрик, появившийся сразу после #3126.

Что случилось

Как только канал алертов реально включился, профиль alerts впервые дошёл до проверки конфига — и деплой встал:

amtool: error: failed to validate 1 file(s)
Checking '/tmp/am.yml'  FAILED: open /tmp/am.yml: permission denied

Отрендеренный конфиг пишется с правами 600 и принадлежит деплой-пользователю, а amtool и сам Alertmanager в образе prom/alertmanager работают под nobody (65534). Чужой файл 600 они прочитать не могут.

Проверка падала не на содержимом конфига, а на доступе к нему. И это не только про проверку: контейнер после подъёма упал бы ровно там же.

Почему не поймали раньше

Без токена профиль alerts не включался, и эта ветка не исполнялась ни разу с момента появления гейта в #3111. Проверка, которая никогда не запускалась, ничем не отличается от отсутствующей — тот самый класс тихой поломки, ради которого весь стек и заводится. Гейт поймал первым же боевым запуском самого себя.

Решение

Права не ослабляем — в файле лежит токен бота.

chmod 644 решил бы вопрос в одну строку, но внёс бы токен в список файлов, читаемых любым локальным пользователем машины. Вместо этого отдаём файл во владение 65534 одноразовым контейнером от root: passwordless sudo на хосте нет, а бинд-маунт правит host-инод напрямую. Доступ остаётся ровно у того, кто конфиг читает, и ни у кого больше.

Следствие, которое легко проглядеть: после смены владельца > в этот файл на следующем деплое уже не запишет. Поэтому добавлен rm -f перед рендером — каталог принадлежит деплой-пользователю, пересоздать файл он может.

Проверка

Синтаксис YAML разобран. Настоящая проверка — сам деплой: раньше он падал на этом шаге, теперь должен пройти его и поднять Alertmanager. Отпишусь в #3078 с результатом выката и составом контейнеров.

Refs #3078, #3126, #3111

Чинит красный деплой метрик, появившийся сразу после #3126. ## Что случилось Как только канал алертов реально включился, профиль `alerts` **впервые** дошёл до проверки конфига — и деплой встал: ``` amtool: error: failed to validate 1 file(s) Checking '/tmp/am.yml' FAILED: open /tmp/am.yml: permission denied ``` Отрендеренный конфиг пишется с правами `600` и принадлежит деплой-пользователю, а `amtool` и сам Alertmanager в образе `prom/alertmanager` работают под `nobody` (65534). Чужой файл `600` они прочитать не могут. Проверка падала **не на содержимом конфига, а на доступе к нему**. И это не только про проверку: контейнер после подъёма упал бы ровно там же. ## Почему не поймали раньше Без токена профиль `alerts` не включался, и эта ветка не исполнялась **ни разу** с момента появления гейта в #3111. Проверка, которая никогда не запускалась, ничем не отличается от отсутствующей — тот самый класс тихой поломки, ради которого весь стек и заводится. Гейт поймал первым же боевым запуском самого себя. ## Решение Права **не ослабляем** — в файле лежит токен бота. `chmod 644` решил бы вопрос в одну строку, но внёс бы токен в список файлов, читаемых любым локальным пользователем машины. Вместо этого отдаём файл во владение `65534` одноразовым контейнером от root: passwordless sudo на хосте нет, а бинд-маунт правит host-инод напрямую. Доступ остаётся ровно у того, кто конфиг читает, и ни у кого больше. **Следствие, которое легко проглядеть:** после смены владельца `>` в этот файл на следующем деплое уже не запишет. Поэтому добавлен `rm -f` перед рендером — каталог принадлежит деплой-пользователю, пересоздать файл он может. ## Проверка Синтаксис YAML разобран. Настоящая проверка — сам деплой: раньше он падал на этом шаге, теперь должен пройти его и поднять Alertmanager. Отпишусь в #3078 с результатом выката и составом контейнеров. Refs #3078, #3126, #3111

lekss361 added 1 commit 2026-08-27 09:59:14 +00:00

fix(observability): конфиг Alertmanager читается контейнером — гейт падал на своих же правах (#3078 )

CI Trade-In / changes (pull_request) Successful in 10s

Details

CI / changes (pull_request) Successful in 10s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

630f3e6e76

Как только канал алертов реально включился (#3126), профиль alerts впервые
дошёл до проверки конфига — и деплой встал:

    amtool: error: failed to validate 1 file(s)
    Checking '/tmp/am.yml'  FAILED: open /tmp/am.yml: permission denied

Отрендеренный конфиг пишется с правами 600 и принадлежит деплой-пользователю,
а и amtool, и сам Alertmanager в образе prom/alertmanager работают под nobody
(65534). Прочитать чужой файл 600 они не могут. Проверка падала не на
содержимом конфига, а на доступе к нему — и контейнер после подъёма упал бы
ровно там же.

Дефект не поймали раньше по понятной причине: без токена профиль alerts не
включался, и эта ветка не исполнялась НИ РАЗУ с момента появления гейта в
#3111. Проверка, которая никогда не запускалась, ничем не отличается от
отсутствующей — это ровно тот класс тихой поломки, ради которого весь стек и
заводится.

Права не ослабляем: в файле лежит токен бота. Вместо chmod 644 (который внёс
бы токен в список файлов, читаемых любым локальным пользователем машины)
отдаём файл во владение 65534 одноразовым контейнером от root — passwordless
sudo на хосте нет, а бинд-маунт правит host-инод напрямую. Доступ остаётся
ровно у того, кто конфиг читает.

Следствие, которое легко проглядеть: после смены владельца `>` в этот файл
на следующем деплое уже не запишет, поэтому добавлен rm перед рендером —
каталог принадлежит деплой-пользователю, пересоздать файл он может.