Aqua Extends Container Security Platform to Kubernetes, Cloud Services
Aqua Security has extended its container security platform to cover the Kubernetes open source container orchestration tool, as well as to third-party container-as-a-service cloud platforms, where users may not otherwise enjoy full security control over their containers.
Aqua 3.0, designed to manage container security across both development and deployment, takes advantage of a number of controls introduced in Kubernetes 1.8, including those for managing image assurance, network segmentation, and role-based access controls, said Amir Jerbi, co-founder and chief technology officer at Aqua Security.
With Aqua 3.0, users can create fine-grained user access control roles and policies. Access to kubectl commands can be specified to particular users, and governed by Aqua’s scalable labeling format. The Kubernetes controls also provides the ability to block unapproved images from running across entire cluster, as well as the ability to control network traffic based on Kubernetes namespaces, clusters or deployments.
In addition to security features, Aqua 3.0 also comes with an expanded set of benchmark and logging capabilities. It integrates the company’s Kube-Bench, a set of checks for ensuring Kubernetes has been secured properly.
“The benchmark itself really is just a document. Most organizations are doing just a manual checklist. The integration here makes the checks much more automated,” said Andy Feit, Aqua vice president of marketing. “As your systems are running, we will flag everything that is outside the benchmark.”
Aqua’s event logging captures Kubernetes-specific information, such as pod name, type, deployment and namespace data, providing additional visibility for compliance and forensics.
The company has also extended its set of protections for where the user does not control the host environment, namely container-as-a-service (CaaS) environments such as Microsoft’s Azure Container Instances (ACI) and Amazon Web Services’ Fargate — through a set of runtime security controls branded as “MicroEnforcer.”
A sidecar is added to each container during the image build that monitors and controls instantiated containers, preventing any unauthorized activities. The “MicroEnforcer” identifies malicious activity on third-party services, much in the same way that the company’s “Aqua Enforcer” does with self-managed services. It also manages the operations to secure operations, such as injecting secrets into containers so they can be used for authorization, and collects alerts so they can be distributed to security information and event management (SIEM) and analytics tools.
With the managed service, “There is no perimeter, there is nothing you can pre-install. So the challenge is how do you get the security embedded into the application,” Jerbi noted. The user embeds the MicroEnforcer into the container along with the application. “It’s basically an additional layer in your image. As you ship your image, it will identify that it is operating in a [third-party hosted] environment, it will start operating itself, and start protecting the containers.”
MicroEnforcer ships its logging info back to the command center, alongside regular in-house deployments of Aqua. This integrated approach offers a freedom for operators in that they can run containers across managed security or unmanaged security environments without making any changes when moving them across the two environments.
Feature image via Pixabay.