Stack Policies

Get working knowledge of managing CloudFormation stacks with stack policies.

We'll cover the following

Just like we restrict different users’ actions on different resources through IAM policies, we can also configure stack policies to define permissible actions on the CloudFormation stack resources.

Managing stack workflows with policies

We can define a stack policy as a JSON document that defines the permissible and impermissible actions that can be applied to the CloudFormation stack resources.

Press + to interact

The following diagram illustrates the workflow of the AWS CloudFormation Service when a stack policy is implemented. In this example, the user makes changes in the stack that we’ve denied in the stack policy:

Press + to interact
Workflow of how the stack policy restricts updates in a stack
Workflow of how the stack policy restricts updates in a stack

It’s useful to describe stack policies for stack with especially critical resources that cannot be modified or deleted. These resources need to be safeguarded from any unintended or unauthorized actions.

Anatomy of a stack policy

A stack policy is somewhat similar to a basic IAM resource policy. To illustrate, here’s the sample template for a stack policy:

Press + to interact
{
  "Statement" : [
    {
      "Effect" : "<Deny|Allow>",
      "Action" : "Update:<Modify|Replace|Delete|*>",
      "Principal" : "*",
      "Resource" : "LogicalResourceId/<LOGICAL_ID>",
      "Condition" : {
        "StringEquals|StringLike" : {
          "ResourceType" : [
            "<Allowed Resource Type List>"
          ]
        }
      }
    }
  ]
}

Here’s a breakdown of all the components in the stack policy template:

  • Effect (Required): This specifies if the associated actions are to be permissible or impermissible. The only acceptable values are either Allow or Deny. The Deny value is an explicit denial and overrides the Allow action.

  • Action (Required): This contains the list of update actions that we can either perform or not. We don’t need to use it if we’re already using the alternate NotAction component. It can have the following values:

    • Update:Modify: It’s used to allow/deny actions that cause no or little disruption during the update. All resources within the stack can only be modified. None of the resources will be replaced and hence, will maintain their physical IDs.

    • Update:Replace: It’s used to allow/deny actions that recreate a stack resource. This allows us to update the stack when a resource needs to be deleted and then replaced by a new one. The physical IDs can change in this case.

    • Update:Delete: It’s used to allow/deny actions that completely remove a resource from a stack.

    • Update:*: It’s a wild card that’s used to allow/deny all update actions.

  • NotAction (Required): This can be used to allow/deny all update actions except one specific one. We don’t need to use it if we’re already using the alternate Action component.

  • Principal (Required): This specifies the entities (such as an IAM user, roles) on whom this policy is applicable. We can only provide the wild card (*) value to the Principal, implying that the policy is applied to all principals.

  • Condition (Optional): This can be a list of additional restrictions regarding when a policy can be in effect.

Example stack policy

Here’s an example stack policy where we’ve used both Deny and Allow cases:

Press + to interact
{
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : "*",
      "Principal" : "*",
      "Resource" : "*"
    },
    {
      "Effect" : "Deny",
      "Action" : "Update:Modify",
      "Principal" : "*",
      "Resource" : [
        "LogicalResourceId/Instance"
      ],
      "Condition" : {
        "StringEquals" : {
          "ResourceType" : [
            "AWS::EC2::Instance"
          ]
        }
      }
    }
  ]
}

In the stack policy above, we define two statements. The first statement uses the wild card value and allows all stack update actions. The second statement uses the Deny effect to explicitly deny the Update:Modify action for an EC2 instance with the Instance logical ID. We also use a condition to only apply these to AWS resources that are of the EC2 instance type (AWS::EC2::Instance).

Best practices

Here are some best practices that we can use when managing CloudFormation stacks:

  • Utilize stack policies: Stack policies prevent any unintentional changes or deletions to any AWS resources provisioned within a stack.

  • Update EC2 instances’ runtimes regularly: We should regularly execute appropriate OS-specific commands to update the runtime and ensure the latest fixes and security patches are applied. For example, we can execute the yum update command on Amazon Linux-based environments to update the RPM package responsible for installing, uninstalling, and managing any software packages.

  • Utilize IAM for controlling access: We need to properly use the AWS IAM service to manage users and their access to the AWS cloud.

    • For example, IAM users deploying CloudFormation stacks need the appropriate permissions to create and manage CloudFormation stacks and the AWS resources being provisioned with them. Alternatively, we can set a service role for AWS CloudFormation with the appropriate permissions instead of relying on the policy associated with the IAM user.

  • Utilize CloudTrail to track CloudFormation calls: We can use the AWS CloudTrail service to log all the CloudFormation service calls made within our AWS account to track who made what call and what services got created or deleted.

    • For example, this can be useful when auditing activity in our AWS account in case anything unexpected happens with a CloudFormation stack and the resources provisioned within it.

This lesson taught us about managing CloudFormation stacks using stack policies.

Get hands-on with 1300+ tech skills courses.