Code Signing via CloudFormation?

[jplock]

Describe your idea/feature/enhancement

Related to #2407, is it possible to deploy a code signed Lambda function using CloudFormation or do you have to use sam deploy? We have CodePipeline's configured that run sam package from CodeBuild, but then use CodePipeline's CloudFormation integration to provisioned the packaged YAML file template (so we don't run sam deploy in our pipeline). CloudFormation returns an error message:

Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept.

Reading https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/authoring-codesigning.html and https://aws.amazon.com/blogs/aws/new-code-signing-a-trust-and-integrity-control-for-aws-lambda/, it's not clear whether this is supported or not.

Thanks.

[mndeveci]

Hi @jplock ,

Code signing is supported with both deploy and package commands. You can use sam package --signing-profile MyFunctionName=MySigningProfile ... just for packaging and signing the artifact which is uploaded to s3 bucket. This will also update template with signed artifact locations.

Please let us know if this works for you.

Thanks

[jplock]

Right so that’s happening and I see the signed packages in S3 and the template is updated to point to them. But then if I upload the template directly into CloudFormation I get that “not configured to accept” message. Do I have to grant access to cloudformation.amazonaws.com to be able to read the signing profile somehow?

[jplock]

The error seems to be coming from the Lambda service based on the actual exception visible in the CloudFormation event when it starts rolling back the stack.

[mndeveci]

I talked with the Lambda team and they said this might be caused if you have signed code using a signing profile that is not included in the code signing config in your template. Can you confirm that you are using same signing profile in your template and when packaging your code?

They also sent this main documentation page for code signer; https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html

[jplock]

Oh interesting. So in this case, I created the code signing config outside of the template and just referenced the ARN in the CodeSigningConfigArn property so I could reuse the signing config across multiple stacks each creating separate Lambda functions (but I want them to all use the same signing config).

Is that supported or should each CloudFormation stack create it's own code signing configuration (which reference the same underlying signing profile)?

Thanks for looking into this.

[mndeveci]

Yes this should work fine. One thing I can suggest to look at is the property that you assigned in SigningProfileVersionArns in AWS::Lambda::CodeSigningConfig resource. They should be profileVersionArn of the signing profile, not the ARN of the signing profile.

I will create and test it by creating 2 stacks,

• First one will only contain the signing profile and code signing config
• Second one will use the code signing config and signing profile from the first one

And if you can provide us the example template that you used which re-produces the issue, I can test that one as well.

[jplock]

That was it! Is there a way to get the signing profile version ARN via CloudFormation? My template looks like this:

SigningProfile:
  Type: "AWS::Signer::SigningProfile"
  Properties:
    PlatformId: AWSLambda-SHA384-ECDSA
    SignatureValidityPeriod:
      Type: MONTHS
      Value: 135

CodeSigningConfig:
  Type: "AWS::Lambda::CodeSigningConfig"
  Properties:
    Description: "Code Signing"
    AllowedPublishers:
      SigningProfileVersionArns:
        - !Ref SigningProfile  <-- this just returns the signing profile ARN without the version
    CodeSigningPolicies:
      UntrustedArtifactOnDeployment: Enforce

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-signer-signingprofile.html doesn't mention any other return values.

[mndeveci]

Glad that it worked, I pinged Lambda team that they will mention this in their documentation. And for your last question, you can use !GetAtt SigningProfile.ProfileVersionArn to get the profileVersionArn from signing profile. This last one is not mentioned in the docs, they will update that as well.

Here is the template;

  SigningProfile:
    Type: "AWS::Signer::SigningProfile"
    Properties:
      PlatformId: AWSLambda-SHA384-ECDSA

  CodeSigningConfig:
    Type: "AWS::Lambda::CodeSigningConfig"
    Properties:
      Description: "Code Signing"
      AllowedPublishers:
        SigningProfileVersionArns:
          - !GetAtt SigningProfile.ProfileVersionArn
      CodeSigningPolicies:
        UntrustedArtifactOnDeployment: Enforce

Please let me know if you need more information by reopening this ticket.

[jplock]

Thank you for the help!

[Manouchehri]

Hmm, is there a reason why forgetting to use ProfileVersionArn sometimes appears to work initially, but fails later?

Took me awhile to figure out my mistake.