“Just defending the perimeter is not enough anymore,” said Haim Helman, CTO of Octarine, a company focused on network security for microservices and Kubernetes workloads.

Their new products play well with all cloud providers, with on premises solutions and with the OpenShift and pivotal Kubernetes service to name a few.  They’ve also been working with the Google team to integrate Octarine into Anthos, especially for the use case of securing the CloudRun function-as-a-service framework.

“We decided to build a solution that makes it easy and friendly for developers and DevOps teams to infuse security into their cloud native environments,” Helman said.

“Just defending the perimeter is not enough anymore” – Helman

Open source at the heart
Octarine is also heavily involved in the open source community.  They have released an integration of the ModSecurity Web Application Firewall with the popular Envoy proxy to allow better protection of APIs in microservices. They’ve also open sourced MAPL, their policy language that lets people to develop their own automated policies whether for network access, managing admissions, or controlling Kubernetes.

They have further made available a free downloadable risk assessment scanner called kube-scan: “What we really want is to allow developers, DevOps people, and security teams to get this first glimpse of their security posture in Kubernetes,” he said.

You can’t control developers

With the shift to microservices, Helman noticed a necessary shift in culture and organizational structure to accommodate DevOps and deploying in cloud native applications.  “There’s a lot more power in the hands of developers now than there ever was before,” he said.

Developers are provisioning cloud infrastructure that governs that process of provisioning network assets, and storage.  This means they also control security in the cloud.

Trying to restrict developers to very specific set of rules is impossible, said Helman. “I believe the only way to implement security in this new culture in this unique environment is by setting guardrails.”

And that means deciding what your acceptable level of risk is. What are the things you are allowing, and what things should not happen? “Security is best serviced by setting scopes for those rules and then allowing the developers to work freely within those guardrails,” he explained.

Octarine’s dual focus

Enter Octarine Guardrails, which provided a set of boundaries for developers to operate in based on policies-based best practices derived from the NIST and CIS benchmark and other sources. They can be customized by the customer as well. Starting with risk assessment via kube-scan, the customer can first identify the security posture of its workloads, and then develop policies based on a set of predefined templates provided in Guardrails.

Giving visibility to blind spots
Helman said their customers are finding blind spots in their security posture from running container image scanning starting from the configuration to the workload.   So the second area of focus in Octarine is runtime, leveraging the service mesh approach. “It’s extremely powerful to offload network, functionality into a proxy in large scale deployments,” said Helman.

There are three zones addressed: visibility, detection, and telemetry.

Octarine shows which workloads are deployed and how they are interacting with each other.  “Once you have your workloads deployed, you want to be able to see what’s going on,” he said.

On top of visibility, they built intrusion detection capabilities, an anomaly detection engine, and  signature-based threat detection.

The third zone is telemetry. “We build our anomaly detection and threat detection and also to policy enforcement. So we help the customer define their network policies, to control access and also to control what egress traffic leaves the cluster,” he said.

By TC Currie