Используя какую-то #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