# Automated IAM Provisioning AMS
AWS Managed Services (AMS) supports automated validation and provisioning for IAM resources including roles and policies using AMS Advanced requests for change (RFCs) and new change types (CTs). Previously, these requests went through a semi-automated process that sometimes resulted in long wait times. Now, you can use AMS Automated IAM Provisioning to provision IAM resources and get the results much more quickly.
# How Automated IAM Provisioning in AMS works
Automated IAM Provisioning relies on automated run-time checks for IAM to validate changes to IAM resources. These automated checks, performed when the Create, Update, or Delete change types are run, prevent IAM resources that are overly-permissive or have insecure patterns from being deployed into your account. This allows you to match the level of rigor in IAM reviews to the expertise of your team. We recommend that teams that are new to cloud services and need manual checks for all IAM resources changes use the existing review-required change type: Deployment \$1 Advanced stack components \$1 Identity and Access Management (IAM) \$1 [Create entity or policy (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-identity-and-access-management-iam-create-entity-or-policy-review-required.html), (ct-3dpd8mdd9jn1r). Teams with AWS expertise and control of their environments can use Automated IAM Provisioning to speed up their deployments. You can use this feature to perform validation through automated run-time checks or to perform validation and provisioning of IAM resources after successful validation.
**Important**
AWS Managed Services has proactively implemented a list of validation [runtime checks](aip-runtime-checks.md) that prevent the creation of IAM resources or policies with certain permissions and conditions. For a description of these privileges and conditions, see [Deploying IAM resources in AMS Advanced](https://docs.aws.amazon.com/managedservices/latest/userguide/deploy-iam-resources.html). The automated change types [ct-1n9gfnog5x7fl](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-identity-and-access-management-iam-create-entity-or-policy-read-write-permissions.html), [ct-1e0xmuy1diafq](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-entity-or-policy-read-write-permissions.html), and [ct-17cj84y7632o6](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-delete-entity-or-policy-read-write-permissions.html), allow users who are proficient in managing IAM resouces to provision IAM roles and policies that allow actions beyond Read Only privileges.
In addition, you can use the roles created through the automated change types [ct-1n9gfnog5x7fl](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-identity-and-access-management-iam-create-entity-or-policy-read-write-permissions.html), [ct-1e0xmuy1diafq](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-entity-or-policy-read-write-permissions.html), and [ct-17cj84y7632o6](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-delete-entity-or-policy-read-write-permissions.html) to create the new resources. However, the resources can't follow the AMS naming standard and aren't part of the standard AMS stack. AMS provides the operational and security support of those specific resources on a best effort basis.
While both manual and automated processes aim to uphold our security standards, it's important to note that there are differences in the checks between the two. The automated provisioning allows for greater flexibility in creating and updating roles and policies; therefore, they are not the same. It's recommended that your organization carefully review the validation [runtime checks](aip-runtime-checks.md) listed in the AMS User Guide to ensure that they align with your organization's expectations and requirements.
**Validation flow**
![\[Validation flow\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/Validation-Flow.png)
**Validation and provisioning flow**
![\[Validation and provisioning flow\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/Validation-and-Provisioning-Flow.png)
**Note**
This feature is suitable for teams that are experienced with AWS and IAM resources, and we do not recommend it for teams that are new to AWS. The automated validation process is designed to catch most errors and is helpful for teams to get quick reviews for changes to IAM, when they understand the permissions that they need. To use the new change types safely and effectively, we recommend you to have a good understanding of AWS IAM, and the [run-time checks](https://docs.aws.amazon.com/managedservices/latest/userguide/aip-runtime-checks.html) offered by the change types to determine whether they are suitable for your team.
# Onboarding to AMS Automated IAM Provisioning in AMS
To use the new change types, first enable AMS Automated IAM Provisioning by submitting an RFC using the following change type: Management \$1 Managed account \$1 AMS Automated IAM Provisioning with read-write permissions \$1 [Enable (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-automated-iam-provisioning-with-read-write-permissions-enable-review-required.html) (ct-1706xvvk6j9hf). AWS requires that your organization go through a customer security risk management (CSRM) process to ensure that the use of these change types are aligned with your organizational policies. The AWS operations team works with you to acquire explicit approval from your security team contact in the form of risk acceptance as part of the required review. To learn more, see the [RFC customer risk management (CSRM) process](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-security.html).
After the RFC for turning on AMS Automated IAM Provisioning with read-write permissions feature is successful, AMS enables the AMS Automated IAM Provisioning change types in the account used to submit the enable RFC. To confirm that an account has AMS Automated IAM Provisioning turned on, check the IAM console for the `AWSManagedServicesIAMProvisionAdminRole` role.
As part of onboarding, AMS provisions IAM Access Analyzer in the same AWS Region of the account to leverage its access preview capability. IAM Access Analyzer helps identify resources in your organization and accounts that are shared with an external entity, validates IAM policies against policy grammar and best practices, and generates IAM policies based on access activity in your AWS CloudTrail logs. To learn more, see [Using AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html).
Once onboarded, the `AWSManagedServicesIAMProvisionAdminRole` is deployed to the enabled accounts. If you choose to use this role through SAML federation, then you must onboard the role to your federation solution.
As part of onboarding, you can request to update AWSManagedServicesIAMProvisionAdminRole’s trust policy to grant another IAM role ARN to assume this role using AWS Security Token Service.
# Using AMS Automated IAM Provisioning in AMS
You can create RFCs with the following AMS Automated IAM Provisioning change types.
**Note**
Only provisioning on roles and policies are supported.
While updating roles, the Update CT replaces the existing list of managed policy Amazon resource names (ARNs) and the "assume role" policy document, with the provided list of managed policy ARNs and "assume role" policy document. In a partial update; for example, adding or removing an ARN in the existing list of managed policy ARNs, adding or removing individual policy statements to the "assume role" policy document is not allowed. Similarly, while updating policies, the Update CT replaces the existing policy document and does not allow adding or removing individual policy statement in the existing policy document.
When the “validate only” option is selected, run-time checks are performed without provisioning any IAM entity or policy. Regardless of any findings, the RFC status is “success”. The "success" status indicates a successful validation against the provided IAM entity or policy.
+ Deployment \$1 Advanced Stack Components \$1 Identity and Access Management (IAM) \$1 [Create entity or policy (read-write permissions)](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-identity-and-access-management-iam-create-entity-or-policy-read-write-permissions.html)(ct-1n9gfnog5x7fl): A new IAM entity or policy is validated and provisioned automatically.
+ Management \$1 Advanced Stack Components \$1 Identity and Access Management (IAM) \$1 [Update entity or policy (read-write permissions)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-entity-or-policy-read-write-permissions.html)(ct-1e0xmuy1diafq): An existing IAM entity or policy is updated and validated automatically.
+ Management \$1 Advanced Stack Components \$1 Identity and Access Management (IAM) \$1 [Delete entity or policy (read-write permissions)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-delete-entity-or-policy-read-write-permissions.html)(ct-17cj84y7632o6): An existing IAM entity or policy that's provisioned using the automated create entity or policy change type is deleted.
You can only call the preceding three CTs using a dedicated IAM role: `AWSManagedServicesIAMProvisionAdminRole`. This role is available only in the accounts that have been onboarded to the feature using the Management \$1 Managed account \$1 AMS Automated IAM Provisioning read-write permissions \$1 [Enable (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-automated-iam-provisioning-with-read-write-permissions-enable-review-required.html) (ct-1706xvvk6j9hf).
**Important**
The Create, Update, and Delete change types are always visible in your account, but they aren't turned on by default. If you try submit an RFC using one of these change types without first enabling the AMS Automated IAM Provisioning feature, then an "unauthorized" error displays.
**Limitations**:
+ The Create CT might allow you to create an IAM role or policy with permission to create AWS resources. However, AWS resources created by these roles and policies aren't managed by AMS. It's a best practice to adhere to your organizational control to limit creation of such roles or policies.
+ The Update CT can not modify IAM roles and policies created with CFN Ingest, Direct Change Mode, Developer Mode, or, in some cases, through existing AMS Advanced manual or automated CTs.
+ The Delete CT can not delete existing roles or policies that are not created with the AMS Automated IAM Provisioning Create CT.
+ The AMS Automated IAM Provisioning with read-write permissions feature isn't supported in Direct Change Mode roles. This means that you can't provision or update IAM roles and policies with read-write permissions using these roles.
+ AMS Automated IAM Provisioning with read-write permissions Create, Update, and Delete change types are not compatible with the ServiceNow Connector.
# Runtime checks for AMS Automated IAM Provisioning in AMS
Automated IAM Provisioning leverages checks from AWS Identity and Access Management Access Analyzer, and performs additional checks and validations against the AMS boundary policy. AMS defined the additional checks and validations based on IAM best practices, experience operating customer workload in the cloud, and the collective AMS IAM manual evaluation experience.
You can view policy run-time check findings in the request for change (RFC) output. The findings include the resource identifier, location within the role and/or policy that generated the findings, and a message outlining the check that the IAM entity or resource failed to pass. These findings help you author policies that are functional and conform to security best practices.
**Note**
Automated IAM Provisioning attempts to be specific about the location within the entity or policy definition that fails to pass the check. Depending on the type, the location might include the resource name or ARN, or index within an array. For example, a statement to help you adjust the entity or policy for a successful outcome.
For a smooth AMS Automated IAM Provisioning experience, it's a best practice to use the “validate only” option to run the validation checks until there are no findings from the validation checks reported in the RFC outputs. When the validation checks report no findings, choose **Create copy** from the AMS Console to quickly create a copy of the existing RFC. When you are ready to provision, in the **Parameters** section, switch the **Validate only** value from **Yes** to **No**, and then proceed.
These are the run-time checks that AMS Automated IAM Provisioning performs to ensure that your IAM resources are secure:
**Note**
To provision IAM policies that contain actions denied by these automated change types, you must follow the RFC customer security risk management (CSRM) process. Use the following change type: Deployment \$1 Advanced stack components \$1 Identity and Access Management (IAM) \$1 Create entity or policy (managed automation) (ct-3dpd8mdd9jn1r).
+ **IAM Access Analyzer policy check and validation:** See also [Access Analyzer policy check reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html) and [IAM Access Analyzer policy validation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html).
+ **AMS permissions boundary policy checks:** Actions on a set of services that are denied by default. For more information, see [Automated IAM Provisioning permission boundary check](https://docs.aws.amazon.com/managedservices/latest/userguide/aip-runtime-checks-perm-boundary.html).
+ **Customer-defined permissions boundary policy checks:** Additional restricted actions on a set of services that are denied. For more information, see [Automated IAM Provisioning permission boundary check](https://docs.aws.amazon.com/managedservices/latest/userguide/aip-runtime-checks-perm-boundary.html).
+ **AMS-defined custom checks**: Checks that identify various insecure and overly permissive policies or access patterns within a requested IAM entity or policy, and denies the request if found one. For for information, see [AWS JSON policy elements: Principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
| Finding | Description |
| --- | --- |
| The role can be accessed from an external account that is outside of your zone of trust. | This finding refers to a principal listed in the role trust policy that is outside of your zone of trust. A zone of trust is defined as the account where the role is being created or the AWS organization that the account belongs to. An entity that does not belong to the account or to the same AWS Organization is an external entity. To resolve the finding, review the account ID in the principal ARNs and make sure that they belong to you and is an AMS onboarded account. |
| The role can be accessed by an external entity owned by account *External\$1Account\$1ID* that is not owned by the AMS customer-owning account *Account\$1ID*. | This finding is generated if the role trust policy includes a principal ARN that has an account ID not owned by you and an AMS onboarded account. To resolve this finding remove any such principal from the role trust policy. |
| The canonical user ID is not a supported principal in IAM trust policy. | Canonical principal IDs are not supported in IAM trust policy. To resolve the finding remove any such principal from the role trust policy. |
| The role can be accessed by an external web identity that is outside of your zone of trust. | This finding is generated if the role trust policy allows an external Web identity provider (IdP) other than SAML IdP. To resolve this finding, review the role trust policy and remove statements that allow the `sts:AssumeRoleWithWebIdentity` operation. |
| The role can be accessed through SAML federation; however, the provided SAML identity provider (IdP) does not exist. | This finding is generated if the role trust policy contains SAML IdP that does not exist in your account. To resolve ensure you all the listed SAML IdP exists in your account. |
| Policy contains privileged actions equivalent to administrator or power user access. Consider reducing the permission scope to a specific service, action, or resource. If advanced policy elements such as **NotAction** or **NotResource** are used, make sure that they are not granting more access than you intend, particularly in **Allow** statements. | It's a best security practice in AWS Identity and Access Management to grant only the permissions required to perform a task when you set permissions with IAM policies. Do this by defining the actions that can be taken on specific resources under specific conditions, also known as least-privilege permissions. This finding is generated when automation detects the policy grants broad permissions and does not adhere to the principle of least privilege. To resolve the finding, review and reduce the permissions. |
| Statement contains privileged actions for *Service\$1Name*. Consider excluding these actions with a deny statement. Refer to the boundary policy reference in the AMS documentation for a list of privileged actions. | AMS identified certain actions for a given service as risky and require further risk review and acceptance by the customer security team. This finding is generated when automation detects the given policy granting such permissions. To resolve this finding, deny these actions in your policy. For a list of actions refer to the AMS boundary policy. For details on AMS boundary policy, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md). |
| Statement grants access to privileged RFC Change Types: [ct-1n9gfnog5x7fl](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-identity-and-access-management-iam-create-entity-or-policy-read-write-permissions.html), [ct-1e0xmuy1diafq](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-entity-or-policy-read-write-permissions.html), and [ct-17cj84y7632o6](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-delete-entity-or-policy-read-write-permissions.html) for service *Service\$1Name*. Consider scoping the permissions to specific change types or exclude these change types with a deny statement. | This finding is generated if the policy grants permissions to perform RFC-related actions using Automated IAM Provisioning change types (CTs). The CTs are subject to risk acceptance and must only be used through onboarded roles. So, you can't granting permission to these CTs. To resolve this finding, deny RFC actions using these CTs. |
| Statement contains privileged actions that are not scoped to your resources for service *Service\$1Name*. Consider scoping the actions to specific resources or exclude resources with AMS namespace prefixes. If wildcards are used ensure they restrict the scope to your resources. | This finding is generated if the policy grants privileged actions that are not scoped to your resources of the given service. Wild cards often create overly permissive policies that bring a broad set of resources or actions into the permission's scope. To resolve the finding, either reduce the scope of permissions to resources you own or exclude resources that are in the AMS namespace. For a list of AMS namespace prefixes, see the boundary policy in AMS documentation. Note that not all prefixes apply to all services. For details on the AMS boundary policy, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md). |
| Invalid account Id or Amazon Resource Name (ARN). | This finding is generated if any ARN or account ID specified in the policy or role trust policy is invalid. To review valid resource ARN's resources for services, see the [Service Authorization Reference](https://docs.aws.amazon.com/service-authorization/latest/reference/reference.html). Make sure that the account ID is a 12-digit number and that the account is active in AWS. |
| Use of wildcard (\$1) for account id in ARN is restricted.. | This finding is generated if a wild card (\$1) is specified in the account ID field of an ARN. A wild card in an account ID field matches any account and potentially grants unintended permission to resources. To resolve this, replace the wild card with a specific account ID. |
| Specified resource account not owned by same AMS customer owning account *Account\$1ID*. | This finding is generated if an account ID specified in a resource ARN does not belong to you and is not managed by AMS. To resolve this, make sure that all resources (as specified by their ARN in the policy) belong to your accounts that are managed by AMS. |
| The role name is in AMS restricted namespace. | This finding is generated if you try to create a role with a name that starts with an AMS reserved prefix. To resolve this, use a name for the role that is specific to your use case. For a list of AMS reserved prefixes, see [AMS reserved prefixes](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-reserved-prefixes.html) |
| The policy name is in AMS restricted namespace. | This finding is generated if you try to create a policy with a name that starts with an AMS reserved prefix. To resolve this, use a name for the policy that is specific to your use case. For a list of AMS reserved prefixes, see [AMS reserved prefixes](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-reserved-prefixes.html). |
| The resource ID in the ARN is in AMS restricted namespace. | This finding is generated if you try to create a policy that grants permission to named resources that are in the AMS namespace. To resolve this, make sure that you scope the permissions to your resources or deny permissions to resources that are in the AMS namespace. For more information on AMS namespaces, see [AMS restricted namespaces](https://docs.aws.amazon.com/managedservices/latest/userguide/apx-namespaces.html). |
| Invalid policy variable case. Update the variable to *Variable\$1Names*. | This finding is generated if try to create a policy that contains an IAM global policy variable in the incorrect case. To resolve this, use the correct case for global variables in your policy. For a list of global variables, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html). For more information on the policy variables, see [IAM policy elements: Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) |
| Statement contains privileged actions that are not scoped to your KMS keys. Consider scoping these permissions to specific keys or exclude AMS owned keys. | This finding is generated if the policy contains permissions that are not scoped to specific KMS keys that you own. To resolve this, scope the permission to specific keys or exclude the keys that are AMS owned. AMS owned keys have specific alias sets. For a list of AMS owned key aliases, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md). |
| Statement contains privileged actions that are not scoped to your KMS keys aliases. Consider scoping these permissions to your keys or aliases, or exclude AMS-owned key aliases. | This finding is generated if the policy contains permissions that are not scoped to specific KMS keys alias that you own. To resolve this, scope the permission to specific keys or exclude the keys that are AMS owned. AMS owned keys have specific alias sets. For a list of AMS owned key aliases, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md). |
| Statement contains privileged actions that are not adequately scoped to your KMS keys using the `kms:ResourceAliases condition`. Consider using specific alias names along with the appropriate set operator for the condition key. If wildcards are used in the alias names ensure they restrict the scope to a limited set of your KMS keys. | This finding is generated if you are scoping permissions to your KMS keys using conditions and not using `kms:ResourceAliases` to scope down to aliases for your KMS keys. Or, if the `kms:ResourceAliases` condition key has a value that also includes AMS owned KMS keys aliases. To resolve this, update the condition to scope down permission only to aliases of your KMS keys or exclude aliases for AMS owned KMS keys. For a list of AMS owned key aliases, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md). |
| The role must have customer\$1deny\$1policy attached. Include the policy ARN in the list of managed policy ARNs. | This finding is generated if the role that you are creating does not have the `customer_deny_policy` attached to it. To resolve this, include the `customer_deny_policy` in the managed policy ARNs list. |
| The AWS managed policy is overly permissive or grants permissions restricted by AMS boundary policy. | This finding is generated if the **ManagedPolicyArns** value for the role contains any AMS managed policy that provides full or administrator level access to the relevant service. To resolve this, review use of the AWS managed policy and use a policy that provides scope down permission or define your own policy that follows the principle of least privilege. |
| The customer managed policy is in restricted AMS namespace. | This finding is generated if any customer managed policy with name prefixed in the AWS namespace is attached to the role. To resolve this, remove the policy from the **ManagedPolicyArn** list for the role. |
| The customer\$1deny\$1policy can not be detached from the role. Include the policy ARN in the list of managed policy ARNs. | This finding is generated if the `customer_deny_policy` is detached from the role during an update. To resolve this, add the `customer_deny_policy` to the **ManagedPolicyArns** field of the role and try again. |
| The customer managed policies were provisioned outside AMS Change Management service or without prior validation. | This finding is generated if one or more existing customer managed policy ARNs are attached to a role and the policies are not provisioned through the AMS Change Management service (through an RFC). For example, Developer Mode or Direct Change Mode allow customers to provision IAM policies without an RFC. To resolve this, remove the customer managed policy ARNs from the **ManagedPolicyArns** list for the role. |
| The count of provided managed policy ARNs exceed attached policy per role quota. | This finding is generated if the total number of managed policies attached to the role exceeds the policy per role quota. For more information on IAM quotas, see [IAM and AWS STS quotas, name requirements, and character limits](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). Use this information to reduce the number of policies that you attach to the role. |
| The trust policy size (\$1trust\$1policy\$1) exceeds assume role policy size quota of \$1size\$1. | This finding is generated if the size of the assume role policy document exceeds the policy size quota. For more information on IAM quotas, see [IAM and AWS STS quotas, name requirements, and character limits](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). |
| Statement contains all mutative actions for Amazon S3. Consider scoping these permissions to required actions only. If wild cards are used ensure they scope limited set of mutative actions. | This finding is generated if the given policy grants all Amazon Simple Storage Service mutative permissions irrespective of one or more resources. To resolve this, include only required Amazon S3 mutative actions against your buckets. |
| Statement contains privileged actions that are not allowed against any bucket in Amazon S3. Consider adding a statement denying these actions. | This finding is generated if the policy grants privileged actions on any bucket. For a list of privileged actions, see [AMS Automated IAM Provisioning permission boundary check](aip-runtime-checks-perm-boundary.md) To resolve this finding, remove, or deny these actions in your policy. |
| Statement contains privileged actions that are not scoped to your buckets in Amazon S3. Consider including your buckets or exclude buckets with AMS namespace prefixes. If wild cards are used, make sure that they match buckets within your namespaces. | This finding is generated if the policy grants Amazon S3 actions that are not scoped to your buckets only. This is often occurs if wild cards are used when specifying bucket resources. To resolve this, specify bucket names or ARNs that you own or exclude the buckets that have AMS namespace prefixes. |
| Statement contains privileged actions that are not scoped to your buckets in Amazon S3. Consider avoiding use of wild cards (\$1) that scopes all buckets in the account. | This finding is generated if the policy grants Amazon S3 actions that are not scoped to your bucket. This is often occurs if wild cards are used when specifying bucket resources. To resolve this, specify bucket names or ARNs that you own or exclude the buckets that have AMS namespace prefixes. |
| Statement contains a resource wildcard which is scoped to all Amazon S3 buckets, including non-existent buckets and buckets you do not own . Consider scoping the permissions using a condition and `s3:ResourceAccount` condition key. | This finding is generated if the policy grants permission to buckets specified using wild cards. Use of wild cards often brings non-existing or non-owner buckets in scope. To resolve this, use condition and the `aws:ResourceAccount` condition key to scope the permission to buckets within the current account only. For more details, see [Limit access to Amazon S3 buckets owned by specific AWS accounts](https://aws.amazon.com/blogs/storage/limit-access-to-amazon-s3-buckets-owned-by-specific-aws-accounts/). |
| Statement contains a `NotResource` policy element, which may be scoped to a large number of buckets, including non-existent buckets and buckets you do not own. Consider scoping the permissions using a condition and `s3:ResourceAccount` condition key. | This finding is generated if the policy utilizes the `NotResources` policy element to specify bucket resources. The use of the `NotResource` element might scope a large number of buckets, including non-existent or non-owner buckets. To resolve this, use conditions and the `aws:ResourceAccount` condition key to scope the permission to buckets only within the current account. |
| Statement contains Amazon S3 action to buckets *Bucket\$1Name* that either do not exist, are not owned by account *Account\$1ID*, or name contains a wild card that might be scoped to a large number of buckets, including non-existent buckets and buckets you do not own. Consider scoping the permissions using a condition and the `s3:ResourceAccount` condition key | This finding is generated if the policy grants permission to buckets that either do no exist, are not owned by you, or have wild cards in the bucket names covering a large number of buckets and access is not scoped to the current account only. To resolve this, use condition and the `aws:ResourceAccount` condition key to scope the permission to buckets within the current account only. |
| Statement contains Amazon S3 action to buckets *Bucket\$1Name* that either do not exist, not owned by account *Account\$1ID*, or the name contains a wild card that might be scoped to a large number of buckets, including non-existent buckets and buckets you do not own. Access is not restricted using `s3:ResourceAccount` or specified resource account in the condition does not belong to you. | This finding is generated if the policy grants permission to buckets that either do no exist, are not owned by you, or have wild cards in the bucket names covering a large number of buckets and access is scoped to a specific account only. However, the account specified in the `aws:ResourceAccount` condition key does not belong to you and is managed by AMS. To resolve this, update the `aws:ResourceAccount` condition key and set the appropriate account ID that you own and is managed by AMS. |
| Statement contains privileged actions that are not scoped to your instances for Amazon EC2. Consider scoping the actions to specific instance ARNs or exclude instances that have Name tag key with value in AMS namespace prefixes. If wild cards are used, ensure they match namespaces that you own. | This finding is generated if the policy grants privileged actions against Amazon EC2 instances that AMS owns. AMS instances are tagged with the **Name** tag key with values in AMS namespace. To resolve this, specify your resources or exclude AMS instances with a condition that has the `aws:ResourceTag/Name` key that excludes values in the AMS namespace using the `StringNotLike` operator |
| Statement contains privileged actions that are not scoped to your resources in AWS Systems Manager parameter store. Consider specifying ARNs of your parameters or exclude parameters with AMS namespace prefixes. If wild cards are used, ensure they scope only your parameters. | This finding is generated if the policy grants permissions to parameters that you do not own. This is usually when wild cards are used or parameters with AMS namespace prefixes are listed under resources in a policy statement. To resolve this, specify parameters that are within your namespace or exclude AMS parameters with a deny statement. |
| Statement contains privileged actions against resources in AWS Systems Manager. Consider scoping the permissions to read only actions or actions against your resources. | This finding is generated if the policy grants permissions other than parameter store or readonly actions against Systems Manager resources. To resolve this finding reduce the permissions to readonly actions or parameter store only. |
| Statement contains privileged actions that are not scoped to \$1message\$1 in *Service\$1Name* that you own. Consider scoping these permissions to specific resource types as appropriate or exclude AMS owned resources. If wild cards are used, ensure they match *Resources*. | This finding is generated if the policy allows privileged actions that are not granted against your resources, especially for named resources. To resolve this finding review your resource list and see if they only scope resource that is in your namespace. Alternatively exclude resources that are in AMS namespace. |
| Statement contains tagging actions of \$1*Service\$1Name*\$1 that are not scoped to specific values for Name tag key. Consider scoping these actions by setting `aws:RequestTag/Name` condition key with values in your namespace or restrict these actions by setting `aws:RequestTag/Name` condition key with the `StringNotLike` operator with values in the AMS namespace prefixes. | This finding is generated if the policy grants tagging permission for given service and the permission is not scoped to specifc tag keys/values. To scope down what key or value can be used in tag actions, for example, when making request to perform the actions, use the `aws:RequestTag/tag key` condition. So, to resolve this, use this condition key to restrict key or values in your name space. Or, deny the `Name` tag key (`aws:RequestTag/Name`) with values in AMS namespace. |
| Internal error validating IAM role trust policy. | This finding is generated when CT automation encounters an error performing validation on the IAM role trust policy through the IAM Access Analyzer service. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating customer managed policy. | This finding is generated when CT automation encounters an error performing ovalidation on the customer managed policy through the IAM Access Analyzer service. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Access analyzer not found in *AWS Region*. Unable to perform access preview check for role trust policy. | This finding is generated when the IAM Access Analyzer resource is not found in the AWS Region. Contact AMS Operations to troubleshoot and create IAM Access Analyzer resource in the AWS Region. |
| Invalid trust policy for role *Role\$1Name* | This finding is generated when provided IAM role contains an invalid trust policy. To resolve review the trust policy to verify that it is valid. |
| IAM Access Analyzer encountered an internal error. Failed to create access preview for role *Role\$1Name* | This finding is generated when automation encounters an error while creating an access preview for a role through the IAM Access Analyzer. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Failed to create access preview for trust policy of role *Role\$1Name* | This finding is generated when automation encounters an error while creating an access preview for a role through the IAM Access Analyzer. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating listed SAML IdP. | This finding is generated when automation encounters an error while validating the provided SAML IdPs listed in the role trust policy. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating permissions against AWS Key Management Service. | This finding is generated when automation encounters an error while validating the AWS KMS key permissions in the provided policy. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating listed managed policy ARNs. | This finding is generated when automation encounters an error while validating listed managed policy ARNs. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating default `customer_deny_policy` attachment. | This finding is generated when automation encounters an error while validating that the `customer_deny_policy` is attached to the role. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating managed policy arns for the role *Role\$1Name* | This finding is generated when automation encounters an error while validating managed policy ARNs for the role. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Internal error validating *Policy\$1name* against customer-defined boundary policy `AWSManagedServicesIAMProvisionCustomerBoundaryPolicy` | This finding is generated when automation encounters an error while validating the policy that cotains your custom deny list. To resolve this, resubmit the RFC. If the error persists, then contact AMS Operations to troubleshoot the error. |
| Customer-defined boundary policy `AWSManagedServicesIAMProvisionCustomerBoundaryPolicy` exists in the account. However, the policy contains allow statements that grant permissions. The policy must only contain deny statements. | This finding is generated when the policy that contains your custom deny list includes a statement that grants permission. Although the custom deny list exists within your account as an IAM managed policy, it can't be used for permission management. The policy must only contain deny statements that indicate that you want AMS Automated IAM Provisioning to validate and deny those actions in your IAM policies that AMS Automated IAM Provisioning creates. |
| Statement contains privileged actions defined by your organization for *Service\$1Name*. Consider excluding these actions with a deny statement. Refer to the policy named in your account for reference to the restricted list of actions. | This finding is generated when automation detects any action in your policy that you defined in the custom deny list. To resolve the finding, review your policy statement and remove any actions that are defined in your custom deny list or add a deny statement that denies those actions. |
| The role must have *POLICY\$1ARN* attached. Include the policy ARN in the list of managed policy ARNs. | This finding is generated if the role that you're creating doesn't have the *POLICY\$1ARN* attached to it. To resolve this, include the *POLICY\$1ARN* in the **ManagedPolicyArns** field of the role and try again. |
| The *POLICY\$1ARN* can not be detached from the role. Include the policy ARN in the list of managed policy ARNs. | This finding is generated if the *POLICY\$1ARN* is detached from the role during an update. To resolve this, add the *POLICY\$1ARN* to the **ManagedPolicyArns** field of the role and try again. |
# AMS Automated IAM Provisioning permission boundary check
AMS permission boundary checks help you adhere to the default permission boundary policy provided by AMS. This policy is a list of actions denied by AMS Automated IAM Provisioning. Provisioning policies that contain these restricted actions require additional explicit risk acceptance. Download the policy here: [boundary-policy.zip](samples/boundary-policy.zip).
Use customer-defined permission boundary policy checks to customize deny actions beyond the AMS permission boundary policy defaults. When you onboard to AMS Automated IAM Provisioning using the following change type: Management \$1 Managed account \$1 AMS Automated IAM Provisioning with read-write permissions \$1 [Enable (managed automation)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-automated-iam-provisioning-with-read-write-permissions-enable-review-required.html) (ct-1706xvvk6j9hf), you can include a list of custom deny actions that specify additional restricted actions.
You can update the list of deny actions using the change type: Management \$1 Managed account \$1 Automated IAM provisioning with read-write permissions \$1 [Update custom deny list](https://docs.aws.amazon.com/managedservices/latest/ctref/management-managed-automated-iam-provisioning-with-read-write-permissions-update-custom-deny-list-review-required.html) (ct-2r9xvd3sdsic0). You must use the dedicated IAM role `AWSManagedServicesIAMProvisionAdminRole` to run this change type.
**Note**
You must provide a comprehensive list of deny actions for each update. The previous list is replaced by the new list.
The list of deny actions must contain only actions to be denied. Allow actions aren't supported.
The list of deny actions resides within the account as an IAM managed policy named `AWSManagedServicesIAMProvisionCustomerBoundaryPolicy`. The policy must not be attached to any role.
The term *permission boundary* used to denote denied actions in AMS Automated IAM Provisioning has a different contextual meaning compared to the IAM permission boundary. The IAM permission boundary sets the maximum permission that a policy can grant at runtime to an IAM entity. For more information on IAM permission boundary see [Policy types](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policy-types) in the *AWS Identity and Access Management User Guide*. The permission boundary in AMS Automated IAM Provisioning prevents you from provisioning an IAM policy that contains a certain set of permissions, for example, a denied list of actions.
# Troubleshooting AMS Automated IAM Provisioning fndings and errors
There are three ways you might run into problems when using AMS Automated IAM Provisioning:
+ RFC errors: These can happen for a variety of reasons; for example, incorrect input. For more information, see [Troubleshooting RFC errors in AMS](rfc-troubleshoot.md).
+ SSM errors: These can happen for a variety of reasons; for example, poor formatting. For more information, see [Troubleshooting Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-troubleshooting.html).
+ Validation check findings: These occur when one of the many validation checks that Automated IAM Provisioning runs finds a problem. For a list of validation checks, and recommended actions to fix, see [Runtime checks for AMS Automated IAM Provisioning in AMS](aip-runtime-checks.md).