TL;DR on the AWS Lambda Security Overview

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

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
  • Communications 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

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abhay Bhargav

Abhay Bhargav

CTO of we45 (An AppSec Company), DevSecOps Greasemonkey, Passionate Security Technologist and Creator