текст перекладу
Вступ
Забезпечення підключення до бази даних, що хоститься в хмарі, може бути складним і трудомістким процесом. Оновлення найкращих практик безпеки та захист статичних паролів можуть швидко стати складним завданням, оскільки команди та сервіси зростають. Google Cloud AlloyDB надає кілька різних механізмів, які інженери платформи можуть використовувати для забезпечення комунікацій і надання безперебійного досвіду для команди розробників.
У цьому посібнику ми розглянемо, як інженер платформи може налаштувати кластери AlloyDB для забезпечення доступу до них, дотримуючись принципу найменших привілеїв, і мінімізувати кроки, необхідні команді розробників для підключення до хмарних кластерів AlloyDB.
Як бонус, ця стаття також охоплює використання імітації сервісного облікового запису, функції, яка може допомогти інженерним командам впевнено налаштувати IAM перед фактичним розгортанням.
Необхідні умови
Щоб слідувати за цією статтею, вам потрібно:
- Обліковий запис Google Cloud Platform (GCP)
- Кластер AlloyDB з одним екземпляром
Ви можете скористатися безкоштовною пробною версією AlloyDB, яка дозволяє протестувати більшість функцій AlloyDB протягом 30 днів без фінансових зобов'язань, використовуючи основний екземпляр 8vCPU, який автоматично масштабує зберігання до 1TB [1].
Ця стаття також передбачає, що ви створили логічну базу даних всередині кластера AlloyDB, щоб після налаштування запустити базовий запит для перевірки, що налаштування працює.
Читачі також повинні переконатися, що мають відповідні права доступу:
- AlloyDB
a. Оновлення прапорців
b. Створення користувачів - IAM
a. Створення груп
b. Додавання користувачів до груп
c. Надання ролей групам
Для цієї статті, щоб зробити все простішим, ми використовуємо кластер AlloyDB з одним екземпляром, який має публічну IP-адресу. Це вирішує перший і найважливіший аспект підключення, а саме створення мережевого шляху до AlloyDB. Як зауважить будь-який хороший інженер, публічне підключення == погано, і вони будуть абсолютно праві. Ця стаття також коротко розглядає, що ви можете зробити для захисту цієї публічної IP-адреси.
Як це зробити
Рис. 1 Огляд
Крок 1 : Увімкнення автентифікації IAM для кожного екземпляра виявленого кластера AlloyDB
Ви можете зробити це, встановивши прапорець alloydb.iam_authentication в значення on для кожного екземпляра кластера:
Рис. 2 Встановлення прапорця IAM Auth
Перевірте, чи була успішною ця зміна:
gcloud alloydb instances describe primary --cluster=development \
--region=us-central1 --project=dev
.
.
.
databaseFlags:
alloydb.enable_pglogical: on
.
.
Це критичний крок для забезпечення того, щоб автентифікація IAM працювала для окремих користувачів. Користувач повинен бути налаштований в AlloyDB так, щоб ім'я користувача кожного користувача відповідало електронній пошті, пов'язаній з їхнім GCP-обліковим записом. Це спосіб, за допомогою якого GCP зв'язує одного користувача IAM з користувачем у базі даних. Ви можете зробити це за допомогою інтерфейсу AlloyDB studio UI:
Рис. 3 Створення користувачів бази даних
Крок 2 : Надання ролей групі користувачів, які повинні мати доступ до AlloyDB за допомогою автентифікації на основі IAM
Це друга частина налаштування користувачів: після того, як всі користувачі будуть налаштовані в базі даних, їх можна об'єднати в групу, і групі будуть надані наступні дозволи:
Рис. 4 Налаштування ролей IAM
Опис ролей на скріншоті вище підкреслює важливість кожної з них. Ми пояснимо призначення ролі Service Account Token Creator в другій частині статті.
Для зручності при налаштуванні цього демо ми використали групу, яка існує на рівні організації, щоб члени мали права, що поширюються на всі проєкти.
Ви можете вибрати зробити те саме на рівні проєкту, якщо хочете досягти більшої ізоляції дозволів. Дозволи, надані учасникам цієї групи, дозволяють лише підключення до будь-якого інстансу AlloyDB. Перевірте, чи зміни були успішними:
gcloud organizations get-iam-policy 49620912242 \
- filter="bindings.members:group:[email protected]" \
- flatten="bindings[].members" \
- format="table(bindings.role)"
ROLE
roles/alloydb.client
roles/alloydb.databaseUser
roles/iam.serviceAccountTokenCreator
roles/serviceusage.serviceUsageConsumer
Це гарний момент, щоб зупинитись і підсумувати, де ми зараз знаходимося в цій статті та що ми вже налаштували. Пройшовши кроки з 1 по 3, ми вже досягли всіх вимог для успішної настройки аутентифікації на основі IAM з AlloyDB за допомогою токенів OAuth 2.0. Це так просто! Наступні кроки демонструють, як розробники можуть підключитись до кластера.
Це також гарний момент, щоб обговорити дозволи. Кроки з 1 по 3 гарантують, що лише один користувач, який є частиною IAM-групи з правильними дозволами та має відповідного користувача в базі даних, може підключитися до інстансу AlloyDB. Те, що користувач може робити всередині логічної бази даних всередині кластера, не визначено. Ці дозволи визначає виключно адміністратор бази даних, користувач з роллю postgres. Тому існують два різні рівні дозволів.
Крок 4: Встановлення облікових даних
Призначте ADC для вашого користувача, виконавши наступну команду:
# Ця стаття передбачає, що користувач вже виконав gcloud init та
# налаштував свій проєкт у процесі. Це необхідно, оскільки без
# цього жоден проєкт не буде призначений для виставлення рахунків і квоти, і
# код на Python поверне повідомлення про помилку, що вказує на це. Якщо ви хочете
# використовувати лише автентифікацію через adc, необхідно зазначити опцію
# set-quota-project.
gcloud auth application-default login
Крок 5: Запуск проксі-сервера AlloyDB
Це встановлює захищене з’єднання TLS 1.3, використовуючи шифр AES 256 біт, між вашим комп'ютером та інстансом AlloyDB. Важливо, щоб:
!!
IAM-обліковий запис, який ви використовуєте для запуску клієнта проксі, має бути тим самим обліковим записом, який ви додали як користувача бази даних.
Зверніть увагу на прапорець —auth-iam-authn, що передається в команду проксі. Використання цього прапорця дозволяє вам автоматично автентифікуватися з AlloyDB, тобто автоматично обмінювати токени OAuth 2.0!!
Поки виконується ця умова І команда платформи налаштувала користувача розробника в базі даних, вам не потрібно турбуватися про запит токену чи його часове обмеження
!!
alloydb-auth-proxy projects/dev/locations/us-central1/clusters/development/instances/primary \
--port 5432 --public-ip --auto-iam-authn
2024/10/07 20:44:32 Авторизація з використанням стандартних облікових даних додатка
2024/10/07 20:44:32 [dev.us-central1.development.primary] Прослуховування на 127.0.0.1:5432
2024/10/07 20:44:32 Проксі-сервер успішно запущений і готовий до нових підключень!
Крок 6: Підключення
Приклад коду Python, щоб перевірити, чи все працює, як очікується:
pip install google-auth
import psycopg
# Підключення до AlloyDB за допомогою psycopg та IAM-токена як пароля.
conn = psycopg.connect(
dbname='',
user='[email protected]', # Використовуйте IAM email як користувача, дивіться, немає пароля!
host='localhost',
port='5432'
)
# Тепер можна виконувати запити
cur = conn.cursor()
cur.execute("SELECT * FROM verse.dev LIMIT 1;")
rows = cur.fetchall()
for row in rows:
print(row, "\n")
cur.close()
conn.close()
Успіх !!
('abc', '123', Decimal('6'))
Імперсонація облікових записів сервісу
Під час тестування локально можливо, що облікові дані користувача мають доступи, які значно ширші, ніж ті, які має обліковий запис сервісу, асоційований з обраною обчислювальною платформою.
Це може означати, що ви бачите успішні запуски локально, але стикаєтесь із помилками дозволів після розгортання.
Для підвищення швидкості розробки та впевненості розробників вам слід скористатися імперсонацією облікових записів сервісу, щоб протестувати навантаження до розгортання на GCP. Щоб використовувати цю конфігурацію, команда платформи може надати IAM-користувачам розробників (краще групі користувачів) дозвіл на імперсонацію облікового запису сервісу, надавши таку роль:
- roles/iam.serviceAccountTokenCreator
Для цієї конфігурації зокрема, якщо ви хочете перевірити, чи працюватиме ваше розгортання, скажімо, на Cloud Run, ви можете імперсувати обліковий запис сервісу, призначений для сервісу Cloud Run, на який ви будете розгортати, використовуючи наступну команду для генерації імперсованих стандартних облікових даних додатка (ADC):
gcloud auth application-default login - impersonate-service-account
Наступного разу, коли ви запустите ваш код локально, ви будете виконувати його так, ніби він працює на GCP, використовуючи облікові дані облікового запису сервісу — таким чином підвищуючи вашу (та інших розробників) впевненість. Недостатні дозволи можна виявити на ранніх етапах розробки і виправити до фактичного розгортання на GCP.
Примітка щодо публічного IP AlloyDB
Для цієї демонстрації ми використовували інстанс AlloyDB з публічною IP-адресою. Це спростило процес для демонстрації та забезпечило чіткий мережевий шлях від локального комп'ютера користувача до AlloyDB. Ви можете посилити цей шлях публічної IP-адреси, скориставшись можливістю AlloyDB для авторизованих зовнішніх мереж, де лише певні зовнішні IP-адреси можуть звертатися до AlloyDB. Ідеально, і залежно від конкретних випадків використання, AlloyDB слід використовувати приватну IP-адресу для мінімізації ризику перехоплення трафіку.
Подальше читання
Ще одним популярним варіантом для автоматизації процесу аутентифікації проти інстансу AlloyDB та входу до бази даних є використання AlloyDB-конекторів. Стаття "Understanding AlloyDB Connectors" (Розуміння AlloyDB конекторів)[2] є чудовим вступним матеріалом для ознайомлення з ними.
Посилання
- “Огляд безкоштовних кластерів AlloyDB | Alloydb для Postgresql | Google Cloud.” Google. https://cloud.google.com/alloydb/docs/free-trial-cluster.
- “Вступ до Alloydb Connectors | Блог Google Cloud.” Google. https://cloud.google.com/blog/products/databases/intro-to-alloydb-connectors.
Перекладено з: IAM-Based Auth for GCP AlloyDB