Security patches when using a custom runtime with AWS Lambda
We have a requirement to pin the version of the runtime (.NET) for our Lambda functions. I am aware of 3 approaches to achieve this:
- Setting the runtime update mode to Manual (not recommended)
- Providing a container image
- Providing a custom runtime (likely as a Lambda layer)
I understand #1 and #2 will not receive patches to the runtime version (of course), or to the underlying OS (please correct me if I'm wrong here).
My question is about #3 (custom runtime). Will the underlying OS receive patches in this case?
From my research on the Security Overview of AWS Lambda, there are a couple of representations that show AWS normally manages updates to the Execution Environment and Runtime Language.
Shared responsibility model (1):
.
Lambda MicroVMs and Workers (2):
If I provide a custom runtime, this would mean maintaining the Runtime Language component becomes the customer's responsibility. In this case, does AWS continue to provide patches to the execution environment?
- 最新
- 投票最多
- 评论最多
Good work on the research there - it clearly shows the delineation between the AWS and customer responsibilities.
If you are using a custom runtime then you are responsible for patches for that runtime. In the second diagram at the bottom-right you can see the Execution Environment - with a custom runtime the customer is responsible for maintaining all of that.
The AWS responsibility starts at the Lambda Sandbox which will include some level of "operating system" (definitions are going to be blurry at this level).
相关内容
AWS 官方已更新 1 年前
Thanks for answering! I'd like to try to clarify my understanding of the scope of the Execution Environment a bit further.
Focusing on the use case of deploying a Lambda function as a .zip archive and providing a custom runtime via a Lambda Layer, my understanding is that the custom runtime layer is simply a collection of files that includes the custom runtime and an executable
bootstrapfile. Is it accurate to think about the Lambda Sandbox as a container image that AWS is responsible for patching, and the custom runtime layer as a bind mount where we're just injecting files into the container at runtime?To put it another way, is there anything inside the Execution Environment other than function code, layer code, and the custom runtime that the customer would need to patch?
Your understanding is correct. Another way to put it is that anything that the customer provides is their responsibility to patch. Because the Lambda execution environment is being supplied by AWS it's the responsibility of AWS to patch.