Aqua Security today unveiled a Kubernetes Security Posture Management (KSPM) offering that provides IT teams with a set of policies and controls to automate configuration and compliance of Kubernetes clusters.
In addition, Aqua Security has added a Kubernetes Runtime Protection module that provides an option for using Kubernetes Admission Controllers to deploy security controls as a set of sidecar containers directly on to a Kubernetes pod.
KSPM comes with more than 20 predefined rules available out of the box as well as support for Open Policy Agent (OPA) Rego rules that IT teams can use to build custom rules. These policies work in conjunction with existing Image Assurance Policies developed by Aqua Security to control which containers run in a cluster based on their contents and configuration as well as pod configuration.
In addition, a Kubernetes roles and subjects assessment capability tracks user and service account privileges to identify risks and make remediation suggestions.
The company also updated its Cloud Security Posture Management (CSPM) offering for containers and virtual machines to include a customizable dashboard, support for the Amazon Web Services (AWS) Bottlerocket operating system, auto-remediation capabilities on the Microsoft Azure cloud, additional compliance reporting and the ability to scan NFS mounts.
Rani Osnat, vice president of strategy and product marketing for Aqua Security, says as Kubernetes becomes more widely deployed in production environments the number of attacks aimed at misconfigured Kubernetes clusters will increase steadily. The issue is that given the complexity of Kubernetes, it’s relatively easy to make a mistake, he notes. Many IT teams are also worried about breaking applications when they add additional security controls after a Kubernetes cluster is up and running.
In fact, most Kubernetes clusters are deployed by developers who have limited security expertise. The roles and subjects assessment capability enabled by Aqua Security should make it easier for developers to securely deploy Kubernetes clusters by surfacing setting recommendations based on risk versus simply presenting developers with a set of configuration issues that lack any context, adds Osnat.
No developer deliberately sets off to deploy a misconfigured Kubernetes cluster. Developers in the interest of speed are using tools such as Terraform to automate the deployment of Kubernetes clusters, many of which are inadvertently misconfigured. Cybersecurity teams don’t always have the time or expertise required to vet those deployments.
Those issues, however, don’t appear to be slowing down the rate at which Kubernetes clusters are being deployed, as organizations rush to build and deploy cloud-native applications. The need to build more flexible and resilient applications is trumping security concerns.
As organizations eventually embrace best DevSecOps practices, many basic security issues should be addressed as part of the workflow of building and deploying cloud-native applications. As is always the case with any emerging IT platform, security is once again playing catchup, notes Osnat.
Hopefully, developers will now apply an ounce of Kubernetes configuration prevention more aggressively before a pound of cybersecurity cure is required later.