Используя какую-то #IAM роль для переключения в другую роль, нужно не забывать про role chaining:
Using the credentials for one role to assume a different role is called role chaining. When you use role chaining, your new credentials are limited to a maximum duration of one hour.
Это в, в частности, объясняет раздражающую всех проблему при использовании AWS #SSO - когда через час сбразывается сессия.

Исправление "раздражающей всех проблемы" — у #SSO появилась возможность установить Session Duration.

В частности, про #SSO — небольшая утилитка на Go для аутентификации с использованием #Shibboleth Identity Provider.

https://github.com/CUBoulder-OIT/aws-shib

⁠О вреде юзеров.

В грамотно спроектированном окружении нет (не должно быть) #IAM юзеров. Почему? Потому что у юзера есть #credentials и они должны быть где-то явно указаны (в отличие от роли, прикреплённой к инстансу).

Если у вас один аккаунт на всех и всё, значит все пользователи заходят через юзеров, что проблема в степени количества этих юзеров. Обязательно включайте MFA для всех юзеров. А лучше переходите на светлую сторону #multi_account_strategy + #SSO.

В легаси-проектах, где ПО не умеет роль (требует наличия AccessKeyId и SecretAccessKey) - приходится заводить юзера. Включайте ему минимальные права - ровно на то, что он должен делать.

Для некоторых ситуаций, например, доступ в #CodeCommit по SSH или в #ES вне #VPC - тоже требуется наличие юзера. Всё это издержки Амазона (фу, как не стыдно), не придумавшего пока, как реализовать это без юзеров.

Во всех остальных случаях - никаких юзеров. Помните, хороший юзер - это роль.

#recomendation

⁠Минимальная схема не является рекомендованной, т.к. поднятие ресурсов в мастер-аккаунте не есть #best_practices. Согласно оным мастер-аккаунт должен быть пустым и страшно защищённым.

Правда пока сам Амазон не способствует такой реализации - отдельные сервисы (#CloudTrail, #Config, #SSO и др.) до сих пор завязаны некоторым своим функционалом на использование именно мастера. В результате для соблюдения архитектурной чистоты приходится плодить костыли и с нетерпением ждать, когда же эти косяки будут исправлены.

Однако делать нужно правильно, несмотря на некоторые текущие моменты. Как минимум знать и стремиться.

Здесь и далее всё будет подразумевать использование AWS #Organizations, что и есть реализация #multi_account_strategy.

===
Рекомендуемая схема
===

В рекомендуемой схеме мастер аккаунт пустой (с поправкой на то, что пока ещё требует запуска в нём) - как минимум, никакие виртуалки в нём точно не запускаем, а наш #devops становится суб-аккаунтом и смещается по иерархии ниже.

Для различных функций, в том числе связанных со всей организацией, некоторая часть мух из предыдущей "мухо-котлетной" схемы выделяются в отдельный аккаунт с расплывчатым названием Secure. Туда переезжают ключи шифрования, домены (только регистрации, а не Hosted zones), бэкапы, #CloudTrail-логи и прочие сущности с особой важностью для организации в целом.

Современные фичи Амазона изменяют некоторые архитектурные элементы.

• Bastion выбрасываем - появление #SSM #Session_Manager закрывает его функционал.

• Для #VPC_peering используем #Transit_Gateway.

• В Devops-аккаунте добаляется #Shared_VPC, которая используется для окружений без жёстких требований по безопасности (условно dev-test), хотя, в принципе, можно и для всех окружений.

Также в Devops-аккаунте появился #Jenkins как CI-инструмент - это может быть любой другой вам привычный (я же использую Jenkins, как говорил Портос, потому, что я использую Jenkins).

⁠Дальнейшее усложнение AWS #Organizations происходит по мере увеличения количества проектов, команд, требований и т.д.

===
Расширенная схема
===

• Общие ресурсы (ECR, снэпшоты, AMI и др.) вместе с #Shared_VPC выделяются в Shared аккаунт.

• Централизованный мониторинг и логи (ELK/Prometheus/Grafana/Sentry и т.д.) занимают свой аккаунт Monitoring (логи прода могут отправляться туда же или в отдельные - тут чисто условно).

• Бэкапы переезжают в DR (Disaster Recovery) аккаунты своих проектов.

• Наборы окружений dev-test-stg-prod-dr объединяются в #OU (Organization Units) для возможности применения к ним групповых SCP политик (объединение может быть и как Dev OU, DR OU etc - тоже чисто условно).

• Если ваша контора хочет целиком переехать в AWS, то выделяется отдельный аккаунт Organization для "организационных" вещей (название не самое удачное, речь об организации-фирме-компании, где, видимо, вы работаете :) ) — AD (Active Directory) для юзеров (самих работников), используемые для #SSO как единой точки входа, а также финансы, биллинги и прочие бухгалтерии, которые совсем не про код - всё будет там.

Процесс детализации #multi_account_strategy можно продолжать дальше - например, добавить OU для #HIPAA и прочих #compliance, где посредством #SCP будут отрабатывать их требования. Многие используеют Sandbox и/или личные аккаунты для разработчиков. И так далее и тому подобное — основные типы уже были перечислены и это уже лишь детали.

