Search for a command to run...
Miguel is a Principal Engineer and the author of the “Serverless Security” book. He has worked on multiple serverless projects as a developer and security engineer, contributed to open-source serverless projects, and worked on large military systems in various engineering roles.
No comments yet. Be the first to comment.
We will discuss aspects serverless security, and describe what you can do to start securing your serverless application. Visit <https://ServerlessSecurityBook.com> to level up and get the book.
The Serverless Framework support numerous plugins—and they are great! They save so much time in deploying our serverless applications. Why reinvent the wheel? This convenience comes with a downside: not all plugins are written securely. We must choos...
Protect your system from vulnerabilities
How I saved my company $1 million
This YouTube video series provides quick overviews of the top 10 cybersecurity risks for serverless applications. Each video covers the risk and some recommendations on how to address it. Why is the OWASP Serverless Top 10 important? In this video, I...
![Overview of the OWASP Serverless Top 10 [videos]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1636408504092%2FBcNttK9q2.png&w=3840&q=75)
A little over one year ago, I published my first book thanks to Apress and author Nihad Hassan. I am in a cybersecurity writing group with Nihad, where he shared he had published his 4th book; this was back in 2019. I was impressed by his accomplishm...
You may have heard, “If you build it, they will come.” Have you heard, “If you build it, I will break it?” This is a skill I developed over my career to build better systems. It is a skill that took me a while to learn I had. Shortly before I graduat...
Miguel's Blog · Serverless · Security
49 posts
Miguel A. Calles is the author of the Serverless Security book, and a Cybersecurity engineer who works on serverless and cloud computing projects.
"Did I just delete the database with all my customer data?!" you might say if you failed to enable the measure to prevent accidental deletion. We will explore how to avoid this pitfall in your Serverless environment.
The Serverless framework has made it extremely easy to deploy you functions, create databases, provision storage, and more with one deploy command. This is powerful and convenient, but the same goes for tearing down your deployment. (You may want to read the first article in this series, "Introduction To Serverless Security: Part 1 - Dependencies," to get a quick overview on serverless environments.)
This example deployment file shows how you can configure the resources you want in one configuration.
service: secjuice-example
provider:
name: aws
runtime: nodejs8.10
stage: ${opt:stage, 'dev'}
region: us-east-1
functions:
exampleFunction:
handler: functions/example.handler
events:
- http:
path: secjuice/example
method: get
resources:
Resources:
S3BucketFiles:
Type: AWS::S3::Bucket
Properties:
# must be globally unique across all AWS
BucketName: secjuice-example-files
CustomersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: secjuice-example-customers
AttributeDefinitions:
- AttributeName: AccountId
AttributeType: S
KeySchema:
- AttributeName: AccountId
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
The serverless.yml configuration file.
The serverless.yml configuration creates the following upon deployment to Amazon Web Services (AWS):
secjuice-example-dev-exampleFunction using AWS Lambdas; it automatically appends the "service" and "stage" to the lambda function name
A Serverless deploy created the Lambda function.
secjuice-example-files using AWS Simple Storage Service (S3)
A Serverless deploy created the S3 buckets.
secjuice-example-customers using AWS DynamoDB.
A Serverless deploy created the DynamoDB table.
To start the deploy, you navigate to the project folder where the serverless.yml file exists and run the following command:
sls deploy
Command to deploy the stack.
Wow! Deploying the stack is really simple.
As simple as it was to deploy, the same applies to removing your environment. This is a double-edge sword. You may want to remove your environment quickly when developing for multiple reasons, but you might not want that same ease with your production environment (and important data).
To start the removal, you navigate to the project folder where the serverless.yml file exists and run the following command:
sls remove
Command to remove the stack.
It is scary how easy it was to delete the entire stack.
Issuing this command deleted the following:
A Serverless remove deleted the DynamoDB table.
A Serverless remove deleted the S3 buckets.
A Serverless remove deleted the Lambda function.
How can you protect your data from an accidental (or maliciously intended) deletion?
You can separate your functions and data into two stacks. I did accomplished this by creating two sub-folders "data" and "functions", each with its own serverless.yml configuration file.
service: secjuice-example-functions
provider:
name: aws
runtime: nodejs8.10
stage: ${opt:stage, 'dev'}
region: us-east-1
functions:
exampleFunction:
handler: example.handler
events:
- http:
path: secjuice/example
method: get
The functions/serverless.yml configuration file.
service: secjuice-example-data
provider:
name: aws
runtime: nodejs8.10
stage: ${opt:stage, 'dev'}
region: us-east-1
resources:
Resources:
S3BucketFiles:
Type: AWS::S3::Bucket
Properties:
# must be globally unique across all AWS
BucketName: secjuice-example-files
CustomersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: secjuice-example-customers
AttributeDefinitions:
- AttributeName: AccountId
AttributeType: S
KeySchema:
- AttributeName: AccountId
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
The data/serverless.yml configuration file.
To start the deploy, you navigate to the project folder where the original serverless.yml file existed and run the following commands:
cd functions
sls deploy
cd ../data
sls deploy
cd ..
Commands to deploy both stacks.
These two deploys did the following:
Each Serverless deploy created a stack.
The Serverless deploy for the functions stack created the Lambda function.
The Serverless deploy for the data stack created the DynamoDB table.
Each Serverless deploy created its S3 buckets.
Now, let's remove on the functions stack.
cd functions
sls remove
cd ..
Commands to remove the functions stack.
You will notice only the Lambda function and the S3 bucket associated with the functions stack is removed:
The Serverless remove for the functions stack removed its CloudFormation stack.
The Serverless remove for the functions stack removed its S3 bucket.
The Serverless remove for the functions stack had no effect on the DynamoDB table.
The Serverless remove for the functions stack removed the Lambda function.
This approach allows a developer to work on the Lambda functions without worrying about the effect it has to the data.
AWS CloudFormation has a nice feature to protect against accidental termination: it is called "termination protection." Termination protection is disabled by default. To enable it:
Navigating to the "Edit termination protection" option.
Enabling termination protection.
Now, when you try to remove the data stack you will get the following error:
Serverless: Getting all objects in S3 bucket...
Serverless: Removing objects in S3 bucket...
Serverless: Removing Stack...
Serverless Error ---------------------------------------
Stack [secjuice-example-data-dev] cannot be deleted while TerminationProtection is enabled
Error displayed when attempting to remove a stack with termination protection enabled.
Enabling termination protection via the web console is very simple, but can be time consuming if you have a lot of stacks to manage. I recommend enabling it as part of the Serverless deploy.
At the time of this writing, the Serverless framework version 1.x has no support for termination protection. You need to use a Serverless plugin to add that capability. You can use one of two plugins:
The "serverless-stack-termination-protection" plugin
This plugin enables termination protection during deploy without any additional configuration.
To install it, run the following commands in your project folder:
cd data
npm install --save-dev serverless-stack-termination-protection
Commands to install the plugin.
Open the serverless.yml configuration file for the data stack and add the plugin.
service: secjuice-example-data
provider:
name: aws
runtime: nodejs8.10
stage: ${opt:stage, 'dev'}
region: us-east-1
resources:
Resources:
S3BucketFiles:
Type: AWS::S3::Bucket
Properties:
# must be globally unique across all AWS
BucketName: secjuice-example-files
CustomersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: secjuice-example-customers
AttributeDefinitions:
- AttributeName: AccountId
AttributeType: S
KeySchema:
- AttributeName: AccountId
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
plugins:
- serverless-stack-termination-protection
The updated data/serverless.yml configuration file.
You will see the following output when you deploy the data stack:
serverless-stack-termination-protection: Successfully enabled termination protection
Output displayed when deploying the data stack.
Disclosure: I wrote the "serverless-stack-termination-protection" plugin.
The "serverless-termination-protection" plugin
This plugin also enables termination protection during deploy, but offers additional configuration options to deploy to specific stages. For example, you can specify to enable termination protection only for your "prod" stage/environment.
To install it, run the following commands in your project folder:
cd data
npm install --save-dev serverless-termination-protection aws-sdk
Commands to install the plugin.
Open the serverless.yml configuration file for the data stack and add the plugin.
service: secjuice-example-data
provider:
name: aws
runtime: nodejs8.10
stage: ${opt:stage, 'dev'}
region: us-east-1
resources:
Resources:
S3BucketFiles:
Type: AWS::S3::Bucket
Properties:
# must be globally unique across all AWS
BucketName: secjuice-example-files
CustomersTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: secjuice-example-customers
AttributeDefinitions:
- AttributeName: AccountId
AttributeType: S
KeySchema:
- AttributeName: AccountId
KeyType: HASH
ProvisionedThroughput:
ReadCapacityUnits: 1
WriteCapacityUnits: 1
plugins:
- serverless-termination-protection
custom:
serverlessTerminationProtection:
stages:
- prod
The updated data/serverless.yml configuration file.
You will see the following output when you deploy the data stack:
Serverless: STP: Adding termination protection to secjuice-example-data-dev..
Serverless: STP: Checking if termination protection should be added..
Serverless: STP: Stages to check: prod
Serverless: STP: Not applying termination protection for dev stage
Output displayed when deploying the data stack.
With either plugin, your data stack is now protected, unless you specify to exclude a stage.
Consider separating your stacks and enabling termination protection on the data stack at a minimum to protect your application from accidental deletion.
The source files are available at https://github.com/miguel-a-calles-mba/secjuice/tree/master/termination-protection-examples for your enjoyment.
Originally published on Secjuice.com
Photo by Blaine Lingard on Dribbble