Стендап Сьогодні 📢 Канал в 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 та іншими технологіями. Гарно!
15.04.2025
AWS та GCP: не такі вони вже й схожі
Я вже років 8 працюю з AWS, а от з Google Cloud Platform довелося стикнутися навсправжки тільки цього року. До того було хіба що Firebase та щось дрібненьке. Втім, в мене було переконання, що хмарна платформа — вона й в Гуглі хмарна платформа, та різниця хіба що в брендінгу та в назвах. (Ну, до речі, в хостингу для VPS дійсно майже так і є, тому було з чого так думати.)
Зате коли довелося налаштовувати авторизацію з AWS в GCP, вмочив ноги в гуглівську модель авторизації. А там… все зовсім не так, як я звик. В AWS доступ до ресурсів оголошується документом-політикою, де перелічені ресурси та дозволені операції з ними. Ну може декількома політиками. Але я легко можу побачити, до чого є доступи в конкретного користувача чи ролі.
А в Google… ну я, звісно, не експерт. Але тут доступи призначаються зі зворотного боку — з боку ресурсу. В Terraform для того є ціла купа окремих ресурсів на кшталт google_storage_bucket_iam_policy. Та ще й існує якесь успадкування. Та сервісні акаунти. Зовсім інша модель, одним словом, та майже ніякі знання з AWS не переносяться.
Тепер, нещодавно також довелося налаштувати на GCP проксі. Та знову, я звик, що в AWS є Балансувальник, а в нього є Слухачі, які направляють запити до Групи Цілей. А на GCP є Глобальна Адреса, Проксі, Відображення URL, та Бекенд-Сервіс. Я тут теж не знаюся, тому реально довго шукав, які взагалі ресурси мені потрібні та як вони називаються. Зокрема те, що в UI є Load Balancers, а в Terraform просто нічого схожого немає. Виявляється, що ото ці Load Balancers збираються з цілої купи абстракцій.
Так що не варто поспішати зі спрощеннями, поки досвіду немає. Зате, раніше я думав, що AWS надто заплутаний, а тепер здається, навпаки по-людськи зроблено.