To create our sessions, we are going to use an open source script created by the same author as Scout2, we will clone the repository and install the dependencies as follows:
$ git clone https://github.com/nccgroup/AWS-recipes $ cd AWS-recipes $ pip install -r requirements.txt
The script we want to use is in the Python directory:
$ cd Python
The script we want to run is called aws_recipes_init_sts_session.py:
$ aws_recipes_init_sts_session.py Saved STS credentials expired on 2017-02-12 10:28:48+00:00 Enter your MFA code (or 'q' to abort): 446054
We assume here that you previously went through the MFA initialization steps as requested in Chapter 2, Deploying Your First Web Application. If you haven't done it yet, you can use the AWS console to initialize your MFA device or use the script aws_iam_enable_mfa.py present in that folder.
Once the script has run, this script will create a new session giving you a 12-hour window to work with the AWS CLI.
At that point, you can start creating more groups, and move users to those new groups. For example, you may create a group for accounting and give the finance team access to billing information by creating a policy with the following statement:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aws-portal:ViewUsage",
"aws-portal:ViewBilling"
],
"Resource": "*"
}
]
}
Giving AWS users admin access to staging but not to production
With the system we created, we can enforce permissions on a per-service basis. Depending on the development workflow you want to provide for the different groups of developers, you may need to provide admin access to your staging resources. The problem with that system is that IAM is a global service and therefore if you give a user the ability to make IAM changes, for example, you give them the ability to be an administrator of all environments as they can make changes to the policy. For a more granular approach to IAM user permissions, you can rely on a feature called cross-account access. At a high level, the idea consists of creating a new AWS account for your staging environment and giving administrator permissions to every engineer in that account. Then on your production AWS account, you will use the IAM service and its AssumeRole feature to grant a different set of permissions to those users coming from your staging account. You can read more on that topic at http://amzn.to/2rGeSdC.
With the system we created, we can enforce permissions on a per-service basis. Depending on the development workflow you want to provide for the different groups of developers, you may need to provide admin access to your staging resources. The problem with that system is that IAM is a global service and therefore if you give a user the ability to make IAM changes, for example, you give them the ability to be an administrator of all environments as they can make changes to the policy. For a more granular approach to IAM user permissions, you can rely on a feature called cross-account access. At a high level, the idea consists of creating a new AWS account for your staging environment and giving administrator permissions to every engineer in that account. Then on your production AWS account, you will use the IAM service and its AssumeRole feature to grant a different set of permissions to those users coming from your staging account. You can read more on that topic at http://amzn.to/2rGeSdC.
Now that we know how to manage users and user groups, we will focus on service permissions.