IAM Users Best Practices – Excerpts from AWS Documentation!

Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
Permissions can be assigned in two ways: as user-based permissions or as resource-based permissions. User-based permissions are attached to an IAM user, group, or role and let you specify what that user, group, or role can do. For example, you can assign permissions to the IAM user named Bob, stating that he has permission to use the Amazon Elastic Compute Cloud (Amazon EC2) RunInstances action and that he has permission to get items from an Amazon DynamoDB table named MyCompany. The user Bob might also be granted access to manage his own IAM security credentials.
Resource-based permissions are attached to a resource like an Amazon S3 bucket or an Amazon SNS topic. They let you specify who has access to the resource and what actions they can perform on it.
When you add a new user we need to check if the policies that we intend to give the user are already existing as part of the Group or not. If so then take the Group that mostly match with the User and remaining policies of the group will be made as Deny for that particular user.

IAM Policies:

To assign permissions to a user, group, role, or resource, you create a policy, which is a document that explicitly lists permissions. In its most basic sense, a policy lets you specify the following:

Actions: what actions you will allow. Each AWS service has its own set of actions. For example, you might allow a user to use the Amazon S3 ListBucket action, which returns information about the items in a bucket. Any actions that you don’t explicitly allow are denied.

Resources: which resources you allow the action on. For example, what specific Amazon S3 buckets will you allow the user to perform the ListBucket action on? Users cannot access any resources that you have not explicitly granted permissions to.

Effect: what the effect will be when the user requests access—either allow or deny. Because the default is that resources are denied to users, you typically specify that you will allow users access to resource.

Policies are documents that are created using JSON. A policy consists of one or more statements, each of which describes one set of permissions. Here’s an example of a simple policy.

{
“Version”:”2012-10-17″,
“Statement”:[{
“Effect”:”Allow”,
“Action”:”s3:ListBucket”,
“Resource”:”arn:aws:s3:::example_bucket”
}]
}
To specify resource-based permissions, you can attach a policy to the resource, such as an Amazon SNS topic or Amazon S3 bucket. In that case, the policy has to include information about who is allowed to access the resource, known as the principal. (For user-based policies, the principal is the IAM user that the policy is attached to, or the user who gets the policy from a group.)

The following example shows a policy that might be attached to an Amazon S3 bucket and that lets IAM user Bob in account 123456789012 perform any actions in mybucket.

{
“Version”:”2012-10-17″,
“Id”: “S3-Account-Permissions”,
“Statement”: [
{
“Sid”: “1”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: [
“arn:aws:iam::123456789012:user/Bob”
]
},
“Action”: “s3:*”,
“Resource”: “arn:aws:s3:::mybucket/*”
}
]
}

IAM Policy Evaluation Logic
IAMEvaluationLogic

1. The decision starts by assuming that the request will be denied.

2. The enforcement code evaluates all user-based and resource-based policies that are applicable to the request (based on the resource, principal, action, and conditions).

The order in which the enforcement code evaluates the policies is not important.

3. In all those policies, the enforcement code looks for an explicit deny instruction that would apply to the request.

If the code finds even one explicit deny that applies, the code returns a decision of “deny” and the process is finished.

4. If no explicit deny is found, the code looks for any “allow” instructions that would apply to the request.

If it finds even one explicit allow, the code returns a decision of “allow” and the service continues to process the request.

5. If no allow is found, the final decision is “deny.”
The distinction between a request being denied by default and an explicit deny in a policy is important. By default, a request is denied, but this can be overridden by an allow. In contrast, if a policy explicitly denies a request, that deny can’t be overridden.

Use roles for applications that run on Amazon EC2 instances

Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn’t a user or group. Roles also don’t have their own permanent set of credentials the way IAM users do. Instead, a role is assumed by other entities. Credentials are then either associated with the assuming identity, or IAM dynamically provides temporary credentials (in the case of Amazon EC2).

When you launch an Amazon EC2 instance, you can specify a role for the instance as a launch parameter. Applications that run on the EC2 instance can use the role’s credentials when they access AWS resources. The role’s permissions determine what the application is allowed to do.
Delegate by using roles instead of by sharing credentials
You might need to allow users from another AWS account to access resources in your AWS account. If so, don’t share security credentials, such as access keys, between accounts. Instead, use IAM roles. You can define a role that specifies what permissions the IAM users in the other account are allowed, and from which AWS accounts IAM users are allowed to assume the role.
Rotate credentials regularly
Change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. That way, if a password is compromised without your knowledge, you limit how long the password can be used to access your resources.
To make it easier to rotate credentials, let your users manage their own passwords.
Use policy conditions for extra security
To the extent that it’s practical, define the conditions under which the policy allows access to a resource. For example, you can write conditions to specify a range of allowable IP addresses for a request, or you can specify that a request is allowed only within a specified date range or time range. You can also set conditions that require the use of SSL or MFA. For example, you can require that a user has authenticated with an MFA device in order to be allowed to terminate an Amazon EC2 instance. The more explicitly you can define when resources are available (and otherwise unavailable), the safer your resources will be.
As an example, let’s say you want to let user John access your Amazon SQS queue under the following conditions:

The time is after 12:00 noon on 8/16/2013

The time is before 3:00 p.m. on 8/16/2013

The request (IAM or SQS) or message (SNS) comes from an IP address within the range 192.0.2.0 to 192.0.2.255 or 203.0.113.0 to 203.0.113.255.

Your condition block has three separate conditions, and all three of them must be met for John to have access to your queue, topic, or resource.

The following shows what the condition block looks like in your policy. The two values for aws:SourceIp are evaluated using OR. The three separate conditions are evaluated using AND.

“Condition” : {
“DateGreaterThan” : {
“aws:CurrentTime” : “2013-08-16T12:00:00Z”
},
“DateLessThan”: {
“aws:CurrentTime” : “2013-08-16T15:00:00Z”
},
“IpAddress” : {
“aws:SourceIp” : [“192.0.2.0/24”, “203.0.113.0/24”]
}
}
Available Keys for Conditions

Keys in a condition represent values that are part of the request sent by a user. AWS provides the following predefined keys for all AWS services that support the IAM for access control:

aws:CurrentTime—To check for date/time conditions.

aws:EpochTime—To check for date/time conditions using a date in epoch or UNIX time.

aws:MultiFactorAuthAge—To check how long ago (in seconds) the MFA-validated security credentials making the request were issued using Multi-Factor Authentication (MFA). Unlike other keys, if MFA is not used, this key is not present (see Existence of Condition Keys, Numeric Conditions and Using Multi-Factor Authentication (MFA) Devices with AWS.

aws:principaltype—To check the type of principal (user, account, federated user, etc.) for the current request.

aws:SecureTransport—To check whether the request was sent using SSL.

aws:SourceArn—To check the source of the request, using the Amazon Resource Name (ARN) of the source. (This value is available for only some services. For more information, see Amazon Resource Name (ARN) under “Element Descriptions” in the Amazon Simple Queue Service Developer Guide.)

aws:SourceIp—To check the requester’s IP address.

aws:UserAgent—To check the requester’s client application.

aws:userid—To check the requester’s user ID.

aws:username—To check the requester’s user name.

Note
Key names are case sensitive.
Some AWS services also provide service-specific keys. For example, for information about keys that you can use in policies for Amazon S3 resources, see Amazon S3 Policy Keys in the Amazon Simple Storage Service Developer Guide. For keys that are available in other services, see the documentation for the individual services.

Permissions Required for Using Roles with Amazon EC2

To launch an instance with a role, the developer must have permission to launch Amazon EC2 instances and permission to pass IAM roles.

The following sample policy allows users to use the AWS Management Console to launch an instance with a role. The policy allows a user to pass any role and to perform all Amazon EC2 actions by specifying an asterisk (*). The ListInstanceProfiles action allows users to view all the roles that are available on the AWS account.

Example Policy that grants a user permission to launch an instance with any role by using the Amazon EC2 console

{
“Version”: “2012-10-17”,
“Statement”: [{
“Effect”:”Allow”,
“Action”:”iam:PassRole”,
“Resource”:”*”
},
{
“Effect”:”Allow”,
“Action”:”iam:ListInstanceProfiles”,
“Resource”:”*”
},
{
“Effect”:”Allow”,
“Action”:”ec2:*”,
“Resource”:”*”
}]
}
Restricting Which Roles Can Be Passed to Amazon EC2 Instances (Using PassRole)

You can use the PassRole permission to prevent users from passing a role to Amazon EC2 that has more permissions than the user has already been granted, and then running applications under the elevated privileges for that role. In the role policy, allow the PassRole action and specify a resource (such as arn:aws:iam::111122223333:role/ec2Roles/*) to indicate that only a specific role or set of roles can be passed to an Amazon EC2 instance.

The following sample policy allows developers to use the Amazon EC2 API to launch an instance with a role. The Resource element specifies an Amazon Resource Name (ARN). By specifying the ARN, the policy grants the user to pass only the Get-pics role.

Example Policy that grants a user permission to launch an instance with a role by using the Amazon EC2 API

{
“Version”: “2012-10-17”,
“Statement”: [{
“Effect”:”Allow”,
“Action”:”ec2:RunInstances”,
“Resource”:”*”
},
{
“Effect”:”Allow”,
“Action”:”iam:PassRole”,
“Resource”:”arn:aws:iam::123456789012:role/Get-pics”
}]
}

References:
http://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html
http://docs.aws.amazon.com/IAM/latest/UserGuide/role-usecase-ec2app.html

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s