Advanced Identity: Organizations and Identity Center

In part two we had one account and a few users. Now imagine a company with fifty accounts and five hundred employees: creating a user in each account for each person would be a nightmare, and one mistake could reach everything.

This part covers the tools for that scale, and it completes IAM with what we left out at the start.

AWS Organizations #

Organizations gathers many accounts under one management account, arranged in organizational units (OUs).

Why many accounts, not one big account?

• Isolation: a mistake or breach in the development account doesn't reach production.
• Clear costs: each account shows its team's bill.
• Limits: each account has its own service quotas.

And what do you get from Organizations?

• Consolidated billing: one invoice, and combined usage reaches volume discounts faster. Savings Plans and Reserved Instances can also be shared across accounts.
• Centralized management: creating accounts by API, and one CloudTrail trail for everyone.
• Policies: rules applying to whole groups of accounts.

Organization policies #

Service Control Policies (SCPs) #

The key point: an SCP doesn't grant anything. It only sets a limit, and each user still needs an IAM permission. It's a ceiling on what's allowed:

• Attached to an OU, it applies to everything beneath it, and each level must allow the action.
• It doesn't affect the management account, so don't run workloads there.
• It applies to everyone in a member account, including that account's root user.

For example, this SCP blocks work outside two Regions, except for global services:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "OnlyTwoRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["me-central-1", "eu-west-1"] }
    }
  }]
}

Conditions in IAM policies #

A policy's Condition element narrows when a permission applies. Some common ones:

The last one is a gift for shared buckets. Instead of listing fifty accounts in a bucket policy, one line allows your whole organization:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::shared-files/*",
  "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } }
}

A classic S3 mistake #

S3 actions work at two levels, and each needs its own ARN:

Put the wrong one in and you get AccessDenied, however right the policy looks. We'll test this in the hands-on.

A role or a resource policy? #

To let a user in account A reach something in account B, you have two ways:

Behind every assumed role is AWS STS (Security Token Service). It hands out the temporary credentials, which expire by themselves. This is how cross-account access works without sharing long-term keys: a user or service calls AssumeRole, STS checks the role's trust policy, and returns keys that work for a limited time.

Permissions boundaries #

You want team leads to create roles for their services, without being able to give anyone more than they should have. A permissions boundary sets the maximum for a particular user or role, and like an SCP, it grants nothing.

The effective permissions are what's allowed by the identity policy and the boundary and the SCP together. It's a good way to delegate safely.

How does AWS decide? #

Every request goes through this reasoning. This is a simplified version:

Remember three rules: an explicit Deny always wins, anything not allowed is denied, and within one account, a resource policy can grant access by itself in many cases.

IAM Identity Center: one sign-in #

Instead of a user in every account, IAM Identity Center gives each employee one sign-in and a portal listing the accounts and roles available to them, and they get temporary credentials with no permanent keys.

For the CLI, aws configure sso signs you in through your browser and gives you temporary credentials. This is the recommended way for people to work with AWS these days, in place of IAM users with long-term keys.

Federation: identities from outside #

Federation means people or systems sign in with an identity that lives outside AWS and receive temporary credentials, with no IAM user to create. Your choice depends on who's signing in:

Active Directory on AWS #

Many companies keep their users in Microsoft Active Directory. AWS Directory Service connects it to AWS:

AWS Control Tower #

Setting all of this up by hand takes weeks. Control Tower builds a best-practice landing zone over Organizations, including log and audit accounts, and it adds:

• Account Factory: creating new accounts with ready settings.
• Controls: preventive through SCPs, detective through Config, and proactive that check resources before they're created.
• A dashboard: showing who's compliant at a glance.

If you're starting a multi-account environment from scratch, start here.

Hands-on: testing policies without touching anything #

The policy simulator evaluates a policy without creating anything or running the action, which is great for learning. From CloudShell, write a policy allowing S3 and EC2, and a boundary allowing S3 only:

cat > identity.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:*", "ec2:*"],
    "Resource": "*"
  }]
}
EOF

cat > boundary.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:*",
    "Resource": "*"
  }]
}
EOF

Test three actions with the policy alone:

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --action-names s3:GetObject ec2:RunInstances iam:CreateUser \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

S3 and EC2 show allowed, and IAM shows implicitDeny, because nothing allows it. Now add the boundary:

aws iam simulate-custom-policy --policy-input-list file://identity.json \
  --permissions-boundary-policy-input-list file://boundary.json \
  --action-names s3:GetObject ec2:RunInstances \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

EC2 has now become implicitDeny, even though the policy allows it. Now see that Deny always wins, by adding an explicit deny on deleting buckets:

cat > deny.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "s3:DeleteBucket",
    "Resource": "*"
  }]
}
EOF

aws iam simulate-custom-policy \
  --policy-input-list file://identity.json file://deny.json \
  --action-names s3:GetObject s3:DeleteBucket \
  --query "EvaluationResults[].[EvalActionName,EvalDecision]" --output table

s3:GetObject stays allowed, and s3:DeleteBucket shows explicitDeny, even though the first policy allows s3:*. Try a condition next: access from the office network only, testing from two addresses:

cat > office.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "*",
    "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
  }]
}
EOF

for ip in 203.0.113.10 198.51.100.7; do
  aws iam simulate-custom-policy --policy-input-list file://office.json \
    --action-names s3:GetObject \
    --context-entries "ContextKeyName=aws:SourceIp,ContextKeyValues=$ip,ContextKeyType=ip" \
    --query "EvaluationResults[0].EvalDecision" --output text
done

The first address is allowed, and the second is implicitDeny. Finally, the classic S3 mistake, a list permission with the object's ARN:

cat > list.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::shop/*"
  }]
}
EOF

aws iam simulate-custom-policy --policy-input-list file://list.json \
  --action-names s3:ListBucket --resource-arns arn:aws:s3:::shop \
  --query "EvaluationResults[0].EvalDecision" --output text

It gives implicitDeny. The policy looks right, but the permission applies to the bucket, not to what's in it. Change the resource to arn:aws:s3:::shop and try again, and you'll get allowed.

Summary #

• Organizations gathers accounts under one bill, and SCPs set a ceiling that grants nothing.
• Conditions narrow permissions by network, Region, MFA and tags, and aws:PrincipalOrgID opens access to your organization only.
• A role gives up your original permissions, and a resource policy keeps them.
• A permissions boundary delegates safely, and an explicit Deny always wins.
• Identity Center gives one sign-in with temporary credentials, and Control Tower builds it all from best practices.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

You've controlled who reaches your data. What if someone reaches it anyway, or attacks your site from outside? In part twenty-seven we cover encryption, secrets and threat protection.