M
Make. Build. Break. Reflect.
@makebreakreflect1.2K подп.
3.6Kпросмотров
24 февраля 2026 г.
Score: 4.0K
#aws #rds #troubleshooting Приходят как-то коллеги, говорят - нет прав включить Enhanced Logging на RDS Proxy. Для дебага очень надо на пару часов. Ок, смотрю политику, а там rds: на Resource = "". Говорю - всё есть, всё должно работать. Хоть дропайте всё к херам (stage account). Возвращаются - нет, всё равно не работает. Проверяю глазами ещё раз полиси. Да вроде всё ок. Говорю сделайте релогин и попробуйте ещё, все права есть. Снова возвращаются, сделав релогин. Говорят "включаем, а оно не включается". Делаю невозмутимое лицо, хотя внутри уже кривлюсь как хурма: описание проблемы уровня "включаем, а не включается, ошибок нет" звучит слишком уныло, чтобы воспринимать его всерьёз. Прошу объяснить подробнее. Мне показывают по шагам: - зашли в консоль - зашли в RDS - нашли нужный proxy - нажали Edit/Modify (я не помню название кнопки) - поставили галочку "Activate enhanced logging" - нажали "Modify proxy" - видят надпись "Modifying proxy ..." - видят зелёный баннер "Successfully modified proxy ..." - выходят, заходят снова - галочки нет Нигде ни одной ошибки. Всё выглядит как успех. Но изменение не применяется. В ивентах пусто. Повторяю сам под своим admin пермишнсетом - у меня работает, галочка стоит. В ивентах изменения появились. Ладно, добавляю себя временно в эту группу и начинаю воспроизводить. Захожу под их пермишнсетом, повторяю их действия. Та же история - "Successfully modified", а галочка не стоит. Думаю что не так. Выхожу из SSO, захожу снова - галочки нет. Сбрасываю кеш браузера - галочки нет. Пробую другой браузер - галочки нет. Смотрю в developer tools в браузере - никаких ошибок, никаких 403, всё 200. Смотрю в сам UI консоли - ни единого красного баннера, ни единого намёка на проблему. Само собой инкогнито мод браузера не помог. Ивентов нет. Потратил на это ещё чуть времени, пока до меня наконец не дошло. Дурачок, - думаю я, - а CloudTrail-то ты проверил? Иду в CloudTrail, фильтрую по ModifyDBProxy. Нахожу событие. И там: "errorCode": "AccessDenied", "errorMessage": "User: ... is not authorized to perform: iam:PassRole on resource: arn:aws:iam::ACCOUNT_ID:role/rds-proxy-wanker because no identity-based policy allows the iam:PassRole action" Вот оно. AWS при вызове ModifyDBProxy передаёт IAM роль прокси в Secrets Manager. Для этого нужно право передать (PassRole) именно эту роль. rds: тут ни при чём - это отдельное действие на отдельный ресурс. В политике группы iam:PassRole был разрешён только для одной конкретной роли. Про rds-proxy- никто не подумал. Добавляем в политику: { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::ACCOUNT_ID:role/rds-proxy-" } Применяем, перелогиниваемся. Галочка встаёт и остаётся стоять. Ивенты пишутся. Итоги: - "Successfully modified" в AWS консоли не гарантирует, что изменение применилось 🥲 - AccessDenied может прилетать не на само действие, а на зависимое - в данном случае на iam:PassRole - Консоль эту ошибку не показывает совсем. Молча глотает. Никакого красного баннера. Никаких ошибок. Никаких ивентов. 😎 - CloudTrail - первое место, куда надо смотреть, когда "всё работает, но не работает" - rds: не равно "всё для RDS". Некоторые операции тащат за собой зависимости на другие сервисы - нехер снова кривить свою морду, коллеги всё же солнышки-зайчики и правы, даже если пояснение проблемы тупорылое
3.6K
просмотров
3351
символов
Да
эмодзи
Нет
медиа

Другие посты @makebreakreflect

Все посты канала →
#aws #rds #troubleshooting Приходят как-то коллеги, говорят — @makebreakreflect | PostSniper