aws_lambda: Python 3.11 is added to aws_lambda module with aws-cdk-lib 2.88.0, but it is not supported yet, causing cdk-nag error

[afurkanoruc]

Describe the bug

Python 3.11 is added as a runtime to the aws_lambda module with aws-cdk-lib 2.88.0. But AWS Lambda does not support Python 3.11 yet. We are using Python 3.10 for our AWS Lambda functions and running cdk-nag on them. Cdk-nag gives the following error message, because it thinks there is a newer version available:
AwsSolutions-L1: The non-container Lambda function is not configured to use the latest runtime version. Use the latest available runtime for the targeted language to avoid technical debt. Runtimes specific to a language or framework version are deprecated when the version reaches end of life. This rule only applies to non-container Lambda functions.

Expected Behavior

Python 3.11 should be removed from AWS Lambda runtimes as it is not supported.

Current Behavior

It is possible to assign Python 3.11 runtime to AWS Lambda function, but it is not released yet. cdk-nag is generating error and prevents deployment.

Reproduction Steps

• Install aws-cdk-lib 2.88.0 and cdk-nag 2.27.75.
• Run cdk synth.

Possible Solution

Python 3.11 should be removed from AWS Lambda runtimes as it is not supported.

Additional Information/Context

No response

CDK CLI Version

2.82.0

Framework Version

No response

Node.js Version

v18.10.0

OS

Windows

Language

Python

Language Version

Python 3.10

Other information

No response

[cgarvis]

We published the python 3.11 runtime enum early so CDK customers can use it "day 1" when it gets released. First time trying this so we will need to figure out how to allow "day 1" usage and not have cdk-nag error out.

[afurkanoruc]

We published the python 3.11 runtime enum early so CDK customers can use it "day 1" when it gets released. First time trying this so we will need to figure out how to allow "day 1" usage and not have cdk-nag error out.

I understand, but customers still going to need to update their constructs with Python 3.11 when it is finally released. What's the point of releasing the enum early, which cannot be used? It is only confusing in my opinion.

[ran-isenberg]

+1 for fixing this, i had to add the exclude for cdk-nag.

[mwebber]

Python 3.11 for Lambda was released on 27/July/2023:
https://aws.amazon.com/blogs/compute/python-3-11-runtime-now-available-in-aws-lambda/
So the immediate problem raised by this issue is solved.
I guess the question remains for future CDK releases - how far id advance (if at all) should "upcoming" enums be added to the CDK code base?

[coryvisi]

As of aws-cdk-libs 2.107, we have the same issue with Python 3.12.

Would it be possible to expose a list structure of recommended runtimes for each family? Deprecated runtimes could be moved out of the list, and new runtimes could be added to the list as they become GA.

For discussion would be the using this information in cdk-nag to raise security concerns: is it better to use the list of exposed runtime versions in the environment version of aws-cdk-libs, or should cdk-nag somehow always use the latest available from AWS Lambda (assuming there is a way to know that)?

[davideagle]

Is there a known workaround for this issue?

[davideagle]

workaround found by suppressing AwsSolutions-L1 checks for the project

service_stack.py

{
         'id': 'AwsSolutions-L1',
         'reason': 'Suppress error caused by python_3_12 release in December'
},

[behrens-cloud]

I see from the CDK API docs that there is a way to get the latest "static NODEJS_LATEST" version. It would be perhaps really nice to have a way to also get the latest for any language, or perhaps the latest major version. I would also think that it should be a warning instead of an error, unless the version requested has a critical finding against it.

[mrgrain]

I see from the CDK API docs that there is a way to get the latest "static NODEJS_LATEST" version. It would be perhaps really nice to have a way to also get the latest for any language, or perhaps the latest major version. I would also think that it should be a warning instead of an error, unless the version requested has a critical finding against it.

NODEJS_LATEST isn't the version you think it is. It's the latest version that is support in all regions, including some regions you do not use or care about (govt cloud, CN, etc)

[mrgrain]

Would it be possible to expose a list structure of recommended runtimes for each family? Deprecated runtimes could be moved out of the list, and new runtimes could be added to the list as they become GA.

We aim to add new Runtimes as soon as they are available in at least one region, even if they have not been publicly announced. This might mean a new runtime is added that does not exist in the region you use or care about.

For discussion would be the using this information in cdk-nag to raise security concerns: is it better to use the list of exposed runtime versions in the environment version of aws-cdk-libs, or should cdk-nag somehow always use the latest available from AWS Lambda (assuming there is a way to know that)?

aws-cdk-lib is not going to include GA information. We are however exploring at the moment making deprecation information available at runtime.

[coryvisi]

Exposing deprecation information would be helpful. I think that could be used for the cdk-nag check (in other words, if the version in the stack is less than the last supported version, or part of the deprecation list, the security check fails). I think this makes more sense than requiring stack authors to be on the very latest Python version to comply with security checks.

If there is an open issue or request for that feature, please link it here so we can support it.

[mrgrain]

If there is an open issue or request for that feature, please link it here so we can support it.

It was part of #27999 but I think this now got closed in favor of a different implementation. FWIW, this information is already available via the jsii assembly. Just not at runtime. There's nothing stopping cdk-nag from using this approach today. I've asked if that is something they would consider, since the rules are obviously quite different.