Aqua Security rolled out initial runtime security control support for container workloads running across the CRI-O Kubernetes runtime platform. A container runtime provides an API and tools that abstract low-level technical details in the container.
CRI-O combines the container runtime interface (CRI) with the “O” from the Open Containers Initiative (OCI) project. CRI-O launched last year as an integration path between OCI conformant runtimes and Kubernetes kubelets. It’s designed as a lighter alternative to using Docker as the runtime for Kubernetes.
Aqua’s container security platform prevents unauthorized images from being selected to build a container pod; uses machine learning to monitor a container’s behavior and apply policy; audits container activity; and provides a firewall of container network connections. It can run either on premises or in the cloud and supports Linux and Microsoft Windows runtime environments.
“Due to the rising popularity of Kubernetes, it is very likely that many new deployments will be using CRI-O instead of the more general purpose Docker runtime,” said Aqua Security Co-Founder and CTO Amir Jerbi.
Broad support for CRI-O will begin in July.
Containers are short-lived entities designed to execute a specific function over a fairly short period of time. However, a security breach can result in a container running for longer than scheduled, providing access to or dumping out sensitive data running inside of that container.
Dealing with containers in a production or runtime environment, however, can be tricky. Analysts have warned against attempting to tamper with those running containers as that can impede the supported application. Instead, they recommend organizations keep their hands off containers in production. This requires a greater focus on securing the content that makes up a running container before that content is distributed or outside of a running container.
A number of security firms have noted that basic protocols designed to check on the running status of a container can highlight whether a container deployment has been breached. Jerbi explained this sort of response also needs to be automated to be most effective.
“Due to the very dynamic and sometimes ephemeral nature of containers, automated response is crucial,” Jerbi noted. “This includes the ability to stop a container from performing an action it isn’t supposed to perform, … and doing so automatically as much as possible since a human response may be too slow.”
Aqua Security was also part of an effort launched last week by Google to secure runtime environments across Google’s Kubernetes Engine (GKE). Aqua was one of five container-focused security providers to join Google’s Cloud Security Command Center. The others were Capsule8, Stackrox, Sysdig Secure, and Twistlock.
Google’s security team noted in a blog post that the combined efforts would provide for “the best options for container runtime security” in Google’s Cloud Platform (GCP).
Aqua Security last month was the first container security partner to join VMware AppDefense’s recently enhanced efforts. That platform added a focus for securing containerized workloads by connecting into native runtime environments like Kubernetes or Docker. Aqua’s technology will send container context to AppDefense and feed enforcement alerts into the AppDefense console for management and remediation.