Feature request: Support for signed Lambda functions

[heitorlessa]

Use case

Originally stated by @jplock

When using code signing feature, any Lambda Layer must be also signed. This means customers using this feature can't use our public Lambda Layers, as it's not currently signed.

What's not clear yet is whether a signed Lambda Layer can be used by a non-signed Lambda function.

Solution/User Experience

Lambda Powertools for Python maintainers to create a Code Signing Profile, sign Lambda Layers, and share its ARN within the documentation.

Alternative solutions

Build my own Layer or use PyPi

Acknowledgment

• This feature request meets Lambda Powertools Tenets
• Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[am29d]

Just checked few configurations for (non- )signed layer/functions. The good news is that you can add a signed layer to a non-signed lambda function. But supporting signed layers will require to also publish the signing profiles ARNs and add documentation steps so customers can modify their lambda code signing configurations, and redeploy the functions.

Another topic to discuss is "Signature validity period" settings for the signer. The maximum period is 11 years. Whatever period we choose, the public layer can't be used if the code signer is configured with the "enforce" policy.

Overall I think this is a feature we should adopt in the future and sign all the layers to add extra security. Once we have the new layer publishing pipeline in place I will look into this feature request and see how we can reduce the overhead to support it.

[leandrodamascena]

Hey everyone!
This week I did some research on how to sign Powertools layers with AWS Signer and I have some news. Sorry if I'm repeating some of the explanations @am29d already gave, but I'll explain the sequence of tests I did and the results to help us make a decision.

For ease of reading, here are some definitions:

• Signing Profiles - A signing profile is a code-signing template that can be used to predefine the signature specifications for a signing job.
• Code signing configurations - A code signing configuration defines a list of allowed Signing Profiles and the signature validation policy (Enforce or Warn). This is used by Lambda to validate the signatures of deployments.
  • Enforce - All deployments will be block if the signatures doesn't match.
  • Warn - Lambda allows the deployment of the code package, but issues a warning. Lambda issues a new Amazon CloudWatch metric and also stores the warning in the CloudTrail log.
  • More information about how Lambda performs the signature checks here.
• Lambda only checks the validity of a layer/function signature during the deployment process, which means that functions that aren't updated will continue to work no matter what happens to the Signing Profiles or Code signing configurations.

1 - Non-signed Lambda function + signed Powertools layer
This scenario is the most straightforward and does not encounter any issues.

2 - Signed Lambda function + non-signed Powertools layer
If the customer's Code signing configurations are set to Enforce mode, the customer will not be able to use the Powertools Layer as it is non-signed. If the Code signing configurations are set to Warn, the customer can use the non-signed Powertools, and a Cloudtrail event is created with the following information (among others):

"additionalEventData": {
           "layers": [
               {
                   "layerArn": "arn:aws:lambda:us-east-1:017000801446:layer:AWSLambdaPowertoolsPythonV2:31",
                   "signatureStatus": "MISMATCH"
               }
           ]
       },

3 - Signed Lambda function + Signed Powertools layer
In order for this to function properly, Powertools must update the documentation to inform the Signing Profile (Versioned profile ARN) that signed the layer, for each region where the layers were signed.
The crucial point to note here is that there are two fields for Signing Profile ARN: Profile ARN and Versioned Profile ARN. We must share the Versioned Profile ARN as it is utilized by the signing job.

4 - Signed Lambda function + Signed Powertools layer with Signing Profile canceled
If for some reason we need to cancel the Signing Profile that signed the layers, the Layers that were signed with this profile will still be valid (with a valid signature) and can be used until the expiration date of the signed file.

The validity period of a Signing Profile is transferred to the file on the date of its signature, for example:

Signing Profile Signature validity period - 1 month
A layer signed 01/05/2023 is valid until 01/06/2023
A layer signed 05/05/2023 is valid until 05/05/2023
And so on.

5 - Signed Lambda function + Signed Powertools layer with Signing Profile revoked
In the worst-case scenario, revoking a Signing Profile will result in all layers signed with that profile becoming non-functional after a certain date. For example, if the revocation start date is set to 01/01/2023, any layer signed after that date will stop working immediately.

---

Questions
In my point of view we still have some questions to address before implementing this:
1 - We need to define the validity period of a Signing Profile. It might make sense to look at the Lambda runtime deprecation policy to understand how long a runtime is deprecated and won't allow further deployments using that runtime. I say this because when a runtime is deprecated, a function can no longer be deployed and the customer will have to upgrade the function to a newer runtime and consequently with another layer, as there must be incompatibilities.
2 - In what scenarios might we need to revoke a Signing Profile?
3 - I think we'll need to create more extensive documentation on using layers and explain this signature process in detail.

Final considerations:

• AWS Signer is not yet supported in all regions.
• We must have a Signing Profile per region since the signing job doesn't support cross-region.
• I think that by implementing this functionality we will bring benefits to customers in the adoption of Powertools Layer, as we will be able to meet more requirements than we do today.

Thank you so much.

cc @dreamorosi @jplock

[jplock]

More regions added for signer? boto/botocore@65dc6b6

[leandrodamascena]

More regions added for signer? boto/botocore@65dc6b6

Hmm I don't think so! This looks like just a few endpoints for the FIPS standard.

[leandrodamascena]

Today I spoke with @sthulb about the 2 missing points for us to make the decision to implement or not. Below I leave more details of what was discussed.

• We will write a document to send to the AppSec team to review the flow of the signature process and potential strengths and weaknesses and give their approval/feedback.
• We agree that if we set an expiration date of 11 years for the Signing Profile, there seems to be no security issue or bad user experience.

As soon as I have any updates on this I will update again on this issue.

[leandrodamascena]

Adding the label "On Hold" because I still couldn't work on the documentation to describe the flow of these signing steps.

Planning to finish this by the end of June.