Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
24.05.2025
Google Workload Identity Federation... на ECS
Понад рік тому я писав про авторизацію з AWS до GCP. ЇЇ не так важко налаштувати та працює вона відмінно. Без жодного секрету, тільки з правильним файлом credentials.json. Але нещодавно дізнався, що є нюанс: не у всіх середовищах.
Всередині клієнту Google потрібні ключі доступу до AWS. (Щоб побудувати підпис — далі вони не йдуть.) В простому випадку код авторизації (ось на Go) шукає ключі в змінних оточення.
Якщо мовити про виконання в AWS, то ключі в оточенні знайдеш тільки в AWS Lambda. Тому що ключі ці завжди тимчасові. Та тільки Lambda теж настільки ефемерна, що її час існування не перебільшує терміну дії ключів.
А в інших місцях — на EC2 та на Fargate - є спеціальні HTTP API для отримання тимчасових ключів. Різні. Та клієнт Google вміє читати ключі тільки з EC2 Metadata API. Буквально — в їхній реалізації немає згадки про Fargate.
(До речі: намагався знайти офіційне посилання на документацію по цьому Fargate API, та знайшов тільки згадку в документації по SDK. Тобто технічно цей API… незадокументований? Таємний? Це багато пояснює.)
(Взагалі, а чому вони не використовують для цього AWS SDK, в якому вже реалізовані універсальні методи отримання ключів? Включаючи, звісно, читання з цього самого API? Політика?)
Отже, як вийти з цих обставин? Ну я знайшов дикий, але дієвий та універсальний спосіб: підробити EC2 Metadata API, а точніше, його частину, до якої звертається клієнт Google. На щастя, в credentials.json є посилання на той API, отже, його можна підмінити на наш власний. А власному залишається просто читати тимчасові ключі з Fargate API та віддавати за EC2 API - суть авторизації абсолютно не змінюється. Класичний патерн адаптера. (Але це не точно).