Bug: Lambda Functions in nested templates are not signed

[stojanovic]

Description:

Configuring Lambda code signing by following this tutorial works fine unless you add a nested template. SAM CLI will sign all the functions in the main template but skip Lambda functions in all nested templates.

Steps to reproduce:

1. Create a SAM template with a signing profile, signing configuration, and one Lambda function (with code signing turned on).
2. Create a nested stack that accepts the signing profile as a parameter and has another Lambda function (with code signing turned on).
3. Run the sam deploy --guided command to create the samconfig.toml file with the signing profiles configuration for both functions.
4. Run the sam deploy command.

A sample SAM template can look like the following:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Sample main SAM template

Resources:
  FunctionSignerProfile:
    Type: AWS::Signer::SigningProfile
    Properties: 
      PlatformId: AWSLambda-SHA384-ECDSA

  CodeSigningConfig:
    Type: AWS::Lambda::CodeSigningConfig
    Properties:
      Description: Turn on code signing
      AllowedPublishers:
        SigningProfileVersionArns:
          - !GetAtt FunctionSignerProfile.ProfileVersionArn
      CodeSigningPolicies:
        UntrustedArtifactOnDeployment: Enforce

  Function1:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./path/to/func1
      Handler: lambda.handler
      CodeSigningConfigArn: !Ref CodeSigningConfig
      Runtime: nodejs16.x
      Timeout: 30

  NestedStack:
    Type: AWS::Serverless::Application
    Properties:
      Location: ./nested-template.yaml
      Parameters:
        SigningProfileArn: !Ref CodeSigningConfig

Nested template can look like the following:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Sample main SAM template

Parameters:
  Parameters:
    SigningProfileArn:
      Type: String
      Description: Lambda code signing profile Arn

Resources:
  Function2:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./path/to/func2
      Handler: lambda.handler
      CodeSigningConfigArn: !Ref SigningProfileArn
      Runtime: nodejs16.x
      Timeout: 30

Observed result:

The Function1 Lambda is signed as expected, but the Fuction2 Lambda is not signed.

Here's the key part of the sam deploy --debug command (the full output is too long):

2023-01-20 13:15:41,726 | Sam customer defined id is more priority than other IDs. Customer defined id for resource Function1 is Function1
2023-01-20 13:15:41,768 | File with same data already exists at bucket/92c6bbf94a549c715fdf9880xxxxxxxx.zip, skipping upload
2023-01-20 13:15:41,816 | S3 Object (s3://aws-sam-cli-managed-default-samclisourcebucket-1vq9k2wio9z60/bucket/92c6bbf94a549c715fdf9880xxxxxxxx.zip) tagging information {'ResponseMetadata': {'RequestId': 'YSQWQPWXRNMNxxxx', 'HostId': '4unfDZdlLxxxx/omeGHAEAGyZUPRlgU5Ymru1S9zGQOMVowQJ9CkmEb6S+ag3vyw8cotJ6bHHjfxxxx+xxxxxx==', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amz-id-2': '4unfDZdlLxxxx/omeGHAEAGyZUPRlgU5Ymru1S9zGQOMVowQJ9CkmEb6S+ag3vyw8cotJ6bHHjfxxxx+xxxxxx==', 'x-amz-request-id': 'YSQWQPWXRNMNVX7H', 'date': 'Fri, 20 Jan 2023 12:15:42 GMT', 'x-amz-version-id': 'xymwwpMypX4dEJc2m8hz9oo9oKxxxxxx', 'transfer-encoding': 'chunked', 'server': 'AmazonS3'}, 'RetryAttempts': 0}, 'VersionId': 'xymwwpMypX4dEJc2m8hz9oo9oKxxxxxx', 'TagSet': []}
2023-01-20 13:15:41,816 | Initiating signing job with bucket:aws-sam-cli-managed-default-samclisourcebucket-1vq9k2wio9z60 key:bucket/92c6bbf94a549c715fdf9880xxxxxxxx.zip version:xymwwpMypX4dEJc2m8hz9oo9oKxxxxxx prefix:bucket/signed_ profile name:FunctionSignerProfile_8tYP6yxxxxxx profile owner:
2023-01-20 13:15:42,309 | Initiated code signing job f46a97a1-fa66-4b99-82a3-f49dddxxxxxx
2023-01-20 13:15:47,539 | Package has successfully signed into the location aws-sam-cli-managed-default-samclisourcebucket-1vq9k2wio9z60/bucket/signed_f46a97a1-fa66-4b99-82a3-f49dddxxxxxx.zip
2023-01-20 13:15:47,540 | Sam customer defined id is more priority than other IDs. Customer defined id for resource NestedStack is NestedStack
2023-01-20 13:15:47,569 | There is no customer defined id or cdk path defined for resource CreateAuthChallenge, so we will use the resource logical id as the resource id
2023-01-20 13:15:47,627 | File with same data already exists at bucket/92c6bbf94a549c715fdf9880xxxxxxxx, skipping upload
2023-01-20 13:15:47,627 | Sam customer defined id is more priority than other IDs. Customer defined id for resource CreateAuthChallenge is CreateAuthChallenge
Uploading to bucket/cdc1d17f8d481c27be4c8e4e33xxxxxx  426453 / 426453  (100.00%)

Expected result:

Both Lambda functions should be signed.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

1. OS: macOs 13.1 (22C65)
2. sam --version: SAM CLI, version 1.67.0
3. AWS region: eu-central-1

{
  "version": "1.67.0"
}

[qingchm]

Thanks for providing us details in the report! We will try to reproduce and understand the behaviour here

[matthewcmorgan]

I have observed identical behavior with nested stacks when using the sam package ... command. Nested functions are not detected and not signed.

As a workaround, I found that performing the sam package ... directly on the nested stack with the function, using the --output-template-file option, then referencing that expected output-template-file in your parent template, then running sam package ... again, against the parent template. The cli will detect that the nested stack is already an s3 url and package it correctly with the the parent template.

sam package --signing-profiles Function1=$SIGNING_PROFILE_NAME \
Function2=$SIGNING_PROFILE_NAME --template-file nested-stack.yaml \
--s3-bucket $bucket --output-template-file nested-stack.yaml.signed
          
sam package --signing-profiles Function1=$SIGNING_PROFILE_NAME \
Function2=$SIGNING_PROFILE_NAME --template-file parent-stack.yaml \
--s3-bucket $bucket --output-template-file parent-stack.yaml.signed