⁠AWS SSO + MFA

Наконец-то завезли честную MFA в SSO (до этого была лишь MFA через почту, что, скажем так, не так удобно и не совсем "мфашно") — теперь можно подключить любимый Google Authenticator сотоварищи:

https://aws.amazon.com/about-aws/whats-new/2019/10/increase-aws-single-sign-on-security-with-multi-factor-authentication-using-authenticator-apps/

Два года назад обещали сделать. Год назад обещали точно сделать через год. Что ж, Авээс обещал - Авээс сделал.

#SSO #субботничное #праздничное

AWS CLI v2 с поддержкой SSO

Новая "беспитонная" версия aws-cli доступна для установки:

https://aws.amazon.com/blogs/developer/aws-cli-v2-installers/

Кроме питононезависимости она умеет работать с SSO:

https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/

Пока данная версия в превью, потому устанавливается как aws2. После отладки она заменит текущую aws и позволит отказаться от набора утилит, реализующих сходный/пересекающийся с SSO функционал.

#aws_cli #SSO

Свой программный логин через SSO

В превью новой версии aws-cli появилась её интеграция с SSO. И вот теперь можно будет делать это самостоятельно из своих приложений.

API программного логина:

https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/Welcome.html

API портала:

https://docs.aws.amazon.com/singlesignon/latest/PortalAPIReference/Welcome.html

Пока нет официального анонса этих фич, но это будут весьма полезные вещи в русле мульти-аккаунт стратегии.

#SSO

⁠Session Duration Time

Люди, кто мучается при переключении аккаунтов, из-за сессии, подло истекающей через 1 час и сбрасывающей недоделанную в консоли работу в самый неподходящий момент — не мучайтесь, пожалуйста, зайдите и поставьте себе 12 часов session duration time!

https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html#API_AssumeRole_RequestParameters

Просто дефолтное значение именно 1 час.

Аналогично для SSO:

https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html

Поставь себе 12 часов - и работай спокойно!

#лайфхак #IAM #SSO

​​ABAC+SSO:

https://aws.amazon.com/blogs/aws/new-attributes-based-access-control-with-aws-single-sign-on/

Прошёл ровно год с появления ABAC (Attribute-Based Access Control) или Tag-Based Access Control. И вот теперь при наличии SSO давать доступ к ресурсам стало ещё проще и удобней.

Включаем ABAC на страничке настроек SSO (на картинке), как заработает, добавляем нужные атрибуты, которые будут пробрасываться. Например, банально username (на картинке). Теперь добавив к любому ресурсу в политики доступа условие:

"Condition": {
 "StringEquals": {
  "ec2:ResourceTag/username": "${aws:PrincipalTag/username}"
 }
}

Можно будет просто зайти в тэги, например, RDS базы данных, и добавить тэг username со значением Karen . В результате пользователь Karen, залогинившись через SSO, автоматически получит доступ к этой базе.

#ABAC #SSO

AWS SSO теперь поддерживает WebAuthn, в результате чего появилась возможность авторизоваться через отпечаток пальца или, например, с помощью Windows Hello:

https://aws.amazon.com/blogs/aws/multi-factor-authentication-with-webauthn-for-aws-sso/

Также теперь можно использовать более, чем два устройства/варианта для авторизации в AWS аккаунт.

#SSO

Оптовый импорт пользователей в AWS SSO:

https://aws.amazon.com/blogs/security/how-to-bulk-import-users-and-groups-from-csv-into-aws-sso/

#SSO

Поддержка AWS SSO в VS Code:

https://aws.amazon.com/blogs/developer/introducing-aws-sso-support-in-the-aws-toolkit-for-vs-code/

#SSO #VSCode

Leapp — утилита для переключения в мультиаккаунтной среде в один клик:

https://github.com/Noovolari/leapp

Утилита не новая, но в последней версии 0.7.4 добавилась поддержка AWS SSO, выглядит привлекательно, а потому стоит ознакомиться и попробовать.

Кроме AWS также работает с Azure.

#IAM #SSO #multi_account_strategy

​​AWS SSO переименовали в AWS IAM Identity Center, теперь это часть IAM сервиса.

https://aws.amazon.com/iam/identity-center/

IAM Identity Center helps you securely create, or connect, your workforce identities and manage their access centrally across AWS accounts and applications. IAM Identity Center is the recommended approach for workforce authentication and authorization in AWS, for organizations of any size and type. 

Демо-видео:

https://www.youtube.com/watch?v=4yJp5-jGGNk

AWS SSO стал реально крутым и обязательным для использования сервисом, реализующим правильный подход к безопасности и получивший достаточный набор функционала, ранее присутстсвующий лишь в платных решениях.

Теперь же его инкарнация в виде IAM Identity Center предполагает в том числе продвижение #multi_account_strategy, становясь главным инструментом для входа через user portal.

p.s. Передаю пламенный привет создателям и студентам курсов по AWS сертификации - кому-то переделывать, а кому-то переучивать. 😁

#SSO #IAM