# Security in CloudFormation
Cloud security at AWS is the highest priority. As an AWS customer, you benefit from data centers and network architectures that are built to meet the requirements of the most security-sensitive organizations.
Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud:
+ **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to CloudFormation, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
This documentation helps you understand how to apply the shared responsibility model when using CloudFormation. The following topics show you how to configure CloudFormation to meet your security and compliance objectives. You also learn how to use other AWS services that help you to monitor and secure your CloudFormation resources.
**Topics**
+ [Protect CloudFormation stacks from being deleted](using-cfn-protect-stacks.md)
+ [Prevent updates to stack resources](protect-stack-resources.md)
+ [Data protection in CloudFormation](security-data-protection.md)
+ [Control CloudFormation access with AWS Identity and Access Management](control-access-with-iam.md)
+ [Logging CloudFormation API calls with AWS CloudTrail](cfn-api-logging-cloudtrail.md)
+ [Infrastructure security in CloudFormation](infrastructure-security.md)
+ [Resilience in CloudFormation](disaster-recovery-resiliency.md)
+ [Compliance validation for CloudFormation](cloudformation-compliance.md)
+ [Configuration and vulnerability analysis in CloudFormation](vulnerability-analysis-and-management.md)
+ [Security best practices for CloudFormation](security-best-practices.md)
+ [Access CloudFormation using an interface endpoint (AWS PrivateLink)](vpc-interface-endpoints.md)
# Protect CloudFormation stacks from being deleted
You can prevent a stack from being accidentally deleted by enabling termination protection on the stack. If a user attempts to delete a stack with termination protection enabled, the deletion fails and the stack, including its status, remains unchanged. You can enable termination protection on a stack when you create it. Termination protection on stacks is disabled by default. You can set termination protection on a stack with any status except `DELETE_IN_PROGRESS` or `DELETE_COMPLETE`.
Enabling or disabling termination protection on a stack passes the same choice on to any nested stacks belonging to that stack as well. You can't enable or disable termination protection directly on a nested stack. If a user attempts to directly delete a nested stack belonging with a stack that has termination protection enabled, the operation fails and the nested stack remains unchanged.
However, if a user performs a stack update that would delete the nested stack, CloudFormation deletes the nested stack accordingly.
Termination protection is different than disabling rollback. Termination protection applies only to attempts to delete stacks, while disabling rollback applies to auto rollback when stack creation fails.
**To enable termination protection when creating a stack**
On the **Specify stack options** page of the **Create stack** wizard, under **Advanced options**, expand the **Termination Protection** section and select **Enable**. For more information, see [Configure stack options](cfn-console-create-stack.md#configure-stack-options).
**To enable or disable termination protection on an existing stack**
1. Sign in to the AWS Management Console and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. On the navigation bar at the top of the screen, choose your AWS Region.
1. Select the stack that you want.
**Note**
If **NESTED** is displayed next to the stack name, the stack is a nested stack. You can only change termination protection on the root stack to which the nested stack belongs.
1. In the stack details pane, select **Stack actions** and then **Edit termination protection**.
CloudFormation displays the **Edit termination protection** dialog box.
1. Choose **Enable** or **Disable**, and then select **Save**.
**To enable or disable termination protection on a nested stack**
If **NESTED** is displayed next to the stack name, the stack is a nested stack. You can only change termination protection on the root stack to which the nested stack belongs. To change termination protection on the root stack:
1. Sign in to the AWS Management Console and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. On the navigation bar at the top of the screen, choose your AWS Region.
1. Select the nested stack that you want.
1. In the **Stack info** pane, in the **Overview** section, select the stack name listed as **Root stack**.
CloudFormation displays the stack details for the root stack.
1. Choose **Stack actions** and then choose **Edit Termination Protection**.
CloudFormation displays the **Edit termination protection** dialog box.
1. Choose **Enable** or **Disable**, and then select **Save**.
**To enable or disable termination protection using the command line**
Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-termination-protection.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-termination-protection.html) command.
## Controlling who can change termination protection on stacks
To enable or disable termination protection on stacks, a user requires permission to the `cloudformation:UpdateTerminationProtection` action. For example, the policy below allows users to enable or disable termination protection on stacks.
For more information on specifying permissions in CloudFormation, see [Control CloudFormation access with AWS Identity and Access Management](control-access-with-iam.md).
**Example A sample policy that grants permissions to change stack termination protection**
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"cloudformation:UpdateTerminationProtection"
],
"Resource":"*"
}]
}
```
# Prevent updates to stack resources
When you create a stack, all update actions are allowed on all resources. By default, anyone with stack update permissions can update all of the resources in the stack. During an update, some resources might require an interruption or be completely replaced, resulting in new physical IDs or completely new storage. You can prevent stack resources from being unintentionally updated or deleted during a stack update by using a stack policy. A stack policy is a JSON document that defines the update actions that can be performed on designated resources.
After you set a stack policy, all of the resources in the stack are protected by default. To allow updates on specific resources, you specify an explicit `Allow` statement for those resources in your stack policy. You can define only one stack policy per stack, but, you can protect multiple resources within a single policy. A stack policy applies to all CloudFormation users who attempt to update the stack. You can't associate different stack policies with different users.
A stack policy applies only during stack updates. It doesn't provide access controls like an AWS Identity and Access Management (IAM) policy. Use a stack policy only as a fail-safe mechanism to prevent accidental updates to specific stack resources. To control access to AWS resources or actions, use IAM.
**Topics**
+ [Example stack policy](#stack-policy-intro-example)
+ [Defining a stack policy](#stack-policy-reference)
+ [Setting a stack policy](#protect-stack-resources-protecting)
+ [Updating protected resources](#protect-stack-resources-updating)
+ [Modifying a stack policy](#protect-stack-resources-modifying)
+ [More example stack policies](#stack-policy-samples)
## Example stack policy
The following example stack policy prevents updates to the `ProductionDatabase` resource:
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
},
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
When you set a stack policy, all resources are protected by default. To allow updates on all resources, we add an `Allow` statement that allows all actions on all resources. Although the `Allow` statement specifies all resources, the explicit `Deny` statement overrides it for the resource with the `ProductionDatabase` logical ID. This `Deny` statement prevents all update actions, such as replacement or deletion, on the `ProductionDatabase` resource.
The `Principal` element is required, but supports only the wild card (`*`), which means that the statement applies to all [principals](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#principal).
**Note**
During a stack update, CloudFormation automatically updates resources that depend on other updated resources. For example, CloudFormation updates a resource that references an updated resource. CloudFormation makes no physical changes, such as the resource's ID, to automatically updated resources, but if a stack policy is associated with those resources, you must have permission to update them.
## Defining a stack policy
When you create a stack, no stack policy is set, so all update actions are allowed on all resources. To protect stack resources from update actions, define a stack policy and then set it on your stack. A stack policy is a JSON document that defines the CloudFormation stack update actions that CloudFormation users can perform and the resources that the actions apply to. You set the stack policy when you create a stack, by specifying a text file that contains your stack policy or typing it out. When you set a stack policy on your stack, any update not explicitly allowed is denied by default.
You define a stack policy with five elements: `Effect`, `Action`, `Principal`, `Resource`, and `Condition`. The following pseudo code shows stack policy syntax.
```
{
"Statement" : [
{
"Effect" : "Deny_or_Allow",
"Action" : "update_actions",
"Principal" : "*",
"Resource" : "LogicalResourceId/resource_logical_ID",
"Condition" : {
"StringEquals_or_StringLike" : {
"ResourceType" : [resource_type, ...]
}
}
}
]
}
```
`Effect`
Determines whether the actions that you specify are denied or allowed on the resource(s) that you specify. You can specify only `Deny` or `Allow`, such as:
```
"Effect" : "Deny"
```
If a stack policy includes overlapping statements (both allowing and denying updates on a resource), a `Deny` statement always overrides an `Allow` statement. To ensure that a resource is protected, use a `Deny` statement for that resource.
Action
Specifies the update actions that are denied or allowed:
Update:Modify
Specifies update actions during which resources might experience no interruptions or some interruptions while changes are being applied. All resources maintain their physical IDs.
Update:Replace
Specifies update actions during which resources are recreated. CloudFormation creates a new resource with the specified updates and then deletes the old resource. Because the resource is recreated, the physical ID of the new resource might be different.
Update:Delete
Specifies update actions during which resources are removed. Updates that completely remove resources from a stack template require this action.
Update:\$1
Specifies all update actions. The asterisk is a wild card that represents all update actions.
The following example shows how to specify just the replace and delete actions:
```
"Action" : ["Update:Replace", "Update:Delete"]
```
To allow all update actions except for one, use `NotAction`. For example, to allow all update actions except for `Update:Delete`, use `NotAction`, as shown in this example:
```
{
"Statement" : [
{
"Effect" : "Allow",
"NotAction" : "Update:Delete",
"Principal": "*",
"Resource" : "*"
}
]
}
```
Principal
The `Principal` element specifies the entity that the policy applies to. This element is required but supports only the wild card (`*`), which means that the policy applies to all [principals](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#principal).
Resource
Specifies the logical IDs of the resources that the policy applies to. To specify types of resources, use the `Condition` element.
To specify a single resource, use its logical ID. For example:
```
"Resource" : ["LogicalResourceId/myEC2instance"]
```
You can use a wild card with logical IDs. For example, if you use a common logical ID prefix for all related resources, you can specify all of them with a wild card:
```
"Resource" : ["LogicalResourceId/CriticalResource*"]
```
You can also use a `Not` element with resources. For example, to allow updates to all resources except for one, use a `NotResource` element to protect that resource:
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"NotResource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
When you set a stack policy, any update not explicitly allowed is denied. By allowing updates to all resources except for the `ProductionDatabase` resource, you deny updates to the `ProductionDatabase` resource.
Conditions
Specifies the resource type that the policy applies to. To specify the logical IDs of specific resources, use the `Resource` element.
You can specify a resource type, such as all EC2 and RDS DB instances, as shown in the following example:
```
{
"Statement" : [
{
"Effect" : "Deny",
"Principal" : "*",
"Action" : "Update:*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::EC2::Instance", "AWS::RDS::DBInstance"]
}
}
},
{
"Effect" : "Allow",
"Principal" : "*",
"Action" : "Update:*",
"Resource" : "*"
}
]
}
```
The `Allow` statement grants update permissions to all resources and the `Deny` statement denies updates to EC2 and RDS DB instances. The `Deny` statement always overrides allow actions.
You can use a wild card with resource types. For example, you can deny update permissions to all Amazon EC2 resources—such as instances, security groups, and subnets—by using a wild card, as shown in the following example:
```
"Condition" : {
"StringLike" : {
"ResourceType" : ["AWS::EC2::*"]
}
}
```
You must use the `StringLike` condition when you use wild cards.
## Setting a stack policy
You can use the console or AWS CLI to apply a stack policy when you create a stack. You can also use the AWS CLI to apply a stack policy to an existing stack. After you apply a stack policy, you can't remove it from the stack, but you can use the AWS CLI to modify it.
Stack policies apply to all CloudFormation users who attempt to update the stack. You can't associate different stack policies with different users.
For information about writing stack policies, see [Defining a stack policy](#stack-policy-reference).
**To set a stack policy when you create a stack (console)**
1. Open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. On the navigation bar at the top of the screen, choose the AWS Region to create the stack in.
1. On the **CloudFormation Stacks** page, choose **Create stack**.
1. In the Create Stack wizard, on the **Configure stack options** page, expand the **Advanced** section and then choose **Stack policy**.
1. Specify the stack policy:
+ To write a policy directly in the console, choose **Enter stack policy** and then type the stack policy directly in the text field.
+ To use a policy defined in a separate file, choose **Upload a file**, then **Choose file** to select the file containing the stack policy.
**To set a stack policy when you create a stack (AWS CLI)**
+ 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) command with the `--stack-policy-body` option to type in a modified policy or the `--stack-policy-url` option to specify a file containing the policy.
**To set a stack policy on an existing stack (AWS CLI only)**
+ Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html) command with the `--stack-policy-body` option to type in a modified policy or the `--stack-policy-url` option to specify a file containing the policy.
**Note**
To add a policy to an existing stack, you must have permission to the CloudFormation [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) action.
## Updating protected resources
To update protected resources, create a temporary policy that overrides the stack policy and allows updates on those resources. Specify the override policy when you update the stack. The override policy doesn't permanently change the stack policy.
To update protected resources, you must have permission to use the CloudFormation [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) action. For information about setting CloudFormation permissions, see [Control CloudFormation access with AWS Identity and Access Management](control-access-with-iam.md).
**Note**
During a stack update, CloudFormation automatically updates resources that depend on other updated resources. For example, CloudFormation updates a resource that references an updated resource. CloudFormation makes no physical changes, such as the resources' ID, to automatically updated resources, but if a stack policy is associated with those resources, you must have permission to update them.
**To update a protected resource (console)**
1. Open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. Select the stack that you want to update, choose **Stack actions**, and then choose **Update stack**.
1. If you *haven't* modified the stack template, select **Use current template**, and then click **Next**. If you have modified the template, select **Replace current template** and specify the location of the updated template in the **Specify template** section:
+ For a template stored locally on your computer, select **Upload a template file**. Choose **Choose File** to navigate to the file and select it, and then click **Next**.
+ For a template stored in an Amazon S3 bucket, select **Amazon S3 URL**. Enter or paste the URL for the template, and then click **Next**.
If you have a template in a versioning-enabled bucket, you can specify a specific version of the template template by appending `?versionId=version-id` to the URL. For more information, see [Working with objects in a versioning-enabled bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-objects-versioned-bucket.html) in the *Amazon Simple Storage Service User Guide*.
1. If your template contains parameters, on the **Specify stack details** page, enter or modify the parameter values, and then choose **Next**.
CloudFormation populates each parameter with the value that is currently set in the stack except for parameters declared with the `NoEcho` attribute. You can use current values for those parameters by choosing **Use existing value**.
For more information about using `NoEcho` to mask sensitive information, as well as using dynamic parameters to manage secrets, see the [Do not embed credentials in your templates](security-best-practices.md#creds) best practice.
1. Specify an override stack policy.
1. On the **Configure stack options** page, in the **Advanced options** section, select **Stack policy**.
1. Select **Upload a file**.
1. Click **Choose file** and navigate to the file that contains the overriding stack policy or type a policy.
1. Choose **Next**.
The override policy must specify an `Allow` statement for the protected resources that you want to update. For example, to update all protected resources, specify a temporary override policy that allows all updates:
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
**Note**
CloudFormation applies the override policy only during this update. The override policy doesn't permanently change the stack policy. To modify a stack policy, see [Modifying a stack policy](#protect-stack-resources-modifying).
1. Review the stack information and the changes that you submitted.
Check that you submitted the correct information, such as the correct parameter values or template URL. If your template contains IAM resources, choose **I acknowledge that this template may create IAM resources** to specify that you want to use IAM resources in the template. For more information, see [Acknowledging IAM resources in CloudFormation templates](control-access-with-iam.md#using-iam-capabilities).
In the **Preview your changes** section, check that CloudFormation will make all the changes that you expect. For example, check that CloudFormation adds, removes, and modifies the resources that you intended to add, remove, or modify. CloudFormation generates this preview by creating a change set for the stack. For more information, see [Update CloudFormation stacks using change sets](using-cfn-updating-stacks-changesets.md).
1. When you are satisfied with your changes, click **Update**.
**Note**
At this point, you also have the option to view the change set to review your proposed updates more thoroughly. To do so, click **View change set** instead of **Update**. CloudFormation displays the change set generated based on your updates. When you are ready to perform the stack update, click **Execute**.
CloudFormation displays the **Stack details** page for your stack. Your stack now has a status of `UPDATE_IN_PROGRESS`. After CloudFormation has successfully finished updating the stack, it sets the stack status to `UPDATE_COMPLETE`.
If the stack update fails, CloudFormation; automatically rolls back changes, and sets the stack status to `UPDATE_ROLLBACK_COMPLETE`.
**To update a protected resource (AWS CLI)**
+ Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html) command with the `--stack-policy-during-update-body` option to type in a modified policy or the `--stack-policy-during-update-url` option to specify a file containing the policy.
**Note**
CloudFormation applies the override policy only during this update. The override policy doesn't permanently change the stack policy. To modify a stack policy, see [Modifying a stack policy](#protect-stack-resources-modifying).
## Modifying a stack policy
To protect additional resources or to remove protection from resources, modify the stack policy. For example, when you add a database that you want to protect to your stack, add a `Deny` statement for that database to the stack policy. To modify the policy, you must have permission to use the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) action.
Use the AWS CLI to modify stack policies.
**To modify a stack policy (AWS CLI)**
+ Use the [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html) command with the `--stack-policy-body` option to type in a modified policy or the `--stack-policy-url` option to specify a file containing the policy.
You can't delete a stack policy. To remove all protection from all resources, you modify the policy to explicitly allow all actions on all resources. The following policy allows all updates on all resources:
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
## More example stack policies
The following example policies show how to prevent updates to all stack resources and to specific resources, and prevent specific types of updates.
### Prevent updates to all stack resources
To prevent updates to all stack resources, the following policy specifies a `Deny` statement for all update actions on all resources.
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### Prevent updates to a single resource
The following policy denies all update actions on the database with the `MyDatabase` logical ID. It allows all update actions on all other stack resources with an `Allow` statement. The `Allow` statement doesn't apply to the `MyDatabase` resource because the `Deny` statement always overrides allow actions.
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "LogicalResourceId/MyDatabase"
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
You can achieve the same result as the previous example by using a default denial. When you set a stack policy, CloudFormation denies any update that is not explicitly allowed. The following policy allows updates to all resources except for the `ProductionDatabase` resource, which is denied by default.
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"NotResource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
**Important**
There is risk in using a default denial. If you have an `Allow` statement elsewhere in the policy (such as an `Allow` statement that uses a wildcard), you might unknowingly grant update permission to resources that you don't intend to. Because an explicit denial overrides any allow actions, you can ensure that a resource is protected by using a `Deny` statement.
### Prevent updates to all instances of a resource type
The following policy denies all update actions on the RDS DB instance resource type. It allows all update actions on all other stack resources with an `Allow` statement. The `Allow` statement doesn't apply to the RDS DB instance resources because a `Deny` statement always overrides allow actions.
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::RDS::DBInstance"]
}
}
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### Prevent replacement updates for an instance
The following policy denies updates that would cause a replacement of the instance with the `MyInstance` logical ID. It allows all update actions on all other stack resources with an `Allow` statement. The `Allow` statement doesn't apply to the `MyInstance` resource because the `Deny` statement always overrides allow actions.
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:Replace",
"Principal": "*",
"Resource" : "LogicalResourceId/MyInstance"
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### Prevent updates to nested stacks
The following policy denies all update actions on the CloudFormation stack resource type (nested stacks). It allows all update actions on all other stack resources with an `Allow` statement. The `Allow` statement doesn't apply to the CloudFormation stack resources because the `Deny` statement always overrides allow actions.
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::CloudFormation::Stack"]
}
}
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
# Data protection in CloudFormation
The AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) applies to data protection in AWS CloudFormation. As described in this model, AWS is responsible for protecting the global infrastructure that runs all of the AWS Cloud. You are responsible for maintaining control over your content that is hosted on this infrastructure. You are also responsible for the security configuration and management tasks for the AWS services that you use. For more information about data privacy, see the [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). For information about data protection in Europe, see the [AWS Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) blog post on the *AWS Security Blog*.
For data protection purposes, we recommend that you protect AWS account credentials and set up individual users with AWS IAM Identity Center or AWS Identity and Access Management (IAM). That way, each user is given only the permissions necessary to fulfill their job duties. We also recommend that you secure your data in the following ways:
+ Use multi-factor authentication (MFA) with each account.
+ Use SSL/TLS to communicate with AWS resources. We require TLS 1.2 and recommend TLS 1.3.
+ Set up API and user activity logging with AWS CloudTrail. For information about using CloudTrail trails to capture AWS activities, see [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) in the *AWS CloudTrail User Guide*.
+ Use AWS encryption solutions, along with all default security controls within AWS services.
+ Use advanced managed security services such as Amazon Macie, which assists in discovering and securing sensitive data that is stored in Amazon S3.
+ If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
We strongly recommend that you never put confidential or sensitive information, such as your customers' email addresses, into tags or free-form text fields such as a **Name** field. This includes when you work with CloudFormation or other AWS services using the console, API, AWS CLI, or AWS SDKs. Any data that you enter into tags or free-form text fields used for names may be used for billing or diagnostic logs. If you provide a URL to an external server, we strongly recommend that you do not include credentials information in the URL to validate your request to that server.
## Encryption at rest
Following the AWS shared responsibility model, CloudFormation stores your data encrypted at rest. Customers are responsible for setting encryption and storage policies for data stored in their accounts. For example, we recommend enabling at-rest encryption for templates and other data stored in S3 buckets or SNS topics. Customers similarly define encryption settings for any data storage systems provisioned by CloudFormation.
## Encryption in transit
CloudFormation uses encrypted channels for service communications under the shared responsibility model.
## Internetwork traffic privacy
CloudFormation service communications are securely encrypted by default between Regions or Availability Zones.
# Control CloudFormation access with AWS Identity and Access Management
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
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
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
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
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
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
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
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.
# Logging CloudFormation API calls with AWS CloudTrail
CloudFormation is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an AWS service in CloudFormation. CloudTrail captures all API calls for CloudFormation as events, including calls from the CloudFormation console and from code calls to the CloudFormation APIs. If you create a trail, you can enable continuous delivery of CloudTrail events to an Amazon S3 bucket, including events for CloudFormation. If you don't configure a trail, you can still view the most recent events in the CloudTrail console in **Event history**. Using the information collected by CloudTrail, you can determine the request that was made to CloudFormation, the IP address from which the request was made, who made the request, when it was made, and additional details.
To learn more about CloudTrail, see the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
**Topics**
+ [CloudFormation information in CloudTrail](#cloudformation_info_in_cloudtrail)
+ [Understanding CloudFormation log file entries](#understanding_cloudformation_entries)
## CloudFormation information in CloudTrail
CloudTrail is enabled on your AWS account when you create the account. When activity occurs in CloudFormation, that activity is recorded in a CloudTrail event along with other AWS service events in **Event history**. You can view, search, and download recent events in your AWS account. For more information, see [Viewing events with CloudTrail event history](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
For an ongoing record of events in your AWS account, including events for CloudFormation, create a trail. A trail enables CloudTrail to deliver log files to an Amazon S3 bucket. By default, when you create a trail in the console, the trail applies to all Regions. The trail logs events from all Regions in the AWS partition and delivers the log files to the Amazon S3 bucket that you specify. Additionally, you can configure other AWS services to further analyze and act upon the event data collected in CloudTrail logs. For more information, see:
+ [Overview for creating a trail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail supported services and integrations](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configuring Amazon SNS notifications for CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)
+ [Receiving CloudTrail log files from multiple Regions](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) and [Receiving CloudTrail log files from multiple accounts](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
All CloudFormation actions are logged by CloudTrail and are documented in the [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_Operations.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_Operations.html). For example, calls to the `CreateStack`, `DeleteStack`, and `ListStacks` sections generate entries in the CloudTrail log files.
Every event or log entry contains information about who generated the request. The identity information helps you determine the following:
+ Whether the request was made with root or IAM user credentials.
+ Whether the request was made with temporary security credentials for a role or federated user.
+ Whether the request was made by another AWS service.
For more information, see the [CloudTrail userIdentity element](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Understanding CloudFormation log file entries
A trail is a configuration that enables delivery of events as log files to an Amazon S3 bucket that you specify. CloudTrail log files contain one or more log entries. An event represents a single request from any source and includes information about the requested operation, the date and time of the operation, request parameters, and so on. CloudTrail log files aren't an ordered stack trace of the public API calls, so they don't appear in any specific order.
The following example shows a CloudTrail log entry that demonstrates the `CreateStack` operation. The operation was made by an IAM user named Alice.
**Note**
Only the input parameter key names are logged. Parameter values aren't logged.
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:02:43Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "CreateStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"templateURL": "templateURL",
"tags": [
{
"key": "test",
"value": "tag"
}
],
"stackName": "my-test-stack",
"disableRollback": true,
"parameters": [
{
"parameterKey": "password"
},
{
"parameterKey": "securitygroup"
}
]
},
"responseElements": {
"stackId": "arn:aws:cloudformation:us-east-1:012345678910:stack/my-test-stack/a38e6a60-b397-11e3-b0fc-08002755629e"
},
"requestID": "9f960720-b397-11e3-bb75-a5b75389b02d",
"eventID": "9bf6cfb8-83e1-4589-9a70-b971e727099b"
}
```
The following example shows that Alice called the `UpdateStack` operation on the `my-test-stack` stack:
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:04:29Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "UpdateStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"templateURL": "templateURL",
"parameters": [
{
"parameterKey": "password"
},
{
"parameterKey": "securitygroup"
}
],
"stackName": "my-test-stack"
},
"responseElements": {
"stackId": "arn:aws:cloudformation:us-east-1:012345678910:stack/my-test-stack/a38e6a60-b397-11e3-b0fc-08002755629e"
},
"requestID": "def0bf5a-b397-11e3-bb75-a5b75389b02d",
"eventID": "637707ce-e4a3-4af1-8edc-16e37e851b17"
}
```
The following example shows that Alice called the `ListStacks` operation.
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:03:16Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "ListStacks",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": null,
"responseElements": null,
"requestID": "b7d351d7-b397-11e3-bb75-a5b75389b02d",
"eventID": "918206d0-7281-4629-b778-b91eb0d83ce5"
}
```
The following example shows that Alice called the `DescribeStacks` operation on the `my-test-stack` stack.
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:06:15Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "DescribeStacks",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"stackName": "my-test-stack"
},
"responseElements": null,
"requestID": "224f2586-b398-11e3-bb75-a5b75389b02d",
"eventID": "9e5b2fc9-1ba8-409b-9c13-587c2ea940e2"
}
```
The following example shows that Alice called the `DeleteStack` operation on the `my-test-stack` stack.
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:07:15Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "DeleteStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"stackName": "my-test-stack"
},
"responseElements": null,
"requestID": "42dae739-b398-11e3-bb75-a5b75389b02d",
"eventID": "4965eb38-5705-4942-bb7f-20ebe79aa9aa"
}
```
# Infrastructure security in CloudFormation
As a managed service, AWS CloudFormation is protected by AWS global network security. For information about AWS security services and how AWS protects infrastructure, see [AWS Cloud Security](https://aws.amazon.com/security/). To design your AWS environment using the best practices for infrastructure security, see [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
You use AWS published API calls to access CloudFormation through the network. Clients must support the following:
+ Transport Layer Security (TLS). We require TLS 1.2 and recommend TLS 1.3.
+ Cipher suites with perfect forward secrecy (PFS) such as DHE (Ephemeral Diffie-Hellman) or ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Most modern systems such as Java 7 and later support these modes.
You can call these API operations from any network location, but CloudFormation does support resource-based access policies, which can include restrictions based on the source IP address. You can also use CloudFormation policies to control access from specific Amazon Virtual Private Cloud (Amazon VPC) endpoints or specific VPCs. Effectively, this isolates network access to a given CloudFormation resource from only the specific VPC within the AWS network.
# Resilience in CloudFormation
The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.
For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/).
# Compliance validation for CloudFormation
To learn whether an AWS service is within the scope of specific compliance programs, see [AWS services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) and choose the compliance program that you are interested in. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/).
You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Your compliance responsibility when using AWS services is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. For more information about your compliance responsibility when using AWS services, see [AWS Security Documentation](https://docs.aws.amazon.com/security/).
# Configuration and vulnerability analysis in CloudFormation
Configuration and IT controls are a shared responsibility between AWS and you, our customer. For more information, see the AWS [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/).
# Security best practices for CloudFormation
CloudFormation provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions.
**Topics**
+ [Use IAM to control access](#use-iam-to-control-access)
+ [Do not embed credentials in your templates](#creds)
+ [Use AWS CloudTrail to log CloudFormation calls](#cloudtrail)
## Use IAM to control access
IAM is an AWS service that you can use to manage users and their permissions in AWS. You can use IAM with CloudFormation to specify what CloudFormation actions users can perform, such as viewing stack templates, creating stacks, or deleting stacks. Furthermore, anyone managing CloudFormation stacks will require permissions to resources within those stacks. For example, if users want to use CloudFormation to launch, update, or terminate Amazon EC2 instances, they must have permission to call the relevant Amazon EC2 actions.
In most cases, users require full access to manage all of the resources in a template. CloudFormation makes calls to create, modify, and delete those resources on their behalf. To separate permissions between a user and the CloudFormation service, use a service role. CloudFormation uses the service role's policy to make calls instead of the user's policy. For more information, see [CloudFormation service role](using-iam-servicerole.md).
## Do not embed credentials in your templates
Rather than embedding sensitive information in your CloudFormation templates, we recommend you use *dynamic references* in your stack template.
Dynamic references provide a compact, powerful way for you to reference external values that are stored and managed in other services, such as the AWS Systems Manager Parameter Store or AWS Secrets Manager. When you use a dynamic reference, CloudFormation retrieves the value of the specified reference when necessary during stack and change set operations, and passes the value to the appropriate resource. However, CloudFormation never stores the actual reference value. For more information, see [Get values stored in other services using dynamic references](dynamic-references.md).
[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) helps you to securely encrypt, store, and retrieve credentials for your databases and other services. The [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) provides secure, hierarchical storage for configuration data management.
For more information on defining template parameters, see [CloudFormation template Parameters syntax](parameters-section-structure.md).
## Use AWS CloudTrail to log CloudFormation calls
AWS CloudTrail tracks anyone making CloudFormation API calls in your AWS account. API calls are logged whenever anyone uses the CloudFormation API, the CloudFormation console, a back-end console, or CloudFormation AWS CLI commands. Enable logging and specify an Amazon S3 bucket to store the logs. That way, if you ever need to, you can audit who made what CloudFormation call in your account. For more information, see [Logging CloudFormation API calls with AWS CloudTrail](cfn-api-logging-cloudtrail.md).
# Access CloudFormation using an interface endpoint (AWS PrivateLink)
You can use AWS PrivateLink to create a private connection between your VPC and CloudFormation. You can access CloudFormation as if it were in your VPC, without the use of an internet gateway, NAT device, VPN connection, or Direct Connect connection. Instances in your VPC don't need public IP addresses to access CloudFormation.
You establish this private connection by creating an *interface endpoint*, powered by AWS PrivateLink. We create an endpoint network interface in each subnet that you enable for the interface endpoint. These are requester-managed network interfaces that serve as the entry point for traffic destined for CloudFormation.
CloudFormation supports making calls to all of its API actions through the interface endpoint.
## Considerations for CloudFormation VPC endpoints
Before you set up an interface endpoint, first make sure you have met the prerequisites in the [Access an AWS service using an interface VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) topic in the *AWS PrivateLink Guide*.
The following additional prerequisites and considerations apply when setting up an interface endpoint for CloudFormation:
+ If you have resources within your VPC that must respond to a custom resource request or a wait condition, make sure that they have access to the required CloudFormation-specific Amazon S3 buckets. CloudFormation has S3 buckets in each Region to monitor responses to a [custom resource](template-custom-resources.md) request or a [wait condition](using-cfn-waitcondition.md). If a template includes custom resources or wait conditions in a VPC, the VPC endpoint policy must allow users to send responses to the following buckets:
+ For custom resources, permit traffic to the `cloudformation-custom-resource-response-region` bucket. When using custom resources, AWS Region names don't contain dashes. For example, `uswest2`.
+ For wait conditions, permit traffic to the `cloudformation-waitcondition-region` bucket. When using wait conditions, AWS Region names do contain dashes. For example, `us-west-2`.
If the endpoint policy blocks traffic to these buckets, CloudFormation won't receive responses and the stack operation fails. For example, if you have a resource in a VPC in the `us-west-2` Region that must respond to a wait condition, the resource must be able to send a response to the `cloudformation-waitcondition-us-west-2` bucket.
For a list of AWS Regions where CloudFormation is currently available, see the [CloudFormation endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cfn.html) page in the *Amazon Web Services General Reference*.
+ VPC endpoints currently don't support cross-Region requests — ensure that you create your endpoint in the same Region in which you plan to issue your API calls to CloudFormation.
+ VPC endpoints only support Amazon-provided DNS through Route 53. If you want to use your own DNS, you can use conditional DNS forwarding. For more information, see [DHCP options sets in Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html) in the Amazon VPC User Guide.
+ The security group attached to the VPC endpoint must allow incoming connections on port 443 from the private subnet of the VPC.
## Creating an interface VPC endpoint for CloudFormation
You can create a VPC endpoint for CloudFormation using either the Amazon VPC console or the AWS Command Line Interface (AWS CLI). For more information, see [Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) in the *AWS PrivateLink Guide*.
Create an interface endpoint for CloudFormation using the following service name:
+ **com.amazonaws.*region*.cloudformation** – Creates an endpoint for CloudFormation API operations.
If you enable private DNS for the interface endpoint, you can make API requests to CloudFormation using its default Regional DNS name. For example, `cloudformation.us-east-1.amazonaws.com`.
In AWS Regions where FIPS-specific endpoints are supported, you can also create an interface endpoint for CloudFormation using the following service name:
+ **com.amazonaws.*region*.cloudformation-fips** – Creates an endpoint for the CloudFormation API that complies with [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/).
For a complete list of CloudFormation endpoints, see [CloudFormation endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cfn.html) in the *Amazon Web Services General Reference*.
## Creating a VPC endpoint policy for CloudFormation
An endpoint policy is an IAM resource that you can attach to an interface endpoint. The default endpoint policy allows full access to CloudFormation through the interface endpoint. To control the access allowed to CloudFormation from your VPC, attach a custom endpoint policy to the interface endpoint.
An endpoint policy specifies the following information:
+ The principals that can perform actions (AWS accounts, IAM users, and IAM roles).
+ The actions that can be performed.
+ The resources on which the actions can be performed.
For more information, see [Control access to VPC endpoints using endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) in the *AWS PrivateLink Guide*.
**Example: VPC endpoint policy for CloudFormation actions**
The following is an example of an endpoint policy for CloudFormation. When attached to an endpoint, this policy grants access to the listed CloudFormation actions for all principals on all resources. The following example denies all users the permission to create stacks through the VPC endpoint, and allows full access to all other actions on the CloudFormation service.
```
{
"Statement": [
{
"Action": "cloudformation:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
},
{
"Action": "cloudformation:CreateStack",
"Effect": "Deny",
"Principal": "*",
"Resource": "*"
}
]
}
```