Example IAM Policies

The following policy can be attached to an IAM group. It lets the IAM user in that group programmatically access a "home directory" in Amazon S3. Each user can perform all Amazon S3 GetObject, ListBucket, PutObject actions on the contents of the folder inside the mybucket bucket—that is, the user can read objects from the folder and write objects to the folder.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["s3:*"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::mybucket"],
      "Condition":{"StringLike":{"s3:prefix":["home/${aws:username}/*"]}}
    },
    {
       "Action":["s3:*"],
       "Effect":"Allow",
       "Resource": ["arn:aws:s3:::mybucket/home/${aws:username}/*"]
    }
  ]
}

The policy uses a policy variable (${aws:username}) that is evaluated at run time and contains the friendly name of the IAM user who made the request.

The following policy expands on the previous one by allowing the user to additionally use the Amazon S3 console to manage the "home directory."

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::*"]
    },
    {
      "Action": ["s3:ListBucket"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::myBucket"],
      "Condition":{"StringEquals":{"s3:prefix":["","home/"],"s3:delimiter":["/"]}}
     },
    {
      "Action": ["s3:ListBucket"],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::myBucket"],
      "Condition":{"StringLike":{"s3:prefix":["home/${aws:username}/*"]}}
    },
    {
       "Action":["s3:*"],
       "Effect":"Allow",
       "Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
		    "arn:aws:s3:::myBucket/home/${aws:username}/*"]
    }
  ]
}

Console-based access is granted by the statements that include the ListAllMyBuckets, GetBucketLocation, and ListBucket actions; these actions are required in order to be able to get to the bucket listings in the console. When the preceding policy is attached to a group, each user in the group can read, write, and list objects only in their home directory. The policy also lets the user see that other user directories exist in the bucket, but users cannot list, read, nor write the contents of the other users' directories.

This policy is for an IAM group that all users in a company belong to. The policy gives users access to only the following:

{
  "Version": "2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Action":["sdb:*","s3:*"],
    "Resource":["arn:aws:sdb:us-east-1:123456789012:domain/mySDBDomain",
      "arn:aws:s3:::my_corporate_bucket",
      "arn:aws:s3:::my_corporate_bucket/*"] 
    },
    {
    "Effect":"Deny",
    "Action":["sdb:*","s3:*"],
    "NotResource":["arn:aws:sdb:us-east-1:123456789012:domain/mySDBDomain",
      "arn:aws:s3:::my_corporate_bucket",
      "arn:aws:s3:::my_corporate_bucket/*"] 
    }
  ]
}

The explicit deny, in conjunction with the NotResource element, helps to ensure that the users can't use any other AWS products or resources than those specified in the policy.

The following policy gives a user permission to programmatically access an Amazon DynamoDB table that has their name. For example, user Bob can perform any Amazon DynamoDB actions in the table named Bob. The policy can be attached to a group that contains users who are allowed to each manage their own Amazon DynamoDB table.

{
  "Version": "2012-10-17",
  "Statement": [{
      "Effect": "Allow",
      "Action": ["dynamodb:*"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/${aws:username}"
    }
  ]
}

The policy uses a policy variable (${aws:username}) that is evaluated at run time and contains the friendly name of the IAM user who made the request.

The following policy might be attached to an IAM group. It gives members of the group permission to programmatically manage their own access keys and certificates.

{
  "Version": "2012-10-17",
  "Statement": [{
      "Effect": "Allow",
      "Action":["iam:*AccessKey*","iam:*SigningCertificate*"],
      "Resource":["arn:aws:iam::123456789012:user/${aws:username}"]
    }
  ]
}

The policy uses wildcards to specify all the IAM actions related to access keys and certificates (the * matches zero or multiple characters). You could instead list each action explicitly. The benefit of using wildcards (*) instead of explicitly listing each action is that if any new IAM actions were to be added that include the string AccessKey or SigningCertificate in their names, this policy would automatically give users access to those new actions to use with his own credentials.

The policy uses a policy variable (${aws:username}) that is evaluated at run time and contains the friendly name of the IAM user who made the request.

This policy lets the IAM user that it's attached to update the membership of the group called MarketingGroup.

{
  "Version": "2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Action":[
       "iam:AddUserToGroup",
       "iam:RemoveUserFromGroup",
       "iam:GetGroup"
    ],
    "Resource":"arn:aws:iam::123456789012:group/MarketingGroup"
    }
  ]
}

This policy is for an IAM group that all users in a company belong to. The policy denies access to all actions in the account unless the request comes from the IP range 192.0.2.0 to 192.0.2.255 or 203.0.113.0 to 203.0.113.255. (The policy assumes the IP addresses for the company are within the specified ranges.) A typical use is for Amazon VPC, where you might expect all your users' requests to originate from a particular IP address, and so you want to deny requests from any other address.

{
  "Version": "2012-10-17",
  "Statement":[{
    "Effect":"Deny",
    "Action":"*",
    "Resource":"*",
    "Condition":{
       "NotIpAddress":{
          "aws:SourceIp":["192.0.2.0/24", "203.0.113.0/24"]
          }
       }
    }
  ]
}

This policy allows the user it is attached to call any IAM action that starts with the literal string Get or List. You probably don't want the user reading the access key IDs of other users, so the policy includes a statement that denies the user access to the ListAccessKeys action.

{
  "Version": "2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Action":[
      "iam:Get*",
      "iam:List*"
      ],
    "Resource":"*"
    },
    {
    "Effect":"Deny",
    "Action":
      [
        "iam:ListAccessKeys",
        "iam:GetUserPolicy",
        "iam:GetGroupPolicy",
        "iam:GetRolePolicy"
      ],
    "Resource":"*"
    }
  ]
}

The benefit of using List* for the action is that if new types of security credentials were added to IAM in the future, the access granted in the policy to all List* actions would automatically allow the user to list those new credentials.