Alcide Adds Kubernetes Security, Compliance Advisor
Alcide this week launched Alcide Advisor, a scanning tool for Kubernetes clusters and Istio server mesh platforms that continuously scans for security and compliance issues.
Company CTO Gadi Naor says Alcide Advisor takes advantage of the application programming interfaces (APIs) exposed on Kubernetes clusters to identify a range of issues that can be fed back into a continuous integration/continuous deployment (CI/CD) pipeline for developers to address or use the Alcide container security platform to apply a new policy.
In addition to scanning for common vulnerabilities and compliance issues, Naor notes Alcide Advisor provides a single pane of glass for monitoring all the cybersecurity, governance and compliance issues that might impact a Kubernetes environment.
Potential issues Alcide Advisor identifies include compliance with the Kubernetes Center for Internet Security (CIS) Benchmark, misplaced secrets, excessive access to secrets, deviations from best practices for Ingress controllers, deviations from best practices for deploying Kubernetes on Amazon Web Services (AWS) and Istio security configuration errors.
One the major obstacles holding back broad adoption of Kubernetes is security. Kubernetes is not necessarily less secure than other platforms, but it is a lot more complex in terms of the number of configuration controls that need to be mastered. The chance a human administrator is likely to make a mistake is high. As the number of Kubernetes clusters proliferating across the enterprise increases, it’s almost inevitable someone will make a serious mistake. It’s also now a matter of time before more cybercriminals take note of increased deployments of Kubernetes clusters, which means a wave of cyberattacks aimed specifically at Kubernetes is most likely in the offing. In fact, at least two severe cybersecurity vulnerabilities relating to Kubernetes have already been disclosed, so Naor says IT organizations should expect more to follow given the relative immaturity of the platform.
At the same time, Kubernetes clusters will be coming to attention of auditors, most of whom won’t understand how the clusters work, but will insist that the teams managing them should be able to document the processes being employed to manage them. That’s going to be a lot easier to achieve using an application that tracks and identifies where compliance holes in those processes are before the auditors arrive.
As Kubernetes clusters are deployed in production environments, the policies and rules that enterprise IT organizations rely on to bring order to their internal IT chaos will be applied to Kubernetes. Tolerance for any so-called “black box” in enterprise IT environments is virtually nil. Development teams that don’t find a way to address these issues likely will run into a ton of organizational inertia that they may overcome eventually. But then again, every minute spent arguing over cybersecurity and compliance issue is that much less time those teams will spend writing code. The easier path will be not so much finding a way to create an exception to the rule for Kubernetes but rather eliminating the cybersecurity and compliance friction surrounding the adoption of Kubernetes in the first place.
