Setting Values for CloudFormation Template (CFT) Parameters and Pseudo Parameters

When DevOps engineers write IaC templates, they'll often use parameters and pseudo parameters to enable using the same infrastructure for different purposes and environments. InsightCloudSec can run IaC scans on these templates without manually providing any values for them because the default value from the template is used (if one is specified) or a new value is generated as necessary (if there isn't a default specified).

However, InsightCloudSec can more accurately simulate IaC resources if it has the same parameter and pseudo parameter values that AWS does when CloudFormation creates a stack. To support these more accurate simulations, the mimics client accepts containing values for parameters using the --parameters-path flag and values for pseudo parameters using the --overrides-path flag.

CFT Parameters

Here's an example of a CFT defining an application that's deployed with different instance sizes in development and production environments:

yaml
1
AWSTemplateFormatVersion: "2010-09-09"
2
Description: Example template with parameterized instance sizes
3
Parameters:
4
  ParameterizedInstanceType:
5
    Type: String
6
    Default: t2.micro
7
    AllowedValues:
8
      - t2.micro
9
      - m1.large
10
    Description: Use large instances in production, small instances in development
11
Resources:
12
  AppInstance:
13
    Type: AWS::EC2::Instance
14
    Properties:
15
      InstanceType:
16
        Ref: ParameterizedInstanceType
17
      ImageId: example-ami

This template defines a parameter named ParameterizedInstanceType in its Parameters block, which is later used in the Resources block. As a result, DevOps users can specify it as a variable when the stack is created rather than in the template itself. In many automated workflows, they do so by specifying a parameter file to aws create-stack:

sh
1
aws cloudformation create-stack \
2
  --stack-name ExampleStack \
3
  --template-body file://template.yaml
4
  --parameters file://example-parameters.json

The file can have any name, so CloudFormation users simply pass that name to the create-stack subcommand. In this case, example-parameters.json contains a JSON array of parameter objects in an AWS-specific format:

json
1
[
2
  {
3
    "ParameterKey": "ParameterizedInstanceType",
4
    "ParameterValue": "m1.large"
5
  }
6
]

This is a simple example, but CFTs often have dozens of user-defined parameters. If no file is provided or if the parameter name isn't in the parameters file, CloudFormation will use the Default value with which the parameter was defined in the template.

Setting Parameter Values in InsightCloudSec CFT Scans

Because the create-stack command expects the format listed in the example above, DevOps teams using CFT probably already have files in this format. For convenience, the mimics --parameters-path flag accepts the same format; you can use these files without modification. InsightCloudSec uses the "ParameterKey" and "ParameterValue" keys in the objects and ignores all other keys.

For example, if a DevOps team sets parameter values in a file named example-parameters.json, you could provide it to mimics with a command like this:

sh
1
$ mimics scan \
2
    ./example-cft.json \
3
    --base-url=ics-url.net \
4
    --ics-config='Example Configuration Name' \
5
    --report-formats=html \
6
    --parameters-path=./example-parameters.json

As with CloudFormation, if no file is provided to InsightCloudSec or if the parameter name isn't in the parameters file, InsightCloudSec will use the Default value with which the parameter was defined in the template.

CFT Pseudo Parameters

CFT resources can also use values for AWS-specific parameters called pseudo parameters, which can specify the current account ID, region name, and other deployment-time values that can't be changed in templates. For example, it's common to dynamically generate ARNs for resources using the AWS::AccountId and AWS::Region pseudo parameters:

yaml
1
Resources:
2
  DynamicAccessPolicy:
3
    Type: AWS::IAM::Policy
4
    Properties:
5
      PolicyName: ExampleDynamicPolicy
6
      Roles:
7
        - Ref: ExampleRole
8
      PolicyDocument:
9
        Version: "2012-10-17"
10
        Statement:
11
          - Sid: ReceieveFromAny
12
            Effect: Allow
13
            Action:
14
              - sqs:ReceiveMessage
15
            Resource:
16
              - Fn::Join:
17
                  - ""
18
                  - - "arn:aws:sqs:"
19
                    - Ref: AWS::Region
20
                    - ":"
21
                    - Ref: AWS::AccountNumber
22
                    - ":*"

Note that CFT authors can't specify custom values for these parameters. Instead, AWS will substitute these values in the cloud when the stack is created. In this case, the ARN constructed in Fn::Join will be a valid ARN pattern for all SQS queues in the region and account in which the stack is created.

For accurate and complete analysis, it can be helpful to set these values for InsightCloudSec scans. For example, in the template above, providing the correct account number can help us accurately analyze for policies granting permissions to principals in unknown accounts.

Setting Pseudo Parameter Values in InsightCloudSec CFT Scans

To specify values for pseudo parameters, create a file to provide to the mimics --overrides flag. This file can have any name and should contain a single JSON object mapping pseudo parameter names to the values you want to substitute:

json
1
{
2
  "AWS::AccountId": "123456789012",
3
  "AWS::Region": "us-west-2"
4
}

Use this file with the --overrides flag to set these values in scans:

sh
1
$ mimics scan \
2
    ./example-cft.json \
3
    --base-url=ics-url.net \
4
    --ics-config='Example Configuration Name' \
5
    --report-formats=html \
6
    --overrides-path=./example-pseudo-params.json

You can also specify the names of user-specified parameters as keys; if you do, they will take precedent over values set in the file passed via --parameters-path. This allows you to override values in the parameters files your DevOps team uses without changing those configuration files:

json
1
{
2
  "AWS::AccountId": "123456789012",
3
  "AWS::Region": "us-west-2",
4
  "ParameterizedInstanceType": "fake.ics.scan.instance.type"
5
}

The values for pseudo parameters will likely be different depending on the pipeline in which the template is used; a single CFT could be used by many pipelines to define deployments in different environments. Work with CFT authors and pipeline teams to determine how to choose values for pseudo parameters in this file for each pipeline in which the template is used.