IAM policies and trust polices

If you want to grant a user the ability to pass any of an approved set of roles to the Amazon EC2 service upon launching an instance, you need to have these three elements:

1. An IAM permissions policy attached to the role that determines what the role can do.

2. A trust policy for the role that allows the service to assume the role.

3. An IAM permissions policy attached to the IAM user that allows the user to pass only those roles that are approved.

A trust policy is defined for the role that allows the service to assume the role. For example, you could attach the following trust policy to the role with the UpdateAssumeRolePolicy action. This situation requires a trust policy that allows Amazon EC2 to use the role and the permission attached to the role.

{
    "Version": "2012-10-17",
    "Statement": {
        "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
        "Effect": "Allow",
        "Principal": { "Service": "ec2.amazonaws.com" },
       "Action": "sts:AssumeRole"
    }
}                    

For the IAM permissions policy, this is attached to the IAM user which allows the ability to pass only those roles that are approved. The iam:PassRole usually is accompanied by iam:GetRole so that the user can get details of the role passed. In this example, the user can pass only roles that exist in the specified account with names that begin with EC2-roles-for-XYZ.

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": [
            "iam:GetRole",
            "iam:PassRole"
        ],
        "Resource": "arn:aws:iam::<account-id>:role/EC2-roles-for-XYZ-*"
    }]
}

Security Best Practices in IAM

To help secure your AWS resources, follow these recommendations for the AWS Identity and Access Management (IAM) service.

• Lock Away Your AWS Account Root User Access Keys
• Create Individual IAM Users
• Use Groups to Assign Permissions to IAM Users
• Grant Least Privilege
• Get Started Using Permissions with AWS Managed Policies
• Use Customer Managed Policies Instead of Inline Policies
• Use Access Levels to Review IAM Permissions
• Configure a Strong Password Policy for Your Users
• Enable MFA
• Use Roles for Applications That Run on Amazon EC2 Instances
• Use Roles to Delegate Permissions
• Do Not Share Access Keys
• Rotate Credentials Regularly
• Remove Unnecessary Credentials
• Use Policy Conditions for Extra Security
• Monitor Activity in Your AWS Account
• Video Presentation About IAM Best Practices

Policies and Permissions

You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. AWS supports six types of policies: identity-based policies, resource-based policies, permissions boundaries, Organizations SCPs, ACLs, and session policies.

Policy Types

The following policy types, listed in order of frequency, are available for use in AWS. For more details, see the sections below for each policy type.

• Identity-based policies – Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.
• Resource-based policies – Attach inline policies to resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy. Principals can be in the same account as the resource or in other accounts.
• Permissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.
• Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.
• Access control lists (ACLs) – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are similar to resource-based policies, although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
• Session policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user’s identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions. For more information, see Session Policies.

 Federation of the AWS Management Console