DZone
Cloud Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Cloud Zone > Complete AWS IAM Reference

Complete AWS IAM Reference

Working on AWS? Need to write your IAM policies but don't want to think of the hassle? Fear not. Michael Wittig is here to help with his compiled IAM reference guide.

Michael Wittig user avatar by
Michael Wittig
·
Aug. 19, 16 · Cloud Zone · Tutorial
Like (2)
Save
Tweet
3.04K Views

Join the DZone community and get the full member experience.

Join For Free

Writing IAM policies is hard. Following the principle of least privilege is even harder. To write a secure IAM policy you need to know:

  • What actions are needed?
  • Are resource-level permissions supported and on what levels?
  • Are conditions supported to restrict access?

That’s a lot of stuff and the information is spread all across the AWS documentation. That’s why we created the Complete AWS IAM Reference.

Example

For example, you want to allow the launch of new EC2 instances.

First, you need to find out what action is needed. You can use the Complete AWS IAM Reference to search for launch in the description field. Now you know, that the action is called ec2:RunInstances .

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*"
    }
  ]
}


Now you can restrict access further. What options do you have? The Complete AWS IAM Reference shows you that you can use many resource-level permissions. For example, you can restrict that it is only allowed to use a certain AMI like Amazon Linux 2016.03.3 (64bit, gp2).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:us-east-1::image/ami-6869aa05",
        "arn:aws:ec2:us-east-1:$account-id:instance/*",
        "arn:aws:ec2:us-east-1:$account-id:key-pair/*",
        "arn:aws:ec2:us-east-1:$account-id:network-interface/*",
        "arn:aws:ec2:us-east-1:$account-id:placement-group/*",
        "arn:aws:ec2:us-east-1:$account-id:security-group/*",
        "arn:aws:ec2:us-east-1::snapshot/*",
        "arn:aws:ec2:us-east-1:$account-id:subnet/*",
        "arn:aws:ec2:us-east-1:$account-id:volume/*"
      ]
    }
  ]
}


You can take it even further. The Complete AWS IAM Reference shows that you can use a condition to restrict based on instance type. To save money in your dev account you may only allow t2.micro instances.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:us-east-1:$account-id:instance/*"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:InstanceType": "t2.micro"
        }
      }
    }, {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:us-east-1::image/ami-6869aa05",
        "arn:aws:ec2:us-east-1:$account-id:key-pair/*",
        "arn:aws:ec2:us-east-1:$account-id:network-interface/*",
        "arn:aws:ec2:us-east-1:$account-id:placement-group/*",
        "arn:aws:ec2:us-east-1:$account-id:security-group/*",
        "arn:aws:ec2:us-east-1::snapshot/*",
        "arn:aws:ec2:us-east-1:$account-id:subnet/*",
        "arn:aws:ec2:us-east-1:$account-id:volume/*"
      ]
    }
  ]
}


Keep in mind that different resource-level permissions support different service specific conditions. That’s why the following policy is not working:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:us-east-1::image/*",
        "arn:aws:ec2:us-east-1:$account-id:instance/*"
        "arn:aws:ec2:us-east-1:$account-id:key-pair/*",
        "arn:aws:ec2:us-east-1:$account-id:network-interface/*",
        "arn:aws:ec2:us-east-1:$account-id:placement-group/*",
        "arn:aws:ec2:us-east-1:$account-id:security-group/*",
        "arn:aws:ec2:us-east-1::snapshot/*",
        "arn:aws:ec2:us-east-1:$account-id:subnet/*",
        "arn:aws:ec2:us-east-1:$account-id:volume/*"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:InstanceType": "t2.micro"
        }
      }
    }
  ]
}


Summary

For every AWS service, different actions are available. Depending on the action you can use resource-level permissions and sometimes also conditions. The Complete AWS IAM Reference collects all that information and makes it accessible to you.

AWS

Published at DZone with permission of Michael Wittig. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Design a CRUD Web Service for Inheritable Entity
  • Java: Why Core-to-Core Latency Matters
  • Comparing Distributed Databases
  • 11 Best Practices to Do Functional Testing on the Cloud

Comments

Cloud Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo