Hybrid Security - From On-Prem to Serverless

BY Leon Stigter
Feb 24 2020
5 Min

DevOps, as a practice to build and deliver software, has been around for over a decade. What about adding security to that, though? After all, security is one of the cornerstones of today’s information technology. As it turns out, one of the first mentions of adding security was a Gartner blog post in 2012. Neil MacDonald wrote, “DevOps must evolve to a new vision of DevOpsSec that balances the need for speed and agility of enterprise IT capabilities (…)”.

In Risk Based Security’s year-end report for 2019, it mentions more than 22 thousand new vulnerabilities have been disclosed. More than a third of those have exploits available or code that proves how it can be misused. In the same report, JFrog’s Paul Garden mentions that if you’re not currently using hybrid infrastructure you soon will as more and more workloads are moved to the cloud. But if your security software is so out of date that last virus it found was the one that killed off the dinosaurs or so old that it originally came with a coupon for floppy discs, that is a big challenge (jokes courtesy of TrendMicro).

With that in mind, figuring out the need for a more cloud-native security solution is easy. Figuring out which one to pick isn’t. The CloudJourney team built the ACME Fitness Shop to show how complex apps run on Kubernetes. Over the past months, we’ve also worked to build a serverless version. There is no difference in the APIs between the Kubernetes and serverless versions, so they should be able to work together. Combining those two, vastly different, technologies into a single technology stack and keeping it safe is tough.

Keeping Kubernetes safe

Aqua’s Risk Explorer view shows all the namespaces and deployments for clusters that have the Aqua enforcer running. That way, you can get a complete overview of your cluster from the ground up. The view shows all your infrastructure, all the namespaces that have apps running, and the containers that are part of those apps. In a Kubernetes environment it’s hard to get a complete overview of everything that goes on, so this view definitely helps get a perspective on things from a security point-of-view.

screenshot1.png

When you click on one of the deployments, you get an overview of the risks and infrastructure associated with it. For example, the Payment service of the ACME Fitness Shop has 4 known high vulnerabilities and currently has one running instance.

screenshot2.png

To keep containers safe, even when there is no immediate resolution to the vulnerability, Aqua built vShield. That vShield technology is like a virtual patch that makes sure no one can exploit the vulnerability without requiring the dev teams to change their code. With a single press of a button, the cURL vulnerability can no longer be misused when attackers would be able to compromise your system.

screenshot3.png

Keeping your Kubernetes environment safe starts with knowing where your containers and images come from. For example, you want to make sure that all the containers you deploy come from a registry you trust. Relying on Docker Hub all the time to pull images to your Kubernetes cluster is a recipe for disaster. Adopting a private registry, like Harbor, is a much safer choice. Aqua comes with out of the box with connectivity to Harbor, so it can help your container registry safe and tell you when things are not as they should be.

screenshot4.png

Making sure that images are scanned by Aqua is important. Equally important is to make sure that you trust the base images of the containers you deploy into your cluster. Personally, I value the amount of effort the Bitnami team takes in making sure the images they provide are safe and secure. My base images of choice are usually bitnami/minideb or bitnami/node. Within Aqua, you can create an Image Assurance Policy where you can list all the base images that you trust. Deployments that do not comply with that policy are flagged and can be acted upon.

screenshot5.png

One of my personal favorite features is the ability to send all notifications through a webhook to Slack. With a ton of activity going on in Slack anyway, it definitely helps when notifications are sent there so everyone in the team can see that the container you just wanted to deploy is not allowed.

screenshot6.png

One of my other favorite features is the RESTful API that Aqua offers. With the API, developers have access to all the functionality that the Web UI has (which does require authentication 😉). That means those devs can build workflows to automate and run actions from within Slack (or any other messaging platform you might like). Going one step further, using the webhook and API together, I could build a serverless app that reacts on new vulnerabilities being detected by running a new image scan, or checking which risks haven’t been acknowledged yet and letting the team on Slack know.

Keeping functions safe

Some of the workload for the ACME Fitness Shop runs on AWS Lambda. While there are definitely aspects of security that are the same across Kubernetes and serverless, there are differences too.

screenshot7.png

One of the hot topics when it comes to building and running serverless applications is the principle of least privilege. That means as much that every component of your serverless app should only have access to the information and resources it needs for its function.

screenshot8.png

In this case, my function is absolutely safe but it does have access to permissions that might not be needed. Knowing what functions have excessive and unused permissions, and being able to act upon them is crucial to make sure that your serverless workload is safe too.

Want to try it too?

Both Harbor and Aqua can run as standalone Docker containers, or as part of your Kubernetes cluster. You can get the Helm charts from, for example, the VMware Cloud Marketplace.Those Helm charts give you a less complex way to get started with both products. If you’re also looking for a way to run everything on your own machine, I can absolutely recommend either Minikube or KinD (Kubernetes in Docker) as great single cluster Kubernetes installations.

What’s next?

Keeping our apps, wherever they might be deployed, safe is a shared responsibility. As we’re all working on better security, let me know your thoughts and send me or the team a note on Twitter.

Cover image by Thomas Jensen on Unsplash.