By Yevgeny Pats, Head of Security
Cloud-native applications require a new security solution. Microservices magnify the attack surface, while communicating over APIs obscure visibility. Defense in depth argues for multiple layers of security control. To help spawn new ideas, this blog is the first in a series of conceptual defense in depth approaches to securing cloud-native applications.
Up until a few years ago, web application firewalls (WAFs) were deployed traditionally in front of a monolithic application. There has been an explosion of microservices and east-west traffic, and WAFs miss most of this traffic. To address this, we decided to take ModSecurity (which is the most used open-source WAF around the world) and integrate with Envoy (which is the most used proxy in cloud-native deployments) as an HTTP filter to give you the option to enable WAF on all the pods or on the most sensitive and front-facing traffic.
As a general rule, WAF requires a lot of maintenance and is very application specific in terms of the rules it runs on the traffic. Here we provide an example and basic guidelines with the free OWASP core rule set. You should configure it to match your application to avoid a lot of false-positive alerts.
The source code and the README for the ModSecurity-Envoy integration is available here. You can compile it yourself, use the release binary, or use the docker image.
How It Works
We compiled LibModSecurityV3 as an HTTP filter in Envoy and built a new Envoy release where you can turn on/off ModSecurity via configuration and configure ModSecurity via regular configuration files as specified in the ModSecurity tutorial. This way you can just swap your Envoy sidecar in your mesh with the new Envoy.
ModSecurity is one of the most used web-application firewalls and Envoy integration is a step forward with defense in depth. Adding signature-based intrusion detection to every microservice via a sidecar is a great example of how a service mesh enhances the security of a cloud-native environment and it gets you one step closer to a zero-trust network. It is important to note, you will get high CPU overhead along with a very high number of false positives and negatives without proper configuration. A central control plane which provides visibility, simple declarative APIs, and continuous automatic policy evaluation is essential to unlocking the value of this great feature.
WAF is an advanced use-case and arguably the last step in application security in the cloud-native era. The most fundamental need that emerged in the cloud-native era is visibility and security policies between your microservices. In layman terms, allow only authorized traffic. Then you don’t need WAFs or other signature based detection tools as there is almost no traffic to run on. After your cloud-native deployment is hardened, WAF can be added to monitor the necessary traffic.
If you’re interested in a demo to see how Octarine gives you visibility and security for your microservices, please reach out here.
Istio and Octarine are Two Peas in a Pod
By William Choe, VP Marketing/Product of Octarine
Istio delivers a new approach to networking for cloud native applications. With applications componentized to discrete functions, tremendous scalability and agility is achieved. However, network service identity based on the five-tuple and a centralized architecture is no longer effective. Istio network services are optimized for cloud native apps with key capabilities such as service discovery, routing, and load balancing. Once all the upstream and backend microservices are identified, Istio routing selects the right upstream service cluster and load balancing determines which service instance the request should be sent with the right policy (e.g. retries, timeouts). Further, for each request, detailed statistics, logs, and trace data are generated for traffic flow and forensic data visibility. This is service mesh butter…enabling a predictive and optimized cloud-native experience.
With New Kubernetes Plugin, Role-Based Access Control Has Never Been Easier
By Haim Helman, CTO/Co-Founder of Octarine
If you are using Kubernetes (K8s), you’re going to want to think about how to minimize its attack surface. To help you achieve least privileged access permissions, we've developed an open-source tool, Kubectl-RBAC. This tool makes it quick and easy to establish and maintain role-based access control (RBAC) for your K8s clusters.
The recent article written by Matt Conran on Network World succinctly captures the challenges with securing cloud native applications. Traditional security models are focused on keeping the bad actors out, whereas the article suggests a new model, zero trust security (similar to the one used by Google, Netflix, and Facebook). The article highlights some key tenets such as application identity, visibility, and policy when securing containerized applications.
By William Choe, VP Marketing/Product of Octarine
We are at a unique inflection point both in the market, as cloud-native applications start to take off, and with our company, as we publicly launch our cloud-native security platform. On the precipice of this gigantic IT shift and company milestone, I thought it would be good to capture the moment, so I sat down with Octarine’s two founders, Shemer Schwarz (SS) and Haim Helman (HH) to get their perspective on what’s going on. Here’s what they had to say: