rights reserved. Agenda • Tools and services to create secure architectures • What happens when you run a Lambda invocation • How to leverage serverless computing for security processes • Some practical tips for serverless security • Q&A
rights reserved. Lambda functions API Gateway Core business logic RESTful microservices DynamoDB https://api.myapp.com AWS Cloud Mobile app Pure serverless can be straightforward
rights reserved. 1-n Lambda function sets 1-n API Gateways Microservices environment . . . . . . Various clients, potentially including other microservices Various data tier components, as needed AWS Cloud DynamoDB Mobile client Amazon ElastiCache Amazon S3 Serverless architectural patterns are easily scalable
rights reserved. Lambda functions Amazon S3 API Gateway Dynamic website content Web application Amazon CloudFront distribution Static website content (HTML/JS/CSS) DynamoDB Amazon RDS ElastiCache Amazon S3 https://api.example.com www.example.com VPC AWS Cloud Web browser Some infrastructure is still there
rights reserved. Lambda functions Amazon Cognito API Gateway AWS Security Token Service (AWS STS) Core business logic Mobile backend User identity management DynamoDB Amazon RDS ElastiCache Amazon S3 https://api.myapp.com AWS Cloud VPC Mobile app Core business logic elements can be code or containers Amazon ECS
rights reserved. Common security approach • Serverless and containers share a common pattern: microservices • Core business logic can be modeled as code or containers • We can reuse the same thought model for both serverless and containers to design secure architectures
rights reserved. Security principles: Least privilege “Granting only those privileges which are essential to perform the intended function” { "Effect": "Allow", "Action": "dynamodb:*", "Resource": "*" } { "Effect": "Allow", "Action": "dynamodb:PutItem", "Resource": ”arn:…/ContactsTable" }
rights reserved. Security principles: Defense in depth (layers) “Using multiple, redundant measures at every system in case a security control fails” AWS Cloud AWS Lambda User traffic Amazon S3 Amazon API Gateway Amazon DynamoDB Amazon RDS Amazon CloudFront
rights reserved. Security principles: Clean code No secrets in code • IAM keys • à Use STS AssumeRole • Database usernames/passwords • à Use AWS Secrets Manager/encrypted env. variables Keep it simple • Lambda functions should be small • Group them based on type of access
rights reserved. Amazon API Gateway queue orders table customers table POST GET DELETE Amazon API Gateway queue orders table customers table monolithic function ANY /{proxy+} Monolithic ü Single responsibility Security principles: Clean code
rights reserved. Lambda execution environments • Upon invocation, Lambda data plane creates execution environment (or chooses an existing one) in a microVM including: • The function code • Any Lambda layers selected for your function • The function runtime, either built-in (Java 8, NodeJS 8, Python 3.7, etc.) or custom runtime • A minimal Linux userland based on Amazon Linux • Execution environments are never shared across functions, and microVMs are never shared across AWS accounts
rights reserved. Host KVM MicroVM (Guest OS & Container Workload) Firecracker RESTful API Networks Storage Rate Limiting Metadata Service • Firecracker microVMs have the same security as KVM VMs • Designed for low overhead, high density, and fast start times • Built-in fair sharing Firecracker Architecture and Benefits Source; https://github.com/firecracker-microvm/firecracker
rights reserved. Lambda design considerations • First invocation of a Lambda function requires “bootstrapping”, which adds some latency. • Execution environments can be reused by subsequent invocations, with no memory scrub. • Execution environments includes a writeable file system, available at /tmp. that remains for the lifetime of the execution environment. • Lambda provides patching and updates for supported runtimes. Maintenance of custom runtimes is customer responsibility.
rights reserved. Lambda best practices • Plan for cold start to optimize microVM reuse • Minimize package size to necessities • ENIs for VPC support are attached during cold start • Instantiate AWS clients and database clients outside the scope of the Lambda handler • Avoid code to read or write to /tmp if not needed • Leverage AWS-supported runtimes to avoid heavy lifting of custom runtimes import sys import logging import rds_config import pymysql rds_host = "rds-instance" db_name = rds_config.db_name try: conn = pymysql.connect( except: logger.error("ERROR: def handler(event, context): with conn.cursor() as cur: Executes with each invocation Executes during cold start
rights reserved. CodeDeploy and Lambda canary deployments • Direct a portion of traffic to a new version • Monitor stability with CloudWatch • Initiate rollback if needed • Incorporate into your AWS SAM templates
rights reserved. Create dedicated, locked down accounts per project Use AWS Organizations Use the third party org-formation solution https://github.com/OlafConijn/AwsO rganizationFormation
rights reserved. Security and compliance Rules engine in Lambda consumes logs and checks for breaches AWS Lambda Rules engine function CloudWatch Logs CloudTrail Logs Account A CloudWatch Logs CloudTrail Logs Account B Ingestion Kinesis Firehose raw storage Raw archive Alarm Compliance team AWS account
marekq
nobutomurata
tubone24
iotengineer22
oracle4engineer
cmusudakeisuke
nikinusu
amixedcolor
kazzpapa3
kaminashi
kniino
sansantech
ysknsid25
tammyeverts
bkeepers
reverentgeek
hatefulcrawdad
jnunemaker
carmenintech
addyosmani
garrettdimon
62gerente
keithpitt
palkan
zakiyama
