A recent Armo survey on the use of security software solutions with Kubernetes found that more than half of the respondents use open source tools. On average, companies using open source tools use 3.6 different tools. These open-source tools were primarily used for service mesh, network policy and micro-segmentation, and misconfiguration scanning.
Open source tools were used significantly more often (32%) than other options (24%) for service mesh solutions. The survey authors believe this is due to the availability of several well-supported open-source service mesh solutions. In particular, they mention the projects completed by the Cloud Native Computing Foundation (CNCF) such as Linkerd, Istio and Open Service Mesh.
A CNCF survey on service mesh technologies confirmed this finding. They found that Linkerd and Istio were the two most commonly used solutions. This was 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 building 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 noted that “just adding a service mesh to the cluster is not a panacea” as work needs to be done to ensure it is properly configured, maintained and used.
Survey respondents expressed frustration that proprietary software presents opaque solutions over which they have limited control or influence. This challenge was followed by difficulties in understanding pricing models, in addition to proprietary software being too expensive. However, proprietary software was heavily used for vulnerability scanning, secret protection, and runtime security. More than half of those surveyed use a commercial solution for these three areas.
Respondents’ opinions of who should own these solutions were in fact the same compared to who currently owns the tools. DevSecOps teams were ranked highest as both the team that currently owns the solutions, with 58% and 63% respectively, of respondents saying they think DevSecOps teams should take on that responsibility. The report’s authors noted that they did not ask additional questions about how organizations structured their DevSecOps teams.
However, there is still a lack of maturity and understanding of the term DevSecOps, and we haven’t asked what the DevSecOps function looks like in each organization, such as 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, emphasized the importance of DevSecOps:
I am one of the people who are definitely driving DevSecOps, or rather SecDevOps, on the customer side. This means please do not add any additional security tasks to the developer. Developers have to process 10x or 100x more code than they did 10 years ago. Please add additional security staff and then educate them about Kubernetes.
Consistent with Fricke’s concerns, the report found that only 10% of respondents consider their developers and security teams to be experts in managing the security of their Kubernetes environments.
The full State of Kubernetes Open Source Security Report can be found on the Armo website.
