Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

02.04.2024

Федеративна авторизація з AWS в GCP

Довелося мати справу з проєктом, де є компоненти в AWS та GCP. Наївне рішення в такому випадку — просто поділитися ключами доступу. Проте ключі можна вкрасти, тому всередині хмари ми користуємося ролями, що призначені з оточення. Дізнався, що роль AWS можна використати для авторизації в GCP - називається це Workload Identity Federation.

Яким чином Google може перевірити нашу роль? Трохи криво, але дієво: викликом AWS API GetCallerIdentity. Причому щоб Google міг зробити той виклик, ми формуємо параметри, підписуємо їх власним ключем AWS, та передаємо всі параметри в сервіс STS Google (зазначу, що ключі залишаються в нас - Google отримує тільки підпис). Той власноруч робить цей виклик, отримує у відповідь автентичну сутність AWS та, якщо їй дозволено вхід, видає нам ключ Google.

Окрему складність ставить бізнес-модель авторизації: є workload identity pool, який є “дверми в Google”; пул отримує доступ до конкретного service account, який буде нашим представником по всіх інших справах в Google Cloud. Але за авторизацію відповідає workload identity provider; в одного пула може бути декілька провайдерів. Як на мене, то дуже заплутано.

На щастя, більшість тих нюансів (в тому числі весь процес авторизації!) приховані в SDK. Тобто пул видає нам стандартний для GCP credentials.json, в якому міститься повна інструкція для клієнта, який буде запущений на AWS. (Нічого секретного: тільки інформація про засіб авторизації, та координати цільового service account.) Оскільки в межах AWS клієнт може отримати (тимчасові) ключі самостійно з оточення, то нам нічого більше робити не треба.

Тобто, коли вже розібрався, то все “просто”. До речі, так само Google підтримує авторизацію з OpenID Connect та іншими технологіями. Гарно!