Skip to content

Instantly share code, notes, and snippets.

@apolloclark

apolloclark/aws iam architecture.md

Last active May 17, 2023 06:05
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save apolloclark/f17e7fea1841a5d0f6125808f8654f2c to your computer and use it in GitHub Desktop.
Save apolloclark/f17e7fea1841a5d0f6125808f8654f2c to your computer and use it in GitHub Desktop.
Download ZIP
Raw
aws iam architecture.md

AWS IAM Multi-Tenancy, Multi-Account, Architectures

This article is an overview of IAM implementations, focused on multi-tenancy deployments.

 

Terminology

  • IAM User - IAM access account.
  • IAM Group - A grouping of IAM Users.
  • IAM Role - temporary IAM access account; cannot be added to an IAM Group.
  • IAM Instance Profile - IAM access account, linked to an EC2 instance, using an IAM Role.
  • IAM AWS Managed Policy - shared access policy managed by AWS, course grained.
  • IAM Customer Managed Policy - shared access policy managed by the AWS account owner.
  • IAM Inline Policy - unique access policy linked to a single IAM User, or IAM Group, or IAM Role.
Identities (Users, Groups, and Roles)
Overview of Access Management: Permissions and Policies
IAM Best Practices
IAM Policy Elements: Variables and Tags
Variables in AWS Access Control Policies
IAM Managed Policies, and Inline Policies
 

Limitations

  • AWS Accounts are not designed for multi-tenancy
  • IAM Inline Policies are very difficult to manage
  • 1500 IAM Customer Managed Policies, per account
  • 5000 IAM Users, per account
  • 300 IAM Groups, per account
  • 10 IAM Groups, per IAM User
  • 1000 IAM Roles, per account
  • 1000 IAM Instance Profiles, per account
  • 1 IAM Role, per IAM Instance Profile
  • 10 Managed Policies, per IAM Role
  • 10 Managed Policies, per IAM User
  • 10 Managed Policies, per IAM Group
  • S3 bucket names must be DNS compatible, not using (: @ ,)
  • S3 bucket policy conditionals cannot reference ResourceTag
Limitations on IAM Identities and Objects
S3 Bucket Restrictions and Limitations
 

Architectures

1. EC2 -> IAM Instance Profile -> IAM Role -> AWS Resource

Pros:

  • Easy to implement.
  • Does not embed IAM User Access Key + Secret Key on EC2 instance.
Cons:
  • IAM Policy var ${aws:username} is not available
  • IAM Policy var ${aws:userid} is set to "role-id:ec2-instance-id"
  • Any policy using ${aws:userid} are linked to individual EC2 instances.
  • Requires redundant IAM Inline Policies, per tenant / customer.
  • Need to link IAM Inline Policies to multiple IAM Roles.

2. EC2 -> IAM User -> IAM Role -> AWS Resource

Pros:

  • Easy to implement.

Cons:

  • Embeds IAM User Access Key + Secret Key on EC2 instance.
  • IAM Policy var ${aws:username} is not available.
  • IAM Policy var ${aws:userid} is set to "role-id:role-name"
  • The format "role-id:role-name", cannot be used for dedicated tenant / customer S3 bucket names.
  • Requires redundant IAM Inline Policies, per tenant / customer.
  • Need to link IAM Inline Policies to multiple IAM Roles.

3. EC2 -> IAM User -> AWS Resource

Pros:

  • Easy to implement.
  • IAM Policy var ${aws:username} is available.
  • IAM Policy var ${aws:userid} is available.
  • Can use IAM Customer Managed Policy, with dynamic variables.
  • No need to create multiple tenant / customer redundant IAM Inline Policies.

Cons:

  • Embeds IAM User Access Key + Secret Key on EC2 instance.
  • Need to match IAM User Name, to either Resource Tag or Resource Name.
  • Need to link IAM Customer Shared Policies to multiple IAM Users.
 

4. EC2 -> IAM User -> IAM Group -> AWS Resource

Pros:

  • IAM Policy var ${aws:username} is available.
  • IAM Policy var ${aws:userid} is available.
  • Can use IAM Customer Managed Policy, with dynamic variables.
  • No need to create multiple tenant / customer redundant IAM Inline Policies.
  • Only need a limited number of account shared IAM Groups.
  • Only need to link IAM Policies to limited number of IAM Groups.

Cons:

  • Embeds IAM User Access Key + Secret Key on EC2 instance.
  • Need to match IAM User Name, to either Resource Tag or Resource Name.
 

Example Policies

S3 Bucket Access, per IAM User Name

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_s3_federated-home-directory-console.html

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::${aws:username}"
      ]
    }
  ]
}

RDS, allow full access, based on ResourceTag


https://docs.amazonaws.cn/en_us/IAM/latest/UserGuide/reference_policies_examples_rds_tag-owner.html

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {"rds:db-tag/IAMUserName": "${aws:username}"}
      }
    }
  ]
}

Tools

  • duosecurity / CloudTracker - helps you find over-privileged IAM users and roles by comparing CloudTrail logs with current IAM policies.
  • Netflix / policyuniverse - provides classes to parse AWS IAM and Resource Policies.
  • Netflix / repokid - uses Access Advisor to remove permissions granting access to unused services from the inline policies of IAM roles in an AWS account.

References

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment