У нас есть определенные лаборатории AWS, которые мы предлагаем нашим клиентам. Каждый раз, когда пользователь открывает лабораторию, создается новая учетная запись участника, которая добавляется к учетной записи организации.
Это происходит только в первый раз, когда пользователь входит в лабораторию. Эта учетная запись участника не имеет ограничений по ресурсам и может делать все, что угодно пользователю.
Например,
Это создает для нас огромную проблему, и мы хотим ограничить ресурсы в зависимости от того, что требуется для выполнения в лабораторных условиях.
После долгих исследований я пришел к следующему:
Resource restrictions on OU level using SCP:
1. Deny every service by default.
2. Allow only those services which are used in tasks.
3. Allow those services in 1 particular region only (For e.g. us-east-1)
4. Limit what type of instances can be launched (For e.g. t2.micro only)
5. Limit specific AMI's using which instances can be launched (For e.g. Only free AMI's like ubuntu and linux AMI's, no windows AMI's)
6. Policy for limiting s3 bucket sizes is not possible.
Organisation account removal:
1. Can't remove member account if they don't have required information to become standalone account.
2. This information includes:
- AWS Customer Agreement
- choose a support plan
- provide and verify the required contact information
- provide a current payment method
3. This can't be automated so the idea is to create 2 OU's "Organisational units".
- Working accounts
- Disabled accounts
4. 1st OU will have required permissions to perform the lab tasks only (Principle of least privilege)
5. 2nd OU will have no permissions, Deny All for all services and actions.
Управление OU
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html
Перенос учетных записей из одного OU в другое OU Можно написать программу, чтобы перечислить учетную запись в «OU рабочих учетных записей».
https://docs.aws.amazon.com/cli/latest/reference/organizations/list-accounts-for-parent.html
Из выходных данных отфильтруйте параметр «JoinedTimestamp» и выполните операцию перемещения для учетных записей старше xx дней.
https://docs.aws.amazon.com/cli/latest/reference/organizations/move-account.html
Я хочу узнать от опытных архитекторов AWS, возможна ли вторая часть «Организационной единицы».
Если да, может ли кто-нибудь помочь мне выяснить, как этого добиться, поскольку у меня нет большого опыта программирования.
Ваш подход верен. Вы могли бы рассмотреть использование ролей IAM, а не SCP для большей части этого, хотя SCP является центральным элементом управления, поэтому все, что вам нужно сделать, это поместить учетную запись в OU, что, я думаю, лучше, чем политика IAM для вашей ситуации.
Вы, вероятно, захотите «запретить» и «не действовать» для таких вещей, как IAM / S3, которые зависят от других регионов - например, S3 / IAM. Обратите внимание, что это может быть довольно длинный список. Затем создайте белый список для вашего региона разрешенных услуг - вам может понадобиться многое, но вы их найдете.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOutsideSingapore",
"Effect": "Deny",
"NotAction": [
"iam:*",
"aws-portal:*",
"organizations:*",
"s3:PutEncryptionConfiguration"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"ap-southeast-1"
]
}
}
},
{
"Sid": "WhitelistAllowedServices",
"Effect": "Allow",
"Action": [
"ec2:*",
"autoscaling:*"
}
}
Применение только определенных AMI довольно утомительно. Вам необходимо создать политику, в которой они будут перечислены по идентификатору AMI, затем вам необходимо вручную обновлять политику каждый раз, когда выпускается новый AMI.
Я не могу помочь с вашим вопросом о перемещении подразделений, извините. Альтернативным подходом здесь было бы присоединение политики «запретить все» к учетной записи в SCP напрямую, поскольку она переопределит разрешающее разрешение, или добавление разрешения «запретить все» к их роли IAM.