AWS- Limiting resource access for member of organisational accounts

Question

We have certain AWS labs which we offer to our customers. Every time a user opens the lab, a new member account is created and added to the organisational account.

This only happens the first time when a user logs into the lab. This member account has no resource restrictions and can do anything the user wants.

For eg.

1. Launching any type and number of ec2 instances.
2. Create as many s3 buckets as possible and upload files of any size.
3. Launch any type of RDS and ElastiCache clusters.

This has been creating a huge problem for us and we want to limit resources depending upon what is required to perform in the labs.

After a lot of research, I came up with this:

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.

Managing OU's

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

Moving accounts from one OU to another OU A program can be written to list account under the "working accounts OU"

https://docs.aws.amazon.com/cli/latest/reference/organizations/list-accounts-for-parent.html

From the output, filter out the "JoinedTimestamp" parameter and perform move operation on accounts which are older than xx days.

https://docs.aws.amazon.com/cli/latest/reference/organizations/move-account.html

I want to know from experienced AWS architects whether the second part of the "Organisational Unit" is possible.

If yes, can someone help me to figure out how to achieve it as I don't have much programming experience.

Answer 1

Your approach is valid. You could look at using IAM roles rather than SCP for pretty much of that, though SCP is central control so all you have to do is put the account in an OU, so better than IAM policy for your situation I think.

You're probably going to want a "deny" and "not action" for things like IAM / S3 that rely on other regions - eg S3 / IAM. Note that this can be quite a bit list. Then a whitelist for your region of allowed services - there's a lot you might need, but you'll find them.

{
  "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:*"
  }
}

Enforcing only specific AMIs is quite fiddly. You need to create a policy which lists them by AMI ID, then you need to manually update the policy every time a new AMI is released.

I can't help with your moving OUs question sorry. Alternate approaches here would be to attach a "deny all" policy to the account in SCP directly as it will override the allow permission, or adding a "deny all" permission to their IAM role.