Lambda Layers of Defense¶
DRAFT: Methods, Ideas, Practices to improve your Lambda's security / reliability
You are responsible for maintaining control over your content that is hosted on this infrastructure.
Event Sources¶
You can protect your lambda handles at the event source level, and avoid lambda invokation where possible.
Synch flow (API GW, AppSync)¶
-
Event source can authorize requests
-
Event source can only be available within a VPC
-
Event source can limit by sourceIp or VPC
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:region:account-id:*"
},
{
"Effect": "Deny",
"Principal": "*",
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:region:account-id:*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "123.4.5.6/24"
}
}
}
]
}
-
Event source can be linked to a waf (AWS Shield, AWS WAF) or cdn (CloudFront)
-
Event source can add usage limits and throttling per api client per endpoint
-
Event source can include request validation
flowchart LR
Client <--> id1(Event Source) <--> id2(Lambda Service) <--> id3(Lambda Function) <--> id4(Down Stream)
Asynch flow (S3, EventBridge)¶
- Event source can do batching
- Event source can have filtering
flowchart LR
Client --> id1(Event Source) --> id5(Requests) <--> id2(Lambda Service) <--> id3(Lambda Function) <--> id4(Down Stream)
Asynch flow (Dynamodb)¶
- Updates can be filtered
- Updates can be sent to EventBridge to further filtering
flowchart LR
Client --> id1(Event Source) --> id5(Changes) <--> id2(Lambda Service) <--> id3(Lambda Function) <--> id4(Down Stream)
Ideas to be documented¶
-
Encryption in transit
- Lambda API endpoints only support secure connections over HTTPS.Encryption at rest
- On a per-function basis, you can configure Lambda to use a customer managed key to encrypt your environment variables. Conterary to the AWS docs, i would not recommended using environments variables for secrets, but rather secret manager (or parameter store). Lambda always encrypts files that you upload to Lambda, including deployment packages and layer archives. Amazon CloudWatch Logs and AWS X-Ray also encrypt data by default.
-
"Identity and access management for Lambda" - least priviledge
- Identity and access management for Lambda
- IAM condition key, lambda:SourceFunctionArn - "This capability allows you to implement advanced security controls for the AWS API calls taken by your Lambda function code. For example, you can write conditional policies using the new lambda:SourceFunctionArn together with existing condition keys such as aws:SourceIP or aws:SourceVPC to grant permissions to AWS API calls only if those originate from inside the customer’s VPC."
- Working with Lambda execution environment credentials
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ExampleSourceFunctionArn",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::lambda_bucket/*",
"Condition": {
"ArnEquals": {
"lambda:SourceFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:source_lambda"
}
}
}
]
}
-
"Compliance validation for AWS Lambda"
- SOC1, SOC2, SOC3, PCI, FedRAMP, HIPAA, ISMAP etc..
- AWS Services in Scope by Compliance Program
- AWS Artifact
-
- High availability - AWS Lambda is always multi-az within a region
- Retries - Async execution have built in retries (Ensure lambdas has idempotency support)
- Dead-letter queue or distinations allow for failed async executions to be recovered
-
"Managed runtimes"
- AWS will patch a managed runtime like python3.9 or nodejs16.x
-
"Limiting concurrency" / "Throttling"
-
"Authentication"
- JWT, Cognito, OIDC, IAM should be in place where applicable.
- All calls should be authorized (using x-api-key can allow for public apis to have throttling and other controls)
-
"Input / Output validation"
-
"VPC"
-
"Observability" (Logging, Metrics, Tracing)
-
"Event sourcing" - Locking down the event source
- Limit what can call your lambda function example below for API GW
{
"Version": "2012-10-17",
"Id": "default",
"Statement": [
{
"Sid": "nodejs-apig-functiongetEndpointPermissionProd-BWDBXMPLXE2F",
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-2:111122223333:function:nodejs-apig-function-1G3MXMPLXVXYI",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "111122223333"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:execute-api:us-east-2:111122223333:ktyvxmpls1/prodStage/GET/image"
}
}
}
]
}
-
Patching library dependencies
-
Static code analysis (code complexity, code style, code quality, security, etc ...)
-
Lambda versioning and aliases
-
Idempotency (best practices)
-
Code Signing
-
Secrets management
- No hard coding of secrets and use SST where possible
- Monitor AWS Secrets Manager secrets
- Deploy Serverless Applications with AWS Lambda and API Gateway
-
Limit function to single use case, keep code simple and small
-
Validate input / output via Jmepath / Pydantic
- Using framework code like Pydantic or JMESchema