Лучшие практики использования OU (Organizational Units) в мульти-аккаунтах:

https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/

#best_practices #multi_account_strategy #Organizations

​​SCP и мастер (root) AWS-аккаунт

Стоит помнить, что "всемогущие" политики SCP, которые так удобно можно применять ко всей организации — не применяются к юзерам и ролям мастер аккаунта (root-аккаунта):

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Потому, если, например, думаете, включать или не включать CloudTrail в регионах, что планируете запретить через SCP — однозначно стоит включать. Уже лишь как раз по причине того, что в мастере SCP не сработает, а две защиты лучше, чем одна (в подаккаунтах).

#SCP #Organizations

Советы по работе с AWS Organizations от производителя:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices.html

Рекомендации для мастер-аккаунта и для подаккаунтов.
Основные:
▪️ не используйте публичные почтовые сервисы (бо̀льшая вероятность взлома)
▪️ обязательно включайте MFA
▪️ блокируйте root-юзеров в подаккаунтах с помощью SCP
▪️ периодически проверяйте процесс восстановления доступа к аккаунту (чтобы проверить, что всё нужное для этого есть у нужных людей)
▪️ создайте/обновляйте документацию по процессу восстановления доступа

#best_practices #Organizations

Master-аккаунт #Organizations переименовали в Management-аккаунт.

https://docs.aws.amazon.com/organizations/latest/userguide/document-history.html

Как несложно догадаться — в рамках борьбы с master ветками и прочими нетолерантными терминами.

===

В связи с этим интересно узнать, что вы думаете по этому поводу.

Стоит избавляться от подобных названий?
(master → main или как в данном случае master → management)

#опрос

​​Superwerker

Кто про что, а в̶ш̶и̶в̶ы̶й̶ ̶п̶р̶о̶ ̶б̶а̶н̶ю̶ я про AWS Organizations. Которой в этом году исполнится пять лет. И, значит, уже пятый год мы живём без гуманной процедуры удаления аккаунта, без временных аккаунтов.

За это время использование #multi_account_strategy стало обязательной практикой, в помощь чему появился сервис Control Tower, который в прошлом году обзавёлся возможностью работать в том числе и в существующей организации.

Однако порог входа для начала работы с лучшими практиками, которые даёт Organizations, пока по-прежнему высок. В попытке его снизить, намедни появился новый open source инструмент – superwerker:

https://github.com/superwerker/superwerker

Хороший набор #security #best_practices, правда, хороший – самое основное, что нужно иметь. Идеи по управлению аккаунтами в том числе позаимстованы из AWS Account Controller от Ian Mckay. Модный event-driven подход, (практически) бесплатные Лямбды.

Если бы хотел начать – точно бы обратил внимание. Заявленные фичи действительно самые нужные-востребованные:

▪️ Control Tower
▪️ AWS SSO
▪️ GuardDuty+dashboards
▪️ Security Hub+dashboards
▪️ AWS Backup
▪️ AWS Budgets
▪️ SCP guardrails
▪️ SSM+OpsCenter
▪️ CloudWatch dashboard

То, что (в первой версии) нет сетевой части, по мне так это и к лучшему. Система расширяемая и новые фичи вскоре наверняка будут с излишком.

Установка Superwerker официально доступна в качестве AWS Quick Start:

https://aws.amazon.com/quickstart/architecture/superwerker/

Хорошая штука, в общем. Можно рекомендовать.

#Organizations

Простая и действенная Лямбда для того, чтобы получать отчёт по биллиннгу по аккаунтам в Organizations, где можно увидеть номера аккаунтов и их тэги:

https://aws.amazon.com/blogs/aws-cost-management/cost-reporting-based-on-aws-organizations-account-id-tags/

Добавляем тэги на аккаунты (EDIT TAGS на AWS аккаунте в консоли Organizations) и после с помощью Лямбды, которую можно легко задеплоить из готового CloudFormation шаблона по ссылке из статьи выше, получаем в бакет csv файл со списком аккаунтов, их почтами, тэгами и расходами.

В общем, не стоит пытаться засунуть в название аккаунта всевозможные его характеристики лишь для того, чтобы после видеть в биллинге разбиение исходя из такого примитивного подхода – ведь для этого есть и правильно использовать тэги.

#Organizations

Рекомендации по мульти-аккаунт стратегии от первоисточника:

https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html

Целый раздел документации по лучшим практикам в организации #Organizations организации. 😄

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

#multi_account_strategy

​​В новых иконках от AWS добавили AWS Account:

https://aws.amazon.com/architecture/icons/

#Organizations #design

Серьёзные подвижки для работы в мульти-аккаунт окружении — возможность программно изменять почту для billing/operations/security в под-аккаунтах:

https://aws.amazon.com/blogs/mt/programmatically-managing-alternate-contacts-on-member-accounts-with-aws-organizations/

По умолчанию все сообщения по поводу AWS аккаунта — биллинг, проблемы безопасности (например, вас поломали и/или ваши виртуалки рассылают спам) — шлются на почту root-юзера. Однако можно задать альтернативные контакты - отдельные почты для billing/operations/security.

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

Теперь же можно запустить баш-скрипт (в AWS огромное Bash-лобби 😁) из статьи и назначить всем подаккаунтам нужные почты (или одну на всех). Что реально круто. Обязательно воспользуйтесь!

#Organizations #security #multi_account_strategy

​​DevOps Guru для всей организации:

https://aws.amazon.com/ru/about-aws/whats-new/2021/11/amazon-devops-guru-multi-account-insight-aws-organizations/

Теперь можно выдать в девопс-аккаунте права для работы DevOps Guru со всей организацией (Delegated Administrator). С учётом того, что DevOps Guru стал поддерживать ещё больше EKS Insights метрик, то получается солидный инструмент.

Не вместо девопса, понятно – это больше для броского словца, но весьма полезный инструмент для девопса. Может быть дорогой, но хипстерский крутой и полезный. 😀

#DevOpsGuru #Organizations #devops

Закрытие AWS account через AWS SDK & AWS CLI:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_close.html#aws-cli-&-aws-sdks

aws organizations close-account --account-id 123456789012

Не прошло и пять лет. Ан нет, прошло.

Нужно учитывать следующие особенности закрытия (на самом деле сначала приостановки - SUSPENDED) AWS аккаунтов в Organizations:

▫️ Закрыть можно любой аккаунт (member account, иногда называются как sub-account) кроме главного (management account, ранее master account).
▫️ Пока команда выполнения закрытия аккаунта находится в процессе (обычно несколько минут), аккаунт будет в состоянии PENDING_CLOSURE. По её отработке он переходит в состояние SUSPENDED, в котором будет висеть ещё три месяца, прежде, чем окончательно удалится.
▫️ Закрыть сразу все аккаунты не получится. Можно закрыть лишь 10% от общего количества в течение месяца.
▫️ Случайно закрытый нужный аккаунт можно восстановить в течение 90 дней через Support (пока аккаунт находится в состоянии SUSPENDED).

Подробности API для Organizations - CloseAccount:

https://docs.aws.amazon.com/organizations/latest/APIReference/API_CloseAccount.html

Особенности закрытия аккаунтов для AWS GovCloud (US):

https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/Closing-govcloud-account.html

⚠️ На момент публикации документация на команду AWS CLI close-account пока ещё не доступна.

#Organizations

The official AWS blog about closing AWS accounts using the AWS CLI or AWS SDK:

https://aws.amazon.com/blogs/mt/aws-organizations-now-provides-a-simple-scalable-and-more-secure-way-to-close-your-member-accounts/

You can use the AWS Organizations console, CLI or API/SDK to efficiently and more securely close the member accounts in your organization, saving you significant overhead in managing these administrative tasks while ensuring resource efficiency and overall security.

#Organizations

​​Создание AWS аккаунтов через CloudFormation: 🎉

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/AWS_Organizations.html

Не прошло и... эээ... 6... Что ж, лучше поздно, чем никогда.

Type: AWS::Organizations::Account
Properties:
AccountName: String
Email: String
ParentIds:
- String
RoleName: String
Tags:
- Tag

⚠️ Important
▪️ If you include multiple accounts in a single template, you must use the DependsOn attribute on each account resource type so that the accounts are created sequentially. If you create multiple accounts at the same time, Organizations returns an error and the stack operation fails.
▪️ You can't modify the following list of Account resource parameters using CloudFormation updates.
▫️ AccountName
▫️ Email
▫️ RoleName

#CloudFormation #Organizations

🆕 Delegated administrator for AWS Organizations: 🎉

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_delegate_policies.html

Это могло стать одной из самых крутых новостей ещё не начавшегося (или вот-вот) re:Invent 2022. Но нет. Кто, как и я, бросился включать AWS Organizations Delegated administrator в консоли, тоже гарантированно сначала получат:

❌Failed to create delegation policy.
▼API response
This resource-based policy contains an unsupported action.

С энной попытки таки решат, наконец, почитать примеры полиси в документации и получат уже синтаксические ошибки (пропущены запятые в JSON), чем часто грешат свежевыпущенные тексты.

Но даже исправив все ошибки, так нахрапом создать delegated policy не получится. Если коротко, то звёздочка в Actions не прокатит. Вот максимальный набор правил, что можно передать в AWS Organizations Delegated Administrator account:

{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Sid": "MaximumPolicy",
   "Effect": "Allow",
   "Principal": {
    "AWS": "arn:aws:iam::121212121212:root"
   },
   "Action": [
    "organizations:List*",
    "organizations:Describe*",
    "organizations:CreatePolicy",
    "organizations:UpdatePolicy",
    "organizations:DeletePolicy",
    "organizations:AttachPolicy",
    "organizations:DetachPolicy",
    "organizations:EnablePolicyType",
    "organizations:DisablePolicyType",
    "organizations:TagResource",
    "organizations:UntagResource"
   ],
   "Resource": "*"
  }
 ]
}

Ответ в самом начале документа. Это "ненастоящий админ", это policy admin. Права у него чуть больше, нежели были раньше доступны для Delegated админов:

https://docs.aws.amazon.com/organizations/latest/APIReference/action-reference.html#actions-management-or-delegated-admin

Добавились тэги и, собственно, управление Policy. Но это всё. Управлять (CRUD и т.п.) непосредственно AWS аккаунтами, OU — нельзя, только из Management account.

Что ж, пока не всё, что хотелось, но уже хоть что-то. И важно — заложен Resource-Based принцип для работы с AWS Organizations в целом и её частями в частности.

А это значит, что «Лёд тронулся, господа присяжные заседатели!» © 😀

#Organizations

Как посчитать все ресурсы в AWS Organizations и найти проблемные или multi-account strategy в действии:

https://aws.amazon.com/blogs/mt/identify-aws-resources-at-risk-across-your-multi-account-environment-with-aws-organizations-integrations/

#Organizations #multi_account_strategy

Ух ты, случилось чудо, теперь можно поменять root user почту подаккаунтов:

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html

Это значит, что все случайно созданные аккаунты на несуществующую почту теперь можно поправить без техподдержки. Ура!

#Organizations