A solid security model is obviously a very big selling point when moving to the cloud. When we’re talking about Identity and Access Management (IAM) in AWS, it’s also important to provision only what we need. After all, we don’t want to give the new junior operator named “Chad” the keys to the kingdom, ultimately resulting in the untimely demise of our entire infrastructure. It’s also important that we provision these credentials in the most logical and easily manageable way.

Let’s take a look at the first of three steps that are involved in the current “preferred practices” of assigning access for AWS users, starting with “Create Policies”.

Step 1. Create Policies.

Here at Stratum we like to use 4 different “standard” policies for our Managed Services Practice. Those policies are: AdministratorAccess, ContributorAccess, OperatorAccess, and ReadOnlyAccess. AdministratorAccess and ReadOnlyAccess come as built-in policies within IAM. The other two, ContributorAccess and OperatorAccess are policies that were created to meet our needs. Here are the definitions of each of the policies:

  • AdministratorAccess (built-in) – Full access to all AWS resources, including billing.
  • ContributorAccess (custom) – Denies access to billing and IAM resources. Full access to all other AWS resources
  • OperatorAccess (custom) – Access to start, stop, and restart AWS Virtual Machines. Also, able to restart Elastic Beanstalk app servers.
  • ReadOnlyAccess (built-in) – Full read-only access to all AWS resources.

Let’s dive in and start building our custom policies.

1.1. Log into AWS and click “Services”. Then, navigate to “IAM”:

1.2. Click “Policies”. Then, click “Create Policy”.

1.3. Click the “JSON” tab, overwrite the current text in the box with this code and click “Review Policy”.

"Version": "2012-10-17",
"Statement": [
"Effect": "Allow",
"Action": "*",

"Resource": "*"
"Effect": "Deny",
"Action": [

"Resource": "*"

1.4. Name the policy “ContributorAccess” and click “Create Policy”

1.5. Repeat the steps 1.1 – 1.4 Using this policy name and JSON:

Name: OperatorAccess


"Version": "2012-10-17",
"Statement": [
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"Resource": "*"

As stated before, these policies should be already created by default in IAM and will be used later:

  • AdministratorAccess
  • ReadOnlyAccess

Now that we’ve created the policies, the next step will be to create the groups and assign said policies to them. This will give us the ability to simply add users to the groups rather than micromanage policies that are attached to the accounts. Attaching policies to user accounts is a common mistake that we see with customers. Groups make adding new users and modifying existing users a breeze in comparison. It’s also worth noting that a user can be a part of multiple groups.

Let’s get started creating groups and assigning the necessary policies.

Step 2. Create Groups and Assign Policies

2.1. While still in the “IAM” service in the AWS portal, click “Groups” and “Create New Group”

2.2. Enter the group name “Administrators” and click “Next Step”

2.3. In the next screen, check the box for “AdministratorAccess” and click “Next Step”.

2.4. Review the Group Name and Policy and click “Create Group”

2.5. Repeat steps 2.1 – 2.4 for the following group names & respective policies:

Group Name: Contributors       -> Policy: ContributorAccess

Group Name: Operators            -> Policy: OperatorAccess

Group Name: Auditors              -> Policy: ReadOnlyAccess

Now that we’ve finished creating the groups and assigning policies, the next obvious step would be to create users (if they don’t currently exist already.) Note that we’re also going to be obtaining the programmatic access key for the accounts. This access key/secret key combination can be generated at any time for the user, but the key generated will only be able to be viewed one time.

Step 3. Create Users

3.1. While still in the “IAM” service in the AWS portal, click “Users” and “Add User”

3.2. Enter the name desired for the user account. Ensure the check box for “Programmatic access” and “AWS Management Console access” are checked. We like to use an Autogenerated password, and require the user to create a new password at next sign-in for security. Click “Next: Permissions”.

3.3. Ensure “Add user to group” is selected. Check the box for the “Administrators” group. Click “Next: Tags”.

3.4. Tag the user if desired (Optional). If you’d like to proceed without a tag, click “Next: Review”.

3.5. Review the user details. When satisfied, click “Create user”.

3.6. Note the “Password”, Access Key ID” and “Secret access key”. Keep These keys somewhere safe.

NOTE: Once you navigate away from this screen, the “Secret access key” and “Password” will be unable to be viewed again.

  •  Repeat steps 3.1 – 3.6 for the remaining users and groups:

User: ContributorUser                  -> Group: Contributors

User: OperatorUser                      -> Group: Operators

User: AuditorUser                         -> Group: Auditors

That’s it! Now that we’ve got the proper IAM policy and credential assignment out of the way, it’s going to be a lot more difficult for “Hurricane Chad” to come through and ruin our day.

AWS IAM Preferred Practices – Group, Policy, and User Identity Assignment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.