By Haim Helman, CTO
In the cloud native world, there is no event bigger than KubeCon and no KubeCon has ever been bigger than the 2019 North America event that was held in San Diego, California from November 19 – 21.
Over 12,000 people flooded the halls of the expansive San Diego Convention Center to hear from experts and vendors about the latest and greatest in cloud native. We were among the many vendors exhibiting at the event and were busy throughout the week with a seemingly endless stream of people stopping by our booth as they wandered through the crowded hallways.
While Kubernetes has become increasingly popular in the last two years, there are a lot of newcomers to the technology. Learning about Kubernetes and particularly Kubernetes security was a key driver for many of the people we spoke with.
A lot of people just don’t know what they don’t know. They have things running in Kubernetes, they may be running scans and they wanted to know what’s missing. Many of the individuals we spoke with knew they were missing a runtime solution, but they didn’t realize that they had things in Kubernetes even before runtime, that they were not covering.
Interest in Service Mesh is High
There was also a lot of interest in service mesh at KubeCon for various reasons. In the past, people tended to very suspicious about service mesh, even after we would tell them that at Octarine we’ll handle it for them. Now in 2019, with major improvements to Envoy, Istio and Linkerd, service mesh resonates way more than it ever has before.
The lightweight nature of service mesh, its ability to help users scale management and operations are all things that potential users now understand. Though there is now broader acceptance of service mesh as a concept and as a technology that should be deployed as part of a cloud native architecture, there are still some missing pieces.
Lots of people came up to us at the booth saying they plan on using the Istio service mesh, to which we responded – that’s awesome, but you still need security for Istio.
Is there still a perimeter?
One of the big questions that people still ask is about the perimeter.
There was a time when the network perimeter, the stuff that exists outside the four walls of an enterprise and beyond the primary firewall and IPS, was the big thing that needed to be protected – that’s no longer the case.
When we’re asked about perimeter defense, what we end up doing is explaining that in the cloud native world it’s more about protecting micro-services and east-west traffic within a data center. Perimeter defense is not enough when each microservice is talking to many different other services, any one of which could represent a potential risk when the perimeter is breached.
Understanding Shared Responsibility
Another area that we were asked about is basic Kubernetes hardening for the infrastructure, rather than for the workload. People wanted to know what they need to do to secure Kubernetes, which is an important topic, but it’s not the only thing that matters when it comes to cloud native security.
It’s important to understand that for those that run Kubernetes as a service, for example on a cloud provider, security is a shared responsibility. What that means is that the service provider takes responsibility for certain elements, such as the core Kubernetes platform that is installed. In the shared responsibility model, the user is still responsible for the non-core elements and most importantly the workload itself.
With many cloud native workloads landing on service provider platforms, a lot of the burden for security teams is actually in protecting the workload, more so than the infrastructure.
With all the noise in the cloud native landscape, and the ‘real’ noise in the large exhibit halls of KubeCon, it’s easy for any one message to get lost. The key slogan that Octarine had for our booth is – DevSecOps simplified.
Many KubeCon attendees asked us about our slogan. They’re struggling with the intersection of development, operations and security and they wanted to see how Octarine can simplify DevSecOps for them.
One of the ways we help make DevSecOps easier is with our risk score, which we demonstrated in hundreds of presentations in the booth. Our new kube-scan risk assessment tool, that we launched at KubeCon, generated a ton of interest. It’s an easy on-ramp for anyone to simply get a quick evaluation of cloud native workload runtime settings and how much risk might be associated with them.
Our guardrails approach also served to get the message of DevSecOps simplified across to KubeCon attendees. With guardrails, companies start with a basic out-of-the box policy that’s very powerful for alerting and informing users about what is insecure.
If you saw us at KubeCon NA 2019, thanks for dropping by. If you missed us, be sure to try kube-scan, our new risk assessment tool for Kubernetes workloads to instantly get a snapshot of your security posture. And email us at email@example.com if you would like to go over your results or to find out how we simplify DevSecOps.