В попередній частині серії по налаштуванню Okta зробили SSO для Grafana (див. Okta: налаштування Grafana SSO з OIDC та Role mapping) – тепер більш цікава задача: треба налаштувати SSO для AWS, і мати не тільки log in – а і users provisinong.
В Okta для цього є AWS IAM Identity Center App, яка дозволяє налаштувати логін з SAML (див. також What is: SAML – обзор, структура и трассировка запросов на примере Jenkins и Okta SAML SSO) та user provisioning із SCIM.
З богу AWS для цієї інтеграції налаштуємо власне сам IAM Identity Center, і заодно створимо AWS Organization.
З приводу Terraform: свідомо роблю без нього, бо зараз ми використовуємо Okta акаунт разом з іншим проектом і потім будемо відокремлюватись і перероблювати сетап. Ну і, крім того – я не займався налаштуваннями Okta з ~2020 року, тому перший час краще “поклікопсити”, аби краще розібратись з тими змінами, які за цей час сталися.
Аналогічно з Terraform для AWS – якщо всякі VPC/EKS у нас вже зроблені з Terraform, то налаштування, які відносяться до account management поки роблю руками, бо 100% ми будемо або переїжджати в новий акаунт, або будемо розділяти поточний, і поки невідомо як це все буде виглядати.
Але коли переїдемо – то 100% будуть пости по Terraform з Okta та AWS.
Зміст
AWS та сервіси для User Management
Перш ніж почати налаштування Okta – давайте коротко про те, що взагалі в AWS є з сервісів, які мають відношення до управлінню юзерами і доступами:
- AWS IAM: базовий сервіс – юзери, групи, ролі, політики
- IAM Identity Providers: наприклад, для налаштування OIDC для GitHub або OIDC для AWS Elastic Kubernetes Service
- AWS IAM Identity Center (колишній AWS Single Sign-On): те, що ми будемо використовувати для Okta – централізоване управління доступом до різних AWS Accounts, інтеграція з Identity Providers (IdP – Okta, Azure Active Directory, etc)
- AWS Organizations: централізоване управління різними AWS Accounts – Service Control Policies (SCP), спільні CloudTrail, Config, GuardDuty, централізований білінг
- AWS Control Tower: автоматичне налаштування AWS Organizations, IAM Identity Center, загальний compliance, security
Варіанти AWS SSO та Okta
Є два підходи до інтеграції Okta з AWS:
- AWS Account Federation (legacy):
- прямий SAML між Okta і кожним AWS акаунтом окремо через IAM Identity Providers – для кожного акаунту треба окремо створювати IAM Roles з Trust Policy на Okta, окремо налаштовувати SAML
- при наявності 10 акаунтів – 10 раз повторювати одне і те саме налаштування
- SCIM (provisioning) з Okta не підтримується – тобто юзери і групи не синхронізуються автоматично
- IAM Identity Center:
- централізований підхід – Okta підключається один раз через SAML, юзери і групи синхронізуються автоматично за SCIM протоколом
- Permission Sets (aka IAM Policies для юзерів і груп) – права визначаються один раз і призначаються на будь-яку кількість акаунтів
- при додаванні нового акаунту в AWS Organization – просто вибираємо існуючі групи та Permission Sets, без додаткового налаштування SAML
Ми будемо робити модно-маладьожно, з IAM Identity Center:
- Okta: буде нашим Idetity Provider – юзери створюються там, логін тільки через Okta
- IAM Identity Center: буде отримувати аутентифікованих юзерів від Okta та виконувати авторизацію з Permission Sets
Документація: Configure SAML and SCIM with Okta and IAM Identity Center та Configure AWS accounts and roles for SAML SSO.
Про AWS Organization
AWS Organizations дає нам централізоване управління кількома AWS акаунтами – об’єднує акаунти в ієрархію (Organizational Unit, OU – повіяло ностальгією за OpenLDAP) з єдиним білінгом, є основою для multi-account management і обов’язковою умовою для повноцінного IAM Identity Center з multi-account SSO.
Що дає AWS Organizations
Billing: єдиний consolidated billing на всі акаунти. До того ж всякі Reserved Instances і Savings Plans можна використовувати між всіма акаунтами організації..
Security / Governance
Єдина точка менеджменту різними security services:
- SCPs (Service Control Policies): політики обмежень на рівні акаунту або OU, які діють поверх будь-яких IAM прав і які не можна обійти навіть з AdministratorAccess, наприклад – “ніхто не може вимкнути CloudTrail” або “дозволити створення нових ресурсів тільки в заданих AWS Regions“
- AWS Config aggregator: збирає дані про конфігурацію ресурсів з усіх акаунтів в одне місце – можна бачити чи всі ресурси відповідають заданим правилам, наприклад – “всі S3 buckets мають бути зашифровані” або “всі EC2 інстанси мають мати певні теги“
- CloudTrail organization trail: єдиний CloudTrail для усіх акаунтів, не треба в кожному налаштовувати окремо
- GuardDuty, Security Hub, Macie: централізоване управління всіма security services
Networking: RAM (Resource Access Manager): дозволяє використовувати спільні ресурси між акаунтами без необхідності налаштовувати це між кожною парою акаунтів.
Account isolation (головна причина multi-account):
- можна (і треба) мати Production акаунт повністю ізольованим від Dev – випадковий
terraform destroyв Dev не торкнеться Prod- ще рекомендується мати і окремий акаунт з обмеженим доступом для security services
- обмежуємо blast radius одним акаунтом: якщо пушнули ACCESS/SECRET ключі в GitHub – то “під роздачу” попаде тільки один акаунт
- хоча краще ключі не використовувати взагалі
Що відбувається при створенні Organizations
Нічого не ламається: всі існуючі IAM Users, IAM Roles, IAM Policies, всі сервіси (EKS, RDS, S3) продовжують працювати. Поточний акаунт стає management account, з’являється root OU.
Єдиний момент, який треба мати на увазі, це сам management account змінити потім не можна. Тому перевіряємо, що створюємо Organization з правильного акаунту – там де billing і root доступ.
Створення AWS Organization
Переходимо в AWS Organization, клікаємо Create an organization:
AWS рекомендує створювати Organization з окремого акаунту – але нам, як маленькому стартапу, підійде і поточний, в якому маємо всі наші сервіси:
Після створення Organization, AWS пропонує включити Centralize root access for member accounts – відключити root accounts, і всі адміністративні дії виконувати тільки з management account.
Нам це поки не актуально, бо взагалі маємо тільки один акаунт, але взагалі з точки зору безпеки штука корисна:
Поїхали до самого цікавого.
Створення Okta App – AWS IAM Identity Center
Спершу додамо Okta App – IAM Identity Center, бо в самому AWS IAM Identity Center потрібні будуть параметри SAML від Okta:
Отримуємо лінк на SAML metadata:
У нас в Okta кастомний домен, в браузері свариться на сертифікат, а через HSTS нема можливості цю помилку ігнорувати:
Тому просто завантажуємо з curl:
$ curl -k https://okta.example.co/app/***/sso/saml/metadata -o metadata.xml
Перевіряємо, що дані в файлі є:
$ head metadata.xml <?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor entityID="http://www.okta.com/***" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"><md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"><md:KeyDescriptor use="signing"><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:X509Data><ds:X509Certificate>MII ...
Тепер, як AWS Organization та Okta App у нас є – можемо налаштувати IAM Identity Center.
Налаштування AWS IAM Identity Center
Документація – What is IAM Identity Center?
Що нам дасть IAM Identity Center, і що будемо налаштовувати:
- AWS Access Portal: буде єдина сторінка входу в усі акаунти організації
- Identity Source: налаштуємо source of truth для юзерів, в нашому випадку буде External Ientity Provider – Okta
- Account Assignments: прив’язка User Groups в IAM Identity Center, які далі синхронізуємо з Okta – до Permission Set для конкретного AWS акаунту, тобто – “Okta Group з іменем org-DevOps має AdministratorAccess в акаунті <accountName>“
- Permission Sets: набір IAM policies, який IAM Identity Center автоматично створює як IAM Role (з іменем, яке починається з AWSReservedSSO_) в цільовому AWS акаунті при підключенні User Group до Permission Sets, і далі, при логіні в акаунт – юзер використовує цю роль
Перед початком читаємо IAM Identity Center prerequisites and considerations, звертаємо увагу на:
IAM Identity Center creates IAM roles to give users permissions to account resources. For more information, see IAM roles created by IAM Identity Center.
AWS Organizations is recommended, but not required, for use with IAM Identity Center. If you haven’t set up an organization, you do not have to. If you’ve already set up AWS Organizations and are going to add IAM Identity Center to your organization, make sure that all AWS Organizations features are enabled. For more information, see IAM Identity Center and AWS Organizations.
Поїхали – переходимо в IAM Identity Center, клікаємо Enable:
Якщо AWS Organization ще нема – AWS пропонує її створити, якщо не хочемо мати Organization – можна включити IAM Identity Center в режимі account instance:
Якщо Organization вже є – то відразу включаємо як organization instance:
Клікаємо Enable, починаємо конфігурацію.
Налаштування Identity Source з Okta
Переходимо в Settings > Identity Source, в Actions вибираємо Change Identity Source:
Вибираємо External type:
Отримуємо URLs, зберігаємо собі:
- IAM Identity Center Assertion Consumer Service (ACS) URL
- IAM Identity Center issuer URL
В Identity Provider Metadata завантажуємо файл metadata.xml, який скачали з Okta App:
При зміні IAM Identity Center виводить попередження про зміни для юзерів – але це відноситься тільки для юзерів самого IAM Identity Center, яких в нашому випадку ще нема – логін для звичайних IAM Users буде працювати, як і раніше:
Налаштування SAML в Okta AWS IAM Identity Center App
Пишемо ACCEPT, клікаємо Change – отримуємо налаштування для SAML в Okta App:
Повертаємось до Okta App, переключаємось на Sign On, клікаємо Edit та задаємо адреси:
- AWS SSO ACS URL: це IAM Identity Center Assertion Consumer Service (ACS) URL із AWS IAM Identity Center
- AWS SSO issuer URL: це IAM Identity Center issuer URL із AWS IAM Identity Center
Власне, на цьому з аутентифікацією все.
Але залогінитись юзери ще не можуть – трохи далі налаштуємо це.
Поки зробимо Users та Groups provisiong – синхронізацію груп та юзерів із Okta до AWS IAM Identity Center.
Налаштування Provisioning з Okta до IAM Identity Center
Повертаємось до IAM Identity Center > Settings, клікаємо Enable в Automatic Provisioning:
Отримуємо URL та Access Token.
Токен відразу зберігаємо – бо більше його не побачимо:
Повертаємось до Okta > Provisioning > Configure API Integration:
Групи із IAM Identity Center в Okta нам не потрібні – ми будемо робити тільки з Okta до IAM Identity Center, тому знімаємо галочку, погоджуємось з попередженням:
Задаємо URL, токен, клікаємо Test API Credentials:
“Єсть контакт!”:
Зберігаємо, клікаємо Edit, включаємо синхронізацію юзерів, їхнії атрибутів та деактивацію юзерів (виключили акаунт в Okta – виключили в AWS):
Тепер у нас під назвою App все зелене – маємо всі інтеграції:
Assigning Okta Users та Okta Groups до Okta IAM Identity Center App
Переходимо в Assign, додаємо цю App до Okta Group:
Залишаємо всі дефолтні атрибути:
І вже маємо юзерів в IAM Identity Center:
Але не групи – тут поки пусто:
Створення Permission Set для IAM Identity Center User Groups
Документація – Create, manage, and delete permission sets.
Permission Sets визначає те, які права доступу будуть у юзера чи групи в AWS Account, тобто:
- в Okta маємо Okta Group (org-DevOps)
- Okta виконує group push в IAM Identity Center (про це далі)
- в IAM Identity Center отримуємо нову групу org-DevOps
- цю групу додаємо до AWS Account
- в AWS Account створиться IAM Role з іменем AWSReservedSSO_<Permission_Set_name>
- при логіні в акаунт – юзер виконує Assume Role цієї ролі
Створюємо новий Permission Set:
В Custom Permission Set можна вибрати власні політики, описати inline policy, або використати вже готові набори.
Для девопсів робимо AdministartorAccess:
Session duration можна поставити побільше:
Зберігаємо новий Permission Set, але Provisioned status поки Not provisioned – бо цей Permission Set ще нікому підключений:
Синхронізація Okta Groups з Okta Push Groups
Для синхронізації Okta Groups до AWS IAM Identity Center – переходимо в Push Groups, вибираємо групу – при чому необов’язково, щоб вона була Assigned до цієї App:
Вибираємо Okta Group:
Група готова до push в IAM Identity Center, і маємо дві опції – Create Group, якщо такої групи в AWS ще нема, або Link Group – зв’язати групу в Okta з вже існуючою групою в AWS:
Клікаємо Save, починається процес синхронізації:
Готово:
Перевіряємо групи в IAM Identity Center – є нова група з двома юзерами:
Потім в Okta можна відключити синхронізацію:
Підключення IAM Identity Center User Groups до AWS Accounts
Аби юзери цієї групи могли логінитись в AWS Account – виконуємо Assign вже в самому IAM Identity Center:
Вибираємо групу:
Вибираємо створений раніше Permission Set:
В списку AWS Accounts тепер маємо підключений Permission Set:
І в самому AWS Account в IAM Roles маємо нову роль:
Final: логін з SSO через AWS Access Portal
Знаходимо URL нашого AWS Access Portal – це буде єдина точка входу всіх юзерів:
Або клікаємо на App в Okta.
Попадаємо на сторінку вибору акаунтів, відразу бачимо Permission Set з яким можемо залогінитись:
Логінимось, і маємо доступ до всіх наших сервісів:
Власне – на цьому і все.
SSO та user provisioning налаштований, логін працює.
Для AWS Access Portal можемо налаштувати власний URL – але тільки в зоні awsapps.com – клікаємо Edit:
Задаємо власне ім’я:
І далі ходимо через https://example.awsapps.com/start.
Налаштування AWS CLI з SSO
Всі старі доступи з ACCESS/SECRET ключами ще працюють, але відразу налаштовуємо собі новий логін з SSO.
Документація – Configuring IAM Identity Center authentication with the AWS CLI.
Виконуємо aws configure sso, з --profile вказуємо для якого саме акаунту буде логін з SSO:
$ aws configure sso --profile work SSO session name (Recommended): org-sso SSO start URL [None]: https://example.awsapps.com/start SSO region [None]: us-east-1 SSO registration scopes [sso:account:access]: Attempting to automatically open the SSO authorization page in your default browser. ...
Відкриється браузер, дозволяємо доступ:
І терміналі бачимо повідомлення, що SSO для профайлу work налаштований:
... The only AWS account available to you is: 492***148 Using the account ID 492***148 The only role available to you is: DevOps-AdministratorAccess Using the role name "DevOps-AdministratorAccess" Default client Region [us-east-1]: CLI default output format (json if not specified) [None]: To use this profile, specify the profile name using --profile, as shown: aws sts get-caller-identity --profile work
Перевіряємо як ми залогінені – маємо наш власний UserId, який має assumed-role/AWSReservedSSO_DevOps-AdministratorAccess:
$ aws sts get-caller-identity --profile work
{
"UserId": "ARO***ORD:[email protected]",
"Account": "492***148",
"Arn": "arn:aws:sts::492***148:assumed-role/AWSReservedSSO_DevOps-AdministratorAccess_66a4ead4b037e25f/[email protected]"
}
А в ~/.aws/config тепер для юзера маємо sso_session та конфіг самого SSO:
$ cat .aws/config ... [profile work] region = us-east-1 output = json sso_session = org-sso sso_account_id = 492***148 sso_role_name = DevOps-AdministratorAccess ... [sso-session org-sso] sso_start_url = https://example.awsapps.com/start sso_region = us-east-1 sso_registration_scopes = sso:account:access
Готово.
