# Control CloudFormation access with AWS Identity and Access Management Control access with IAM With AWS Identity and Access Management (IAM), you can create IAM users and control their access to specific resources in your AWS account. When you use IAM, you can control what users can do with CloudFormation, such as whether they can view stack templates, create stacks, or delete stacks. Beyond CloudFormation-specific actions, you can manage what AWS services and resources are available to each user. That way, you can control which resources users can access when they use CloudFormation. For example, you can specify which users can create Amazon EC2 instances, terminate database instances, or update VPCs. Those same permissions apply anytime they use CloudFormation to do those actions. Use the information in the following sections to control who can access CloudFormation. We will also explore how to authorize IAM resource creation in templates, give applications running on EC2 instances the permissions they need, and make use of temporary security credentials for enhanced security in your AWS environment. ## Defining IAM identity-based policies for CloudFormation To give access to CloudFormation, you need to create and assign IAM policies that give your IAM identities (such as users or roles) permission to call the API actions they need. With IAM identity-based policies, you can specify allowed or denied actions and resources, as well as the conditions under which actions are allowed or denied. CloudFormation supports specific actions, resources, and condition keys. If you're new to IAM, start by familiarizing yourself with the elements of an IAM JSON policy. For more information, see [IAM JSON policy element reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*. To learn how to create IAM policies, complete the tutorial [Create and attach your first customer managed policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) in the IAM documentation. **Topics** + [ ### Policy actions for CloudFormation ](#using-iam-actions) + [ ### Console-specific actions for CloudFormation ](#console-specific-actions) + [ ### Policy resources for CloudFormation ](#resource-level-permissions) + [ ### Policy condition keys for CloudFormation ](#using-iam-conditions) ### Policy actions for CloudFormation In the `Action` element of your IAM policy statement, you can specify any API action that CloudFormation offers. You must prefix the action name with the lowercase string `cloudformation:`. For example: `cloudformation:CreateStack`, `cloudformation:CreateChangeSet`, and `cloudformation:UpdateStack`. To specify multiple actions in a single statement, separate them with commas, as follows: ``` "Action": [ "cloudformation:action1", "cloudformation:action2" ] ``` You can also specify multiple actions using wildcards. For example, you can specify all actions whose names begin with the word `Get`, as follows: ``` "Action": "cloudformation:Get*" ``` To see a complete list of actions associated with the `cloudformation` service prefix, see [Actions, resources, and condition keys for CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html) and [Actions, resources, and condition keys for AWS Cloud Control API](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudcontrolapi.html) in the *Service Authorization Reference*. #### Examples The following shows an example of a permissions policy that grants permissions to view CloudFormation stacks. **Example 1: A sample policy that grants view stack permissions** **** ``` { "Version":"2012-10-17", "Statement":[{ "Effect":"Allow", "Action":[ "cloudformation:DescribeStacks", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStackResource", "cloudformation:DescribeStackResources" ], "Resource":"*" }] } ``` Users who create or delete stacks need additional permissions based on their stack templates. For example, if your template describes an Amazon SQS queue, users must have permissions for both CloudFormation and Amazon SQS actions, as shown in the following sample policy. **Example 2: A sample policy that grants create and view stack actions and all Amazon SQS actions** **** ``` { "Version":"2012-10-17", "Statement":[{ "Effect":"Allow", "Action":[ "sqs:*", "cloudformation:CreateStack", "cloudformation:DescribeStacks", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStackResources", "cloudformation:GetTemplate", "cloudformation:ValidateTemplate" ], "Resource":"*" }] } ``` ### Console-specific actions for CloudFormation Users of the CloudFormation console require additional permissions beyond those needed for the AWS Command Line Interface or CloudFormation APIs. These additional permissions support console-specific features such as template uploads to Amazon S3 buckets and drop-down lists for AWS-specific parameter types. For all actions listed below, grant permissions to all resources; don't limit them to specific stacks or buckets. The following action is used only by the CloudFormation console and is not documented in the API reference. The action allows users to upload templates to Amazon S3 buckets. + `cloudformation:CreateUploadBucket` When users upload templates, users also require the following Amazon S3 permissions: + `s3:PutObject` + `s3:ListBucket` + `s3:GetObject` + `s3:CreateBucket` To see values in the parameter drop-down lists for templates with AWS-specific parameter types, users need permissions to make the corresponding describe API calls. For example, the following permissions are required when these parameter types are used in the template: + `ec2:DescribeKeyPairs` – Required for the `AWS::EC2::KeyPair::KeyName` parameter type. + `ec2:DescribeSecurityGroups` – Required for the `AWS::EC2::SecurityGroup::Id` parameter type. + `ec2:DescribeSubnets` – Required for the `AWS::EC2::Subnet::Id` parameter type. + `ec2:DescribeVpcs` – Required for the `AWS::EC2::VPC::Id` parameter type. For more information about AWS-specific parameter types, see [Specify existing resources at runtime with CloudFormation-supplied parameter types](cloudformation-supplied-parameter-types.md). ### Policy resources for CloudFormation In an IAM policy statement, the `Resource` element specifies the object or objects that the statement covers. For CloudFormation, each IAM policy statement applies to the resources that you specify using their Amazon Resource Names (ARNs). The specific ARN format depends on the resource. For a complete list of CloudFormation resource types and their ARNs, see [Resource types defined by CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html#awscloudformation-resources-for-iam-policies) in the *Service Authorization Reference*. To learn with which actions you can specify with each resource's ARN, see [Actions defined by CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html#awscloudformation-actions-as-permissions). You can specify actions for a specific stack, as shown in the following policy example. When you provide an ARN, replace the `placeholder text` with your resource-specific information. **Example 1: A sample policy that denies the delete and update stack actions for the specified stack** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "cloudformation:DeleteStack", "cloudformation:UpdateStack" ], "Resource": "arn:aws:cloudformation:us-east-1:111122223333:stack/MyProductionStack/*" } ] } ``` The policy above uses a wild card at the end of the stack name so that delete stack and update stack are denied on both the full stack ID (such as `arn:aws:cloudformation:region:account-id:stack/MyProductionStack/abc9dbf0-43c2-11e3-a6e8-50fa526be49c`) and the stack name (such as `MyProductionStack`). To allow `AWS::Serverless` transforms to create a change set, include the `arn:aws:cloudformation:region:aws:transform/Serverless-2016-10-31` resource-level permission, as shown in the following policy. **Example 2: A sample policy that allows the create change set action for the specified transform** **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:CreateChangeSet" ], "Resource": "arn:aws:cloudformation:us-east-1:aws:transform/Serverless-2016-10-31" } ] } ``` ### Policy condition keys for CloudFormation In an IAM policy statement, you can optionally specify conditions that control when a policy is in effect. For example, you can define a policy that allows users to create a stack only when they specify a certain template URL. You can define CloudFormation-specific conditions and AWS-wide conditions, such as `DateLessThan`, which specifies when a policy stops taking effect. For more information and a list of AWS-wide conditions, see Condition in [IAM policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) in *IAM User Guide*. **Note** Don't use the `aws:SourceIp` AWS-wide condition. CloudFormation provisions resources by using its own IP address, not the IP address of the originating request. For example, when you create a stack, CloudFormation makes requests from its IP address to launch an Amazon EC2 instance or to create an Amazon S3 bucket, not from the IP address from the `CreateStack` call or the **create-stack** command. The following list describes the CloudFormation-specific conditions. These conditions are applied only when users create or update stacks: `cloudformation:ChangeSetName` An CloudFormation change set name that you want to associate with a policy. Use this condition to control which change sets users can execute or delete. `cloudformation:ImportResourceTypes` The template resource types that you want to associate with a policy, such as `AWS::EC2::Instance`. Use this condition to control which resource types users can work with when they import resources into a stack. This condition is checked against the resource types that users declare in the `ResourcesToImport` parameter, which is currently supported only for AWS CLI and API requests. When using this parameter, you must specify all the resource types you want users to control during import operations. For more information about the `ResourcesToImport` parameter, see the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html) action in the *AWS CloudFormation API Reference*. For a list of possible `ResourcesToImport`, see [Resource type support](resource-import-supported-resources.md). Use the three-part resource naming convention to specify which resource types users can work with, from all resources across an organization, down to an individual resource type. `organization::*` Specify all resource types for a given organization. `organization::service_name::*` Specify all resource types for the specified service within a given organization. `organization::service_name::resource_type` Specify a specific resource type. For example: `AWS::*` Specify all supported AWS resource types. `AWS::service_name::*` Specify all supported resources for a specific AWS service. `AWS::service_name::resource_type` Specify a specific AWS resource type, such as `AWS::EC2::Instance` (all EC2 instances). `cloudformation:ResourceTypes` The template resource types, such as `AWS::EC2::Instance`, that you want to associate with a policy. Use this condition to control which resource types users can work with when they create or update a stack. This condition is checked against the resource types that users declare in the `ResourceTypes` parameter, which is currently supported only for AWS CLI and API requests. When using this parameter, users must specify all the resource types that are in their template. For more information about the `ResourceTypes` parameter, see the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html) action in the *AWS CloudFormation API Reference*. For a list of resource types, see [CloudFormation Template Reference Guide](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/introduction.html). Use the three-part resource naming convention to specify which resource types users can work with, from all resources across an organization, down to an individual resource type. `organization::*` Specify all resource types for a given organization. `organization::service_name::*` Specify all resource types for the specified service within a given organization. `organization::service_name::resource_type` Specify a specific resource type. For example: `AWS::*` Specify all supported AWS resource types. `AWS::service_name::*` Specify all supported resources for a specific AWS service. `AWS::service_name::resource_type` Specify a specific AWS resource type, such as `AWS::EC2::Instance` (all EC2 instances). `Alexa::ASK::*` Specify all resource types in the Alexa Skill Kit. `Alexa::ASK::Skill` Specify the individual [Alexa::ASK::Skill](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/alexa-resource-ask-skill.html) resource type. `Custom::*` Specify all custom resources. For more information, see [Create custom provisioning logic with custom resources](template-custom-resources.md). `Custom::resource_type` Specify a specific custom resource type. For more information, see [Create custom provisioning logic with custom resources](template-custom-resources.md). `cloudformation:RoleARN` The Amazon Resource Name (ARN) of an IAM service role that you want to associate with a policy. Use this condition to control which service role users can use when they work with stacks or change sets. `cloudformation:StackPolicyUrl` An Amazon S3 stack policy URL that you want to associate with a policy. Use this condition to control which stack policies users can associate with a stack during a create or update stack action. For more information about stack policies, see [Prevent updates to stack resources](protect-stack-resources.md). To ensure that users can only create or update stacks with the stack policies that you uploaded, set the S3 bucket to read only for those users. `cloudformation:TemplateUrl` An Amazon S3 template URL that you want to associate with a policy. Use this condition to control which templates users can use when they create or update stacks. To ensure that users can only create or update stacks with the templates that you uploaded, set the S3 bucket to read only for those users. The following CloudFormation-specific conditions apply to the API parameters of the same name: + `cloudformation:ChangeSetName` + `cloudformation:RoleARN` + `cloudformation:StackPolicyUrl` + `cloudformation:TemplateUrl` For example, `cloudformation:TemplateUrl` only applies to the `TemplateUrl` parameter for `CreateStack`, `UpdateStack`, and `CreateChangeSet` APIs. For examples of IAM policies that use condition keys to control access, see [Example IAM identity-based policies for CloudFormation](security_iam_id-based-policy-examples.md). ## Acknowledging IAM resources in CloudFormation templates Before you can create a stack, CloudFormation validates your template. During validation, CloudFormation checks your template for IAM resources that it might create. IAM resources, such as a user with full access, can access and modify any resource in your AWS account. Therefore, we suggest that you review the permissions associated with each IAM resource before proceeding so that you don't unintentionally create resources with escalated permissions. To ensure that you've done so, you must acknowledge that the template contains those resources, giving CloudFormation the specified capabilities before it creates the stack. You can acknowledge the capabilities of CloudFormation templates by using the CloudFormation console, AWS Command Line Interface (AWS CLI), or API: + In the CloudFormation console, on the **Configure stack options** page of the Create Stack or Update Stack wizards, choose **I acknowledge that this template may create IAM resources**. + In the AWS CLI, when you use the [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html) and [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html) commands, specify the `CAPABILITY_IAM` or `CAPABILITY_NAMED_IAM` value for the `--capabilities` option. If your template includes IAM resources, you can specify either capability. If your template includes custom names for IAM resources, you must specify `CAPABILITY_NAMED_IAM`. + In the API, when you use the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html) and [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_UpdateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_UpdateStack.html) actions, specify `Capabilities.member.1=CAPABILITY_IAM` or `Capabilities.member.1=CAPABILITY_NAMED_IAM`. If your template includes IAM resources, you can specify either capability. If your template includes custom names for IAM resources, you must specify `CAPABILITY_NAMED_IAM`. **Important** If your template contains custom named IAM resources, don't create multiple stacks reusing the same template. IAM resources must be globally unique within your account. If you use the same template to create multiple stacks in different Regions, your stacks might share the same IAM resources, rather than each having a unique one. Shared resources among stacks can have unintended consequences from which you can't recover. For example, if you delete or update shared IAM resources in one stack, you will unintentionally modify the resources of other stacks. ## Managing credentials for applications running on Amazon EC2 instances If you have an application that runs on an Amazon EC2 instance and needs to make requests to AWS resources such as Amazon S3 buckets or an DynamoDB table, the application requires AWS security credentials. However, distributing and embedding long-term security credentials in every instance that you launch is a challenge and a potential security risk. Instead of using long-term credentials, like IAM user credentials, we recommend that you create an IAM role that is associated with an Amazon EC2 instance when the instance is launched. An application can then get temporary security credentials from the Amazon EC2 instance. You don't have to embed long-term credentials on the instance. Also, to make managing credentials easier, you can specify just a single role for multiple Amazon EC2 instances; you don't have to create unique credentials for each instance. For a template snippet that shows how to launch an instance with a role, see [IAM role template examples](quickref-iam.md#scenarios-iamroles). **Note** Applications on instances that use temporary security credentials can call any CloudFormation actions. However, because CloudFormation interacts with many other AWS services, you must verify that all the services that you want to use support temporary security credentials. For a list of the services that accept temporary security credentials, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. ## Granting temporary access (federated access) In some cases, you might want to grant users with no AWS credentials temporary access to your AWS account. Rather than creating and deleting long-term credentials whenever you want to grant temporary access, use AWS Security Token Service (AWS STS). For example, you can use IAM roles. From one IAM role, you can programmatically create and then distribute many temporary security credentials (which include an access key, secret access key, and security token). These credentials have a limited life, so they cannot be used to access your AWS account after they expire. You can also create multiple IAM roles in order to grant individual users different levels of permissions. IAM roles are useful for scenarios like federated identities and single sign-on. A federated identity is a distinct identity that you can use across multiple systems. For enterprise users with an established on-premises identity system (such as LDAP or Active Directory), you can handle all authentication with your on-premises identity system. After a user has been authenticated, you provide temporary security credentials from the appropriate IAM user or role. For example, you can create an administrators role and a developers role, where administrators have full access to the AWS account and developers have permissions to work only with CloudFormation stacks. After an administrator is authenticated, the administrator is authorized to obtain temporary security credentials from the administrators role. However, for developers, they can obtain temporary security credentials from only the developers role. You can also grant federated users access to the AWS Management Console. After users authenticate with your on-premises identity system, you can programmatically construct a temporary URL that gives direct access to the AWS Management Console. When users use the temporary URL, they won't need to sign in to AWS because they have already been authenticated (single sign-on). Also, because the URL is constructed from the users' temporary security credentials, the permissions that are available with those credentials determine what permissions users have in the AWS Management Console. You can use several different AWS STS APIs to generate temporary security credentials. For more information about which API to use, see [Compare AWS STS credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html) in the *IAM User Guide*. **Important** You cannot work with IAM when you use temporary security credentials that were generated from the `GetFederationToken` API. Instead, if you need to work with IAM, use temporary security credentials from a role. CloudFormation interacts with many other AWS services. When you use temporary security credentials with CloudFormation, verify that all the services that you want to use support temporary security credentials. For a list of the services that accept temporary security credentials, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*. For more information, see the following related resources in the *IAM User Guide*: + [Common scenarios for temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction) + [Enable custom identity broker access to the AWS console](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html) # Example IAM identity-based policies for CloudFormation Identity-based policy examples By default, users and roles don't have permission to create or modify CloudFormation resources. They also can't perform tasks by using the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS API. To grant users permission to perform actions on the resources that they need, an IAM administrator can create IAM policies. The administrator can then add the IAM policies to roles, and users can assume the roles. For more information, see [Defining IAM identity-based policies for CloudFormation](control-access-with-iam.md#iam-id-based-policies). The following examples show policy statements that you could use to allow or deny permissions to use one or more CloudFormation actions. **Topics** + [ ## Require a specific template URL ](#w2aac43c23c17b9) + [ ## Deny all CloudFormation import operations ](#w2aac43c23c17c11) + [ ## Allow import operations for specific resource types ](#w2aac43c23c17c13) + [ ## Deny IAM resources in stack templates ](#w2aac43c23c17c15) + [ ## Allow stack creation with specific resource types ](#w2aac43c23c17c17) + [ ## Control access based on resource-mutating API actions ](#w2aac43c23c17c19) + [ ## Restrict stack set operations based on Region and resource types ](#resource-level-permissions-service-managed-stack-set) + [ ## Allow all IaC generator operations ](#iam-policy-example-for-iac-generator) ## Require a specific template URL The following policy grants permissions to use only the `https://s3.amazonaws.com/amzn-s3-demo-bucket/test.template` template URL to create or update a stack. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:CreateStack", "cloudformation:UpdateStack" ], "Resource": "*", "Condition": { "StringEquals": { "cloudformation:TemplateUrl": [ "https://s3.amazonaws.com/amzn-s3-demo-bucket/test.template" ] } } } ] } ``` ------ ## Deny all CloudFormation import operations The following policy grants permissions to complete all CloudFormation operations except import operations. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowAllStackOperations", "Effect": "Allow", "Action": "cloudformation:*", "Resource": "*" }, { "Sid": "DenyImport", "Effect": "Deny", "Action": "cloudformation:*", "Resource": "*", "Condition": { "ForAnyValue:StringLike": { "cloudformation:ImportResourceTypes": [ "*" ] } } } ] } ``` ------ ## Allow import operations for specific resource types The following policy grants permissions to all stack operations, in addition to import operations only on specified resources (in this example, `AWS::S3::Bucket`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowImport", "Effect": "Allow", "Action": "cloudformation:*", "Resource": "*", "Condition": { "ForAllValues:StringEqualsIgnoreCase": { "cloudformation:ImportResourceTypes": [ "AWS::S3::Bucket" ] } } } ] } ``` ------ ## Deny IAM resources in stack templates The following policy grants permissions to create stacks but denies requests if the stack's template include any resource from the IAM service. The policy also requires users to specify the `ResourceTypes` parameter, which is available only for AWS CLI and API requests. This policy uses explicit deny statements so that if any other policy grants additional permissions, this policy always remain in effect (an explicit deny statement always overrides an explicit allow statement). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect" : "Allow", "Action" : [ "cloudformation:CreateStack" ], "Resource" : "*" }, { "Effect" : "Deny", "Action" : [ "cloudformation:CreateStack" ], "Resource" : "*", "Condition" : { "ForAnyValue:StringLikeIfExists" : { "cloudformation:ResourceTypes" : [ "AWS::IAM::*" ] } } }, { "Effect": "Deny", "Action" : [ "cloudformation:CreateStack" ], "Resource": "*", "Condition": { "Null": { "cloudformation:ResourceTypes": "true" } } } ] } ``` ------ ## Allow stack creation with specific resource types The following policy is similar to the previous example. The policy grants permissions to create a stack unless the stack's template includes any resource from the IAM service. It also requires users to specify the `ResourceTypes` parameter, which is available only for AWS CLI and API requests. This policy is simpler, but it doesn't use explicit deny statements. Other policies, granting additional permissions, could override this policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect" : "Allow", "Action" : [ "cloudformation:CreateStack" ], "Resource" : "*", "Condition" : { "ForAllValues:StringNotLikeIfExists" : { "cloudformation:ResourceTypes" : [ "AWS::IAM::*" ] }, "Null":{ "cloudformation:ResourceTypes": "false" } } } ] } ``` ------ ## Control access based on resource-mutating API actions The following policy grants permissions to filter access by the name of a resource-mutating API action. This is used to control which APIs IAM users can use to add or remove tags on a stack or stack set. The operation that is used to add or remove tags should be added as value for the condition key. The following policy grants `TagResource` and `UntagResource` permissions to mutating operation `CreateStack`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [{ "Sid": "CreateActionConditionPolicyForTagUntagResources", "Effect": "Allow", "Action": [ "cloudformation:TagResource", "cloudformation:UntagResource" ], "Resource": "*", "Condition": { "StringEquals": { "cloudformation:CreateAction": [ "CreateStack" ] } } }] } ``` ------ ## Restrict stack set operations based on Region and resource types The following policy grants service-managed stack set permissions. A user with this policy can only perform operations on stack sets with templates containing Amazon S3 resource types (`AWS::S3::*`) or the `AWS::SES::ConfigurationSet` resource type. If signed in to the organization management account with ID `123456789012`, the user can also only perform operations on stack sets that target the OU with ID `ou-1fsfsrsdsfrewr`, and can only perform operations on the stack set with ID `stack-set-id` that targets the AWS account with ID `987654321012`. Stack set operations fail if the stack set template contains resource types other than those specified in the policy, or if the deployment targets are OU or account IDs other than those specified in the policy for the corresponding management accounts and stack sets. These policy restrictions only apply when stack set operations target the `us-east-1`, `us-west-2`, or `eu-west-2` AWS Regions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudformation:*" ], "Resource": [ "arn:aws:cloudformation:*:*:stackset/*", "arn:aws:cloudformation:*:*:type/resource/AWS-S3-*", "arn:aws:cloudformation:us-west-2:111122223333:type/resource/AWS-SES-ConfigurationSet", "arn:aws:cloudformation:*:111122223333:stackset-target/*/ou-1fsfsrsdsfrewr", "arn:aws:cloudformation:*:111122223333:stackset-target/stack-set-id/444455556666" ], "Condition": { "ForAllValues:StringEqualsIgnoreCase": { "cloudformation:TargetRegion": [ "us-east-1", "us-west-2", "eu-west-1" ] } } } ] } ``` ------ ## Allow all IaC generator operations The following policy allows access to CloudFormation actions related to IaC generator resource scanning and template management. The first statement grants permissions to describe, list, and start resource scans. It also allows access to additional required permissions (`cloudformation:GetResource`, `cloudformation:ListResources`, and `cloudformation:ListTypes`) that enable the IaC generator to retrieve information about resources and available resource types. The second statement grants full permissions to create, delete, describe, list, and update generated templates. You must also grant read permissions for the target AWS services to anyone who will scan resources with IaC generator. For more information, see [IAM permissions required for scanning resources](generate-IaC.md#iac-generator-permissions). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"ResourceScanningOperations", "Effect":"Allow", "Action":[ "cloudformation:DescribeResourceScan", "cloudformation:GetResource", "cloudformation:ListResources", "cloudformation:ListResourceScanRelatedResources", "cloudformation:ListResourceScanResources", "cloudformation:ListResourceScans", "cloudformation:ListTypes", "cloudformation:StartResourceScan" ], "Resource":"*" }, { "Sid":"TemplateGeneration", "Effect":"Allow", "Action":[ "cloudformation:CreateGeneratedTemplate", "cloudformation:DeleteGeneratedTemplate", "cloudformation:DescribeGeneratedTemplate", "cloudformation:GetResource", "cloudformation:GetGeneratedTemplate", "cloudformation:ListGeneratedTemplates", "cloudformation:UpdateGeneratedTemplate" ], "Resource":"*" } ] } ``` ------ # AWS managed policies for AWS CloudFormation AWS managed policies An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: AWSCloudFormationFullAccess AWSCloudFormationFullAccess You can attach `AWSCloudFormationFullAccess` to your users, groups, and roles. This policy grants permissions that allow full access to CloudFormation actions and resources. **Permissions details** This policy includes the following permissions. + `cloudformation` – Allows principals to perform all CloudFormation actions on all resources. To view the permissions for this policy, see [AWSCloudFormationFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCloudFormationFullAccess.html) in the *AWS Managed Policy Reference Guide*. ## AWS managed policy: AWSCloudFormationReadOnlyAccess AWSCloudFormationReadOnlyAccess You can attach `AWSCloudFormationReadOnlyAccess` to your users, groups, and roles. This policy grants permissions that allow read-only access to CloudFormation resources and actions. **Permissions details** This policy includes the following permissions. + `cloudformation` – Allows principals to perform read-only CloudFormation actions such as describing stacks, listing resources, and viewing templates, but does not allow creating, updating, or deleting stacks. To view the permissions for this policy, see [AWSCloudFormationReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCloudFormationReadOnlyAccess.html) in the *AWS Managed Policy Reference Guide*. ## CloudFormation updates to AWS managed policies Policy updates View details about updates to AWS managed policies for CloudFormation since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the CloudFormation Document history page. | Change | Description | Date | | --- | --- | --- | | [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – Update to an existing policy | CloudFormation added new permissions to allow `cloudformation:BatchDescribe*` actions for batch describe operations. | January 30, 2026 | | [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – Update to an existing policy | CloudFormation added new permissions to allow `cloudformation:Detect*` actions for stack drift detection capabilities. | November 13, 2019 | | [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – Update to an existing policy | CloudFormation added new permissions to allow `cloudformation:EstimateTemplateCost`, `cloudformation:Get*`, and `cloudformation:ValidateTemplate` actions. | November 2, 2017 | | [AWSCloudFormationFullAccess](#security-iam-awsmanpol-AWSCloudFormationFullAccess) – New policy | CloudFormation added a new AWS managed policy that provides full access to CloudFormation actions and resources. | July 26, 2019 | | [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – Update to an existing policy | CloudFormation added new permissions to allow `cloudformation:DetectStackDrift` and `cloudformation:DetectStackResourceDrift` actions for stack drift detection. | February 6, 2019 | | [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – New policy | CloudFormation added a new AWS managed policy that provides read-only access to CloudFormation actions and resources. | February 6, 2015 | | CloudFormation started tracking changes | CloudFormation started tracking changes for its AWS managed policies. | February 6, 2015 | # CloudFormation service role A *service role* is an AWS Identity and Access Management (IAM) role that allows CloudFormation to make calls to resources in a stack on your behalf. You can specify an IAM role that allows CloudFormation to create, update, or delete your stack resources. By default, CloudFormation uses a temporary session that it generates from your user credentials for stack operations. If you specify a service role, CloudFormation uses that role's credentials. Use a service role to explicitly specify the actions that CloudFormation can perform, which might not always be the same actions that you or other users can do. For example, you might have administrative privileges, but you can limit CloudFormation access to only Amazon EC2 actions. You create the service role and its permission policy with the IAM service. For more information about creating a service role, see [Create a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) in the *IAM User Guide*. Specify CloudFormation (`cloudformation.amazonaws.com`) as the service that can assume the role. To associate a service role with a stack, specify the role when you create the stack. For details, see [Configure stack options](cfn-console-create-stack.md#configure-stack-options). You can also change the service role when you update the stack in the console, or [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeleteStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeleteStack.html) the stack through the API. Before you specify a service role, ensure that you have permission to pass it (`iam:PassRole`). The `iam:PassRole` permission specifies which roles you can use. For more information, see [Grant a user permissions to pass a role to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) in the *IAM User Guide*. **Important** When you specify a service role, CloudFormation always uses that role for all operations that are performed on that stack. It is not possible to remove a service role attached to a stack after the stack is created. Other users that have permissions to perform operations on this stack are able to use this role, regardless of whether those users have the `iam:PassRole` permission or not. If the role includes permissions that the user shouldn't have, you can unintentionally escalate a user's permissions. Ensure that the role grants least privilege. For more information, see [Apply least-privilege permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *IAM User Guide*. # Cross-service confused deputy prevention Cross-service confused deputy prevention The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In AWS, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it shouldn't otherwise have permission to access. To prevent this, AWS provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. We recommend using the [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that CloudFormation gives another service to a specific resource, such as a CloudFormation extension. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use. Make sure that the value of `aws:SourceArn` is an ARN of the resource that CloudFormation stores. The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws:cloudformation:*:123456789012:*`. If the `aws:SourceArn` value doesn't contain the account ID, you must use both global condition context keys to limit permissions. The following example shows how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in CloudFormation to prevent the confused deputy problem. ## Example trust policy that uses `aws:SourceArn` and `aws:SourceAccount` condition keys For registry services, CloudFormation makes calls to AWS Security Token Service (AWS STS) to assume a service role in your account. This role is configured for `ExecutionRoleArn` in the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_RegisterType.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_RegisterType.html) operation and `LogRoleArn` set in the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_LoggingConfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_LoggingConfig.html) operation. For more information, see [Configure an execution role with IAM permissions and a trust policy for public extension access](registry-public.md#registry-public-enable-execution-role). This example role trust policy uses condition statements to limit the `AssumeRole` capability on the service role to only actions on the specified CloudFormation extension in the specified account. The `aws:SourceArn` and `aws:SourceAccount` conditions are evaluated independently. Any request to use the service role must satisfy both conditions. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "resources.cloudformation.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnLike": { "aws:SourceArn": "arn:aws:cloudformation:us-east-1:123456789012:type/resource/Organization-Service-Resource" } } } ] } ``` ------ ## Additional information For example policies that use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys for a service role used by StackSets, see [Set up global keys to mitigate confused deputy problems](stacksets-prereqs-self-managed.md#confused-deputy-mitigation). For more information, see [Update a role trust policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) in the *IAM User Guide*. # Forward access sessions (FAS) requests and permission evaluation FAS requests and permission evaluation When creating, updating, and deleting CloudFormation stacks, users can optionally specify an IAM role ARN. If no role is provided, CloudFormation uses its default service mechanism to interact with other AWS services. In this scenario, the caller must have the necessary permissions for the resources being managed. Alternatively, when a user supplies their own IAM role, CloudFormation will assume that role to perform service interactions on their behalf. Regardless of whether the user provides an IAM role, CloudFormation generates a new scoped-down FAS token for each resource operation. Consequently, [FAS-related condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html#access_fas_policy_conditions), including `aws:ViaAWSService`, are populated in both scenarios. The use of FAS affects how IAM policies are evaluated during CloudFormation operations. When creating a stack with a template that includes resources affected by FAS-related condition keys, permission denials may occur. **Example IAM policy** Consider the following IAM policy. `Statement2` will consistently prevent the creation of an `AWS::KMS::Key` resource in CloudFormation. The restriction will be enforced consistently, whether or not an IAM role is provided during the stack operation. This is because the `aws:ViaAWSService` condition key is always set to `true` due to the use of FAS. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": [ "kms:CreateKey" ], "Resource": [ "*" ] }, { "Sid": "Statement2", "Effect": "Deny", "Action": [ "kms:CreateKey" ], "Resource": [ "*" ], "Condition": { "Bool": { "aws:ViaAWSService": "true" } } } ] } ``` ------ **Example stack template** For example, when a user creates a stack with the following example template, `aws:ViaAWSService` is set to `true`, and role permissions will be overridden by the FAS policy. Stack creation will be affected by `Statement2` of the IAM policy, which denies the `CreateKey` action. This results in a permission denied error. ``` Resources: myPrimaryKey: Type: AWS::KMS::Key Properties: Description: An example multi-Region primary key KeyPolicy: Version: '2012-10-17' Id: key-default-1 Statement: - Sid: Enable IAM User Permissions Effect: Allow Principal: AWS: !Join - '' - - 'arn:aws:iam::' - !Ref AWS::AccountId - ':root' Action: kms:* Resource: '*' ``` For more information about FAS, see [Forward access sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html) in the *IAM User Guide*. **Note** Most resources adhere to this behavior. However, if you experience unexpected success or failure when creating, updating, or deleting a resource, and your IAM policy includes FAS-related condition keys, it's likely that the resource in question belongs to a small subset of resources that don't follow this standard pattern.