A recent survey by Armo on the use of security software solutions with Kubernetes found that over half of respondents leverage open-source tooling. Companies using open-source tooling, use on average 3.6 different tools. These open-source tools were predominately used for service mesh, network policy and micro-segmentation, and misconfiguration scanning.
There was a significantly larger use of open-source tools for service mesh solutions (32%) than other options (24%). The survey authors posit that this is due to there being several well-supported open-source service mesh solutions available. They specifically call out Cloud Native Computing Foundation (CNCF) graduated projects such as Linkerd, Istio, and Open Service Mesh.
A survey by the CNCF on service mesh technologies backed this finding. They found that Linkerd and Istio were the two most popular solutions in use. These were followed by proprietary solutions such as HashiCorp Consul and AWS App Mesh.
William Morgan, CEO of Buoyant, noted in an article for InfoQ that service meshes are a good tool for setting up a zero-trust solution. Morgan notes that service meshes provide workload identity, granular enforcement, and a consistent means of authentication and authorization. However, Morgan also called out that "just adding a service mesh to the cluster is not a panacea" as work needs to be done to ensure it is configured, maintained, and used properly.
Survey respondents noted frustration with proprietary software being opaque solutions where they have limited control or influence. This challenge was followed by difficulty in understanding pricing models in addition to proprietary software being too expensive. However, proprietary software was heavily used for vulnerability scanning, secrets protection, and runtime security. Over half of the respondents have a commercial solution in place for those three areas.
There was some alignment in respondents' belief in who should own these solutions versus who currently owns the tooling in reality. DevSecOps teams were ranked highest as both the team that currently owns the solutions at 58% with 63% of respondents saying they believe DevSecOps teams should have this responsibility. The report authors did note they did not ask more questions regarding how the organizations have structured their DevSecOps teams.
However, there is still a lack of maturity and understanding for the term "DevSecOps", and we didn't ask what the DevSecOps function looks like in each company, for example where it sits in the org chart, or who it reports to.
In a recent InfoQ panel discussion on Kubernetes Security, Thomas Fricke, Cloud Security Architect, highlighted the importance of DevSecOps:
I'm one of the people who definitely promote DevSecOps, or better, SecDevOps, at the customer side. This means, please don't add additional security tasks to the developer. The developers need to handle 10 times or 100 times more code than 10 years ago. Please add extra security people and then teach them about Kubernetes.
Aligned with Fricke's concern, the report found that only 10% of respondents consider their developers and security teams to be experts in handling the security of their Kubernetes environments.
The full State of Kubernetes Open-Source Security report can be found on Armo's website.
Comments