

# Setting permissions in AMS with IAM roles and profiles
<a name="setting-permissions"></a>

AMS uses AWS Identity and Access Management (IAM) to manage users, security credentials such as access keys, and permissions that control which AWS resources users and applications can access. AMS provides a default IAM user role and a default Amazon EC2 instance profile (which includes a statement allowing the resource access to the default IAM user role).

## Requesting a new IAM user role or instance profile
<a name="request-new-role-or-profile"></a>

AMS uses an IAM role to set user permissions through your federation service and an IAM instance profile as a container for that IAM role.

You can request a custom IAM role with the Deployment \$1 Advanced stack components \$1 Identity and Access Management (IAM) \$1 Create entity or policy (managed automation) change type (ct-3dpd8mdd9jn1r), or an IAM instance profile with the Management \$1 Applications \$1 IAM instance profile \$1 Create Management \$1 Applications \$1 IAM instance profile \$1 Create (managed automation) change type (ct-0ixp4ch2tiu04). See the descriptions of each in this section.

**Note**  
AMS has an IAM policy, `customer_deny_policy` that blocks out dangerous namespaces and actions. This policy is attached to all AMS customer roles by default and is rarely a problem for users. Your IAM user and role requests don't include this policy, but automatic inclusion of the `customer_deny_policy` in requests for IAM roles helps AMS deploy new IAM instance profiles more quickly. You can request the exclusion of the `customer_deny_policy` policy. However, this request will go through a weighty security review and is likely to be declined due to security reasons.

# Restrict permissions with IAM role policy statements
<a name="request-iam-user"></a>

AMS uses an IAM role to set user permissions through your federation service.

**Single-Account Landing Zone AMS**: See [SALZ: Default IAM User Roles](https://docs.aws.amazon.com/managedservices/latest/userguide/defaults-user-role.html#json-default-role).

**Multi-Account Landing Zone AMS**: See [MALZ: Default IAM User Roles](https://docs.aws.amazon.com/managedservices/latest/userguide/defaults-user-role.html#json-default-role-malz).

An IAM role is an IAM entity that defines a set of permissions for making AWS service requests. IAM roles are not associated with a specific user or group. Instead, trusted entities assume roles, such as IAM users, applications, or AWS services such as Amazon EC2. For more information, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html).

You can scope down the desired policy for a user assuming the AMS IAM user role by using the AWS Security Token Service (STS) API operation [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) by passing a more restrictive IAM policy under the `Policy` request field.

Example policy statements that you can use to restrict CT access are provided next.

Using your configured Active Directory (AD) groups, and the AWS Security Token Service (STS) API operation [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html), you can set permissions for certain users or groups, including restricting access to certain change types (CTs). You can use the policy statements shown below to restrict CT access in various ways.

AMS change type statement in the default IAM instance profile that allows access to all AMS API calls (amscm and amsskms) and all change types:

```
{
    "Sid": "AWSManagedServicesFullAccess",
    "Effect": "Allow",
    "Action": [
        "amscm:*",
        "amsskms:*"
    ],
    "Resource": [
        "*"
    ]
}
```

1. Statement to allow access and all actions for only two specified CTs, where "Action" is the AMS API operations (either `amscm` or `amsskms`), and "Resource" represents existing change type IDs and version number:

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "amscm:*",
               "Resource": [
                   "arn:aws:amscm:*:*:changetype/ct-ID1:1.0",
                   "arn:aws:amscm:*:*:changetype/ct-ID2:1.0"
               ]
           }
       ]
   }
   ```

------

1. Statement to allow access for CreateRfc, UpdateRfc, and SubmitRfc on only two specified CTs:

1. Statement to allow access for CreateRfc, UpdateRfc, and SubmitRfc on all available CTs:

1. Statement to deny access for all actions on restricted CT and allow on other CTs:

# Restrict permissions with Amazon EC2 IAM instance profiles
<a name="request-instance-profile"></a>

An IAM instance profile is a container for an IAM role that you can use to pass role information to an Amazon EC2 instance when the instance starts.

Currently there is one AWS Managed Services (AMS) default instance profile, `customer-mc-ec2-instance-profile`, that grants permissions to the applications running on the instance, not to users logging into the instance. You might want to modify the default instance profile, or create a new one, if you want to give an instance access to something, without granting other instances access as well. You can request a new IAM instance profile with the Management \$1 Applications \$1 IAM instance profile \$1 Create change type (ct-0ixp4ch2tiu04). When submitting the RFC, you could fashion your own instance profile and include that as the InstanceProfileDescription, or you could just inform AMS (using the same field) of what changes you want. Because this is a Manual CT, AMS must approve the change and will be in contact with you about it.

If you're unfamiliar with Amazon IAM policies, see [Overview of IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) for important information. There is also a good blog post, [ Demystifying Amazon EC2 Resource-Level Permissions](https://aws.amazon.com/blogs/security/demystifying-ec2-resource-level-permissions/). Note that AMS does not currently support Resource-based access control, but does support Resource-level controls using IAM role policies (for an explanation of the difference, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).

**Single-Account Landing Zone AMS**:

To see a table of permissions that the default AMS IAM instance profile grants, go to [EC2 IAM Instance Profile](https://docs.aws.amazon.com/managedservices/latest/userguide/defaults-user-role.html). 