Octarine Offers a Platform for Securing Kubernetes Workloads
Portworx sponsored The New Stack’s coverage of KubeCon + CloudNativeCon in San Diego.
Container security company Octarine has launched Guardrails and Runtime, a pair of technologies designed to keep Kubernetes workloads secure during the development, testing and deployment phase as well as in runtime.
Many companies running Kubernetes in production rely on container image scanning to detect threats, explains Haim Helman, chief technology officer and co-founder of Octarine. “That leaves blind spots into risks that are in the configuration of workloads deployed in Kubernetes and also in the runtime behavior.”
Octarine Guardrails and Octarine Runtime address those two security blind spots.
One of Octarine’s customers had a developer remove all authentication from a workload that was not supposed to be exposed to the internet in order to do testing. Then the workload was accidentally pushed into production and exposed. This is the kind of security problem that Guardrails can prevent. Runtime would detect any anomalous behavior if the workload were compromised, Helman says — but container scanning would not.
“There is a lack of knowledge of cloud native in the security team,” Helman explains. “There is a lack of knowledge and skills of security on the DevOps team. Tools that are opinionated, that have pre-baked policies, that are automation-friendly, helps bridge the gap.”
Putting up Guardrails
Kubernetes does more than orchestrate containers. Developers use it to provision storage, configure networks, manage secrets and define privileges. This is done directly using YAML. Unless there’s a way to ensure best practices are followed consistently, organization-wide, it’s possible — perhaps inevitable — that a mistake can slip in.
Octarine Guardrails provides an admission controller that runs in the cluster and enforces policies. Best practices policies are pre-loaded, but users can also extend or alter the templates Octarine provides by default. Deployments that violate policies can be automatically denied.
In addition, there’s an API that can be integrated into the continuous integration tool that provides analysis of YAML files for policy violations.
The closest equivalent to Guardrails, Helman says, is Kubernetes Pod Security Policy, which is included in core Kubernetes. But Pod Security Policy only looks at the attributes of the pod, not at how the pod is exposed to the outside world, like which secrets the pod has access to. The data from Pod Security Policy is also buried in logs, hard to visualize and has no automatic enforcement.
Security in Runtime
“There are two main problems with scanning images,” Helman explains. “One is that it only looks for vulnerabilities that have already been detected and understood.” This often does not happen until the vulnerability has been around for weeks or months. It has to be added to a Vulnerability Database before an image scanner will detect it.
“The second problem is that container scanning only looks at the known library,” Helman says. It’s not looking for custom code, and won’t detect policy violations in custom code because that’s not what the tool is looking for.
Octarine Runtime uses a service mesh, either integrating with customers’ Istio deployments or using its own Envoy-based service mesh, to capture and analyze traffic and look for any behavior anomalies. The service mesh can also be used to define and enforce policies in runtime related to segmentation, access control and egress traffic.
Octarine will be demonstrating these new technologies at KubeCon+CloudNativeCon this week in San Diego.
KubeCon+CloudNativeCon is a sponsor of The New Stack.
Feature image by Jill Wellington from Pixabay.
