​​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

Student SCP policy — политика для защиты аккаунтов, предназначенных для изучения AWS.

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StudentSCPpolicy",
      "Effect": "Deny",
      "Action": [
        "athena:CreateCapacityReservation",
        "aws-marketplace:AcceptAgreementRequest",
        "aws-marketplace:CreateAgreementRequest",
        "aws-marketplace:CreatePrivateMarketplaceRequests",
        "aws-marketplace:Subscribe",
        "backup:CreateLogicallyAirGappedBackupVault",
        "backup:PutBackupVaultLockConfiguration",
        "bedrock:CreateFoundationModelAgreement",
        "bedrock:CreateProvisionedModelThroughput",
        "cloudfront:CreateSavingsPlan",
        "devicefarm:PurchaseOffering",
        "directconnect:ConfirmCustomerAgreement",
        "dynamodb:PurchaseReservedCapacityOfferings",
        "ec2:AcceptReservedInstancesExchangeQuote",
        "ec2:CreateCapacityReservation",
        "ec2:CreateCapacityReservationFleet",
        "ec2:CreateReservedInstancesListing",
        "ec2:LockSnapshot",
        "ec2:PurchaseCapacityBlock",
        "ec2:PurchaseHostReservation",
        "ec2:PurchaseReservedInstancesOffering",
        "ec2:PurchaseScheduledInstances",
        "eks:CreateEksAnywhereSubscription",
        "elasticache:PurchaseReservedCacheNodesOffering",
        "elemental-appliances-software:CreateOrderV1",
        "elemental-appliances-software:SubmitOrderV1",
        "es:PurchaseReservedElasticsearchInstanceOffering",
        "es:PurchaseReservedInstanceOffering",
        "freertos:CreateSubscription",
        "glacier:CompleteVaultLock",
        "glacier:PurchaseProvisionedCapacity",
        "groundstation:ReserveContact",
        "iottwinmaker:UpdatePricingPlan",
        "iq:ApprovePaymentRequest",
        "mediaconnect:PurchaseOffering",
        "medialive:PurchaseOffering",
        "memorydb:PurchaseReservedNodesOffering",
        "organizations:LeaveOrganization",
        "organizations:DeleteOrganization",
        "organizations:RemoveAccountFromOrganization",
        "outposts:CreateOrder",
        "panorama:ProvisionDevice",
        "quicksight:Subscribe",
        "quicksight:UpdateSPICECapacityConfiguration",
        "rbin:LockRule",
        "rds:PurchaseReservedDBInstancesOffering",
        "redshift:AcceptReservedNodeExchange",
        "redshift:PurchaseReservedNodeOffering",
        "route53domains:AcceptDomainTransferFromAnotherAwsAccount",
        "route53domains:RegisterDomain",
        "route53domains:RenewDomain",
        "route53domains:TransferDomain",
        "route53domains:TransferDomainToAnotherAwsAccount",
        "s3:PutBucketObjectLockConfiguration",
        "s3:PutObjectLegalHold",
        "s3:PutObjectRetention",
        "s3-object-lambda:PutObjectLegalHold",
        "s3-object-lambda:PutObjectRetention",
        "savingsplans:CreateSavingsPlan",
        "shield:CreateSubscription",
        "snowball:CreateJob",
        "snowball:CreateLongTermPricing"
      ],
      "Resource": "*"
    }
  ]
}

Student SCP policy не имеет ограничений на адекватные действия и создание любых ресурсов, что могут потребоваться для изучения. Поэтому предполагается обязательная настройка AWS Budgets и алертов.

Если требуется более жёсткие ограничений, то нужно использовать Allow List Approach — вместо запрещения проблемных лишь разрешать нужные.

#security #organizations #scp

Как перенести AWS аккаунт из одной AWS Organization в другую.

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

#Organizations

Resource control policies — RCPs

https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/

Как SCP, но для ресурсов.

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

Действует на уровне AWS Organizations. Перекрывает IAM права, как и SCP. В результате с помощью RCP можно просто запретить доступ к S3 бакетам извне организации.

RCP vs SCP — SCP для ролей, RCP для ресурсов, в чём-то перекрывают друг друга, RCP важное дополнение SCP.

На текущий момент поддерживает лишь следующие ресурсы:

• S3
• STS
• KMS
• SQS
• Secrets Manager

⚠️ Как и SCP, RCP не применяется к Management (главному, root) аккаунту.

#RCP #Organizations

Root access management

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html

С помощью Root access management можно централизованно на уровне всей организации выключить root-пользователей оптом сразу во всех под-аккаунтах.

Чтобы выполнить действия, требующие именно root-юзера, например, снятие неудачно применённой S3 bucket policy, то используем perform a privileged task. Когда можно переключиться из главного аккаунта в под-аккаунт в специальную "short-term" root-сессию.

Таким образом у вас (у нас) появляется официальная возможность послать всех безопасников с их проверками на root-пользователей нафиг упростить механизмы соответствия compliance требованиям.

P.S. Кто не может найти у себя такую картинку — это доступно только в главном (management) аккаунте или аккаунте delegated administrator for IAM.

#IAM #Organizations #root

AWS Organizations: Как управлять сотнями аккаунтов без головной боли

https://www.youtube.com/watch?v=7bBHGCG0Dys

#organizations

Специально для счастливых обладателей нового Free Tier (заведённого после July 15, 2025):

НЕ следуйте рекомендациям в AWS Console по включению AWS Organizations для создания IAM Identity Center! Иначе ваш план автоматически будет проапгрейжен на платную версию (Paid plan).

Для включения IAM Identity Center используйте его отдельный инстанс в аккаунте. Для этого выбирайте вторую опцию мелким текстом.

P.S. Кто пропустил — можно создавать IAM Identity Center в отдельных аккаунтах кроме одного общего на AWS Organization:

https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-center-instances.html

#FreeTier #organizations #IAM

Multi-party approval — когда нужно реализовать подтверждение на операцию в AWS от нескольких человек:

https://docs.aws.amazon.com/mpa/latest/userguide/

#security #organizations