TL;DR on AWS Lambda Security Model

AWS recently released a whitepaper on the Security Overview of Lambda. This document is meant to be an in-depth look at Lambda Security. Its definitely a worthwhile read. However, I have tried to simplify and distill some of the most important security points for general consumption

A little bit of background on my work in Lambda. I work with AWS Lambda every day. I continue to build and release production-grade applications on Lambda and have deployed complex stacks in EdTech, Security Automation and Payment Processing, built entirely as an event-driven system on AWS Lambda. I really love AWS Lambda and the general "serverless" paradigm. It has been a game-changer for the way we build applications within we45. We've been able to be much more productive and faster to market because we've built our stack on AWS Lambda. Some of the obvious benefits of Lambda include:

• No managing servers
• Massive, Elastic Scalability as a Service
• Pay for what you use, down to the last millisecond

I will divide this blogpost into specific segments based on topics related to AWS Lambda security. Let's dive in!

Shared Responsibility and Lambda Layers

• Unlike IaaS services (EC2) and PaaS Services (Elastic Beanstalk) on AWS, the Shared Responsibility Model (your problem) for Lambda largely extends to your Code, third party libraries, configurations and IAM configs applied on Lambda. You don't need to manage the servers, consequently, the hardening, the hypervisor, the Runtime, the Sandbox, the hardware, etc.
• You use Layers to load custom third party libraries for your Lambda stack. The libraries and code within these layers are your problem. So is the IAM for the layers. However, access to layers is encrypted with TLS 1.2 (transit) and at-rest with AWS Key Management Service. Check out our interactive KMS Tour on Github

AWS Lambda Invoke Modes

• Two types of Invoke Modes: Event and Request-Response Invoke Modes
• Request-Response is a synchronous invoke with payload and returns response immediately. For example Lambda triggered from an API Gateway is Request-Response

Request => API Gateway => Invoke Service => Worker (VM) => MicroVM (for exec)

• Event Invoke Modes are queued with SQS. Retrieved in batches by poller fleet. Passes to the invoke service
• Control Plane == Management APIs ⇒ CreateFunction, UpdateFunctionCode and PublishLayerVersion
• Comms to Control plane are encrypted
• Data Plane ⇒ Runs the Lambda Function (Invoke) API
• Allocates a worker (EC2)

Lambda Execution Environment and Execution Role

• Customers cannot directly communicate with execution environment
• Execution Environments are bound to specific function versions ⇒ Cant be shared across versions, accounts, etc.
• Execution Environment ⇒ One concurrent invocation at a time. Multiple invokes of the same function version for performance
• No isolation of state between invokes ⇒ i.e. invoke state from a previous invoke is likely available to the next invoke. This has been the cause of some security gotchas
• Exec Role == IAM role that is assumed by the Lambda Function
• Credentials are mounted and cached in the ENV-Vars of the function

• Exec Role is assumed to perform Control-Plane Ops like configuring ENIs, Logs for Cloudwatch, AWS X-Ray

Micro-VMs, Workers and Lambda Isolation

• Fleet of EC2 Servers == Lambda Workers
• Runs on EC2 Nitro ⇒ Nitro Hypervisor, Nitro Security Chip, Nitro Cards and Enclaves
• Lambda team uses Inspector to stay on top of security issues with Ntro instances
• Workers have a max lease time of 8 hours
• Function code is zipped and encrypted with AES-GCM
• Functions created as containers is chunked and encrypted with a combination of AES-CTR, AES-GCM and SHA-256 MAC
• Exec Environment has a copy of: Your code + Layers + Runtime + writeable tmp directory + minimal user-space with Amazon Linux-2
• Isolation done with: cgroups, dedicated namespaces, seccomp-bpf, iptables, chroot
• /tmp is not accessible across exec environments. You'll need to persist with Elastic File System or S3, etc.

Monitoring

• Cloudwatch ⇒ Logs
• X-Ray ⇒ Traces
• AWS Config ⇒ Managing Config and compliance and security

Abhay is the Chief Research Officer of AppSecEngineer. One of the courses within AppSecEngineer is "Attacking AWS Serverless Applications". With our library and hands-on cloud labs and cyber-ranges consisting of amazing courses on DevSecOps, AppSec, Cloud Security and Threat Modeling, AppSecEngineer helps you become a better AppSec Professional. Subscribe today!