We help IT Professionals succeed at work.

Kubernetes related security tools.

marrowyung asked

what Kubernetes security tools you guys are using ?

I heard about one newcomer, Octarine, piggybacks on the Envoy proxy and Istio service mesh, NeuVector,  CI/CD pipeline what are all that ?

from topology point of views how they fit into the picture of Kubernetes  ?

I can't find resource of above tools, please suggest!

which one is necessary and unnecessary and which one is good ?

seems Octarine's Kubernetes security software is good as it monitor the whole thing ? This tools can let you know when [cluster configurations] are violating policies, like if they're public by default when they're not supposed to be.

and seems NeuVector can operate at nearly the same feature as Octarine ?
Watch Question

Exec Consultant
Distinguished Expert 2019
couple of fundamental term need to identify so that we are clear each of these solution plays

Security Mesh (SM) - Adding layer of security in a service mesh
Container security (CS) - Adding in protection to the application running in container
Orchestration Manager (OM)  - Manage all the container running in the Pod deployment under a Cluster of nodes
Code Pipeline (CP) - Run seamless chain of code checks (using security tools), build ready apps and deploy into the production environment

SM - NeuVector while Istio is the Service Mesh, and underlying is sidecar proxy which Envoy can serves as to manage all transaction across the services
> the short of it is that these lay the foundation of the data and control plane for running your apps

CS - Octarine while Kubernete is the OM that oversees all the running apps in the container environment
> the short of it is that both will rely on the foundation to track the services which is also secured with protection policy applied

SM and CS are the security element to the service mesh and Kubernete. They have technologies that can overlap but it it is best to trial out or talk to the tech sales on the difference. Below are my quick take with reference from some public inputs.

For CS (Octarine as an example), many companies running Kubernetes in production rely on container image scanning to detect threats, however, 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. E.g., if a developer remove all authentication from a workload that was not supposed to be exposed to the internet in order to do testing, the workload will be accidentally pushed into production and exposed. Guardrails does the prevention and alert on change in configuration that differs from policy and Runtime detects any anomalous behavior if the workload were indeed been compromised even if it is scanned alright.

For SM (NeuVector as example), the core service mesh technology is a container. When you put it on any Kubernetes worker node or Docker host, NV inspect all the traffic on that host. Istio and Linkerd insert a sidecar container into the pod. Istio uses the Envoy proxy. The container sends its connections through the proxy, where it is encrypted before sending it out to other pods or externally. NV intercepts those connections before it’s encrypted in Envoy. Then on the other end, the receiving Envoy sidecar decrypts it, then we look at it before it hits the receiving application container.

NV also visualizes, monitor and protect service mesh system connections and containers plus application workloads managed by a service mesh. Besides its deep packet inspection, it also has the ability to segment services at the application layer and to define authorization between services with Layer 7 segmentation rules generated automatically based on a baseline of network traffic and processes generated from behavioral learning.

There are similar tools which you may want to take a look - worthy to note is AquaSec and Twistlock

Hope it helps
David FavorFractional CTO
Distinguished Expert 2019
Best security is just locking down each machine + container correctly.

No... added security will break basic security...

For example, running any clear text protocol (FTP, HTTP, IMAP, POP, SQL) where user/pass logins can be scrapped off the wire allows people to login to each subsystem, avoiding any security.

Likewise, running old software, with known backdoors will allow hackers into your machines. Old Kernels/PHP being the most common offenders.

Several great security discussions have occurred on EE recently...



Might be useful for you to review these discussions.
madunixExecutive IT Director, MVE
Most Valuable Expert 2019
>>Best security is just locking down each machine + container correctly. << 
I agree with above. Hardening is most useful as a preventative measure when designing system security. However, hardening can be useful after an incident has occurred to shut down any lingering effects or to purge a system of infection. Hardening can also remove and prevent further unauthorized users from accessing compromised systems. Check also topics collectively relate to cloud security or something straightforward, such as "Securing the cloud."

btanExec Consultant
Distinguished Expert 2019

The Cloud Native Computing Foundation (CNCF) Interactive Landscape can be handy serving as a resource map that filters and categorizes hundreds of cloud-native projects and tools. It organizes technologies into groups, based on functionality, such as scheduling and orchestration, databases and container registries. This map is to help enterprises navigate the vast technology ecosystem around cloud-native application deployments. Enterprises can choose the tools specifically listed on the map, or use the interactive landscape to see other options. https://landscape.cncf.io/
marrowyungSenior Technical architecture (Data)


tks all
David FavorFractional CTO
Distinguished Expert 2019

You're welcome!