Protego is the provider of a comprehensive security solution for cloud native and serverless applications, providing enhanced security posture, realtime security observability and cloud native application defense. One key technology in the Protego arsenal is the Protego Function Self Protection module (FSP). The FSP is a transparent, lightweight module that is inserted into functions to provide inline monitoring and defense, in concert with Protego’s learning backend.
Typically, the insertion of the FSP is done using a CI/CD plugin which is responsible for automatically inserting the FSP into each serverless function or container as it’s deployed. This can create all sorts of complexities in the deployment. The insertion involves some automated code changes to rewire the function handler or entry point. Also, since functions are deployed with the FSP wired in, it can be challenging to enable or disable this feature without redeploying the functions.
The new Layers and Runtimes feature AWS has just rolled out enables a much cleaner deployment model for security modules and overlays such as the FSP. Rather than modify the function deployment package, Protego can augment the function with additional security or monitoring by including that security in a separate layer that can be deployed with the function. This makes the insertion process less tricky, enables runtime enabling or disabling of the layer, and centralizes the security module in a single location for updates.
Layers and RuntimesAWS has introduced two new features for Lambda, which have the potential to significantly shift the way that Lambda functions are written, deployed and operated. Lambda Layers is the ability to decompose Lambda functions into one or more runtime layers that are merged together when the function is invoked. This can help make software organization cleaner, by allowing you to decouple various parts of your software stack. It also opens up the possibility of sourcing layers from third parties, which can free you up from dealing with developing and patching these components.
Additionally, the Lambda Runtime API lets you bring your own runtime to a function. In reality this means that instead of loading all your software (function code and any included layers) into a container that contains AWS’s python or node, and its boilerplate handler code, your software stack (typically the lowest layer in the stack) is actually a replacement for the stock runtime. This is a tradeoff. On the one hand, you’ve taken a “step back” in shared responsibility, since you now have to deploy and patch the runtime environment. On the other hand, this
enables you to do lots of cool things, like support languages not currently supported by Lambda, or introducing instrumented runtimes for performance measurement, debugging, or security. And since you can source layers from third parties, you could shift responsibility for this from AWS to a third party, instead of handling it yourself.
Using Layers for Security
Our first foray into layers was to leverage layers for FSP insertion. As mentioned above, while insertion via CI/CD automation works pretty well for customers, it would be cleaner and more testable if the FSP lived in its own layer. To that end, we moved all of our FSP code (it’s pretty small anyway) into a separate layer. Using the new APIs, we enabled deploying a function with the additional layer, thus leaving the original code package untouched.
This new layer lives is a separate package, which we can update when we need to, ensuring that when a function is deployed, it has the latest FSP with it. If a customer has a need to shut off the FSP entirely to test something out of the ordinary, a call to the API or CLI will make the change without modifying the deployed code.
Customizing the RuntimeThis approach made this somewhat cleaner, but didn’t remove the issue entirely. That’s because it isn’t enough to crop our files into the package. We need a way to make sure the FSP is loaded before the function code is, and can put security in place as needed. Our goal with Layers has always been to make security insertion as transparent and frictionless as possible, and we’re not quite there yet with layers alone.
This is where the Runtime API comes into play. By deploying a customized Python Runtime that includes bootstrap code to first load the FSP and then call the actual handler, we can completely remove and code changes in the original function, and FSP insertion is truly frictionless. What’s Next?
We’ve rolled out Layers and Runtime API support for FSP insertion on Python, and we’ll roll out support for node.js, C# and Java soon.
We’ve already added support to Protego Proact , which does posture scanning for serverless applications, to ensure it can properly scan functions that include Layers in their deployment package, and we’ll continue to enhance this as the Layers feature evolves.
Ultimately, security doesn’t belong in a special runtime, but rather in an overlay layer that adds any security functionality. The same could be said for monitoring. Custom Runtimes should primarily be reserved for adding language support. We’re working closely with the Lambda team to enable deployment of security in a standalone layer without a custom Runtime, and this is how we plan to work in the future.
Finally, security monitoring insertion is just the start of how this new deployment model can be used. Protego is already researching additional ways that Layers and the Runtime API can be used for more advanced cloud native security.
Get Started
The Protego SaaS solution is the first comprehensive application security platform built with the unique constraints and opportunities of serverless in mind. Get started now with our free starter plan get a handle on your growing serverless environment in less than 20 min. The LAB version is free and complete with all of Protego’s serverless security functionality.
The post Layers and Runtimes @ Protego appeared first on Protego .
