Yesterday Microsoft dropped a bombshell in containersphere, announcing Azure Container Instances, or ACI.

ACI is a natural step in the evolution of cloud-native containers - it’s a way to run and consume containers directly in Azure, with no provisioning of VMs needed. This means that customers no longer have to spin up a VM in order to run containers on it, which is more efficient and scalable, and also allows leveraging Azure’s RBAC directly to govern access to containers.

With VMs gone, however, so goes the confidence of isolating workloads from each other, something many adopters of containers use today as a security layer. In fact, customers wouldn’t know where their containers are running. This make runtime protection of containers even more cardinal.

The K8S Connection

Another big change that ACI brings is that Microsoft released as open-source a connector to run ACIs directly from Kubernetes. This connector is actually an implementation of (ready for another 3-letter acronym?) CRI - the Container Runtime Interface of Kubernetes. It originated as a project led by OpenShift but was adopted by the K8S community.

CRI allows you to run containers using different container engines (not necessarily Docker Engine). For example, RKT (CoreOS’s engine) can run seamlessly over Kubernetes - earning it the nickname rktnetes.

At Aqua we’ve been adjusting our runtime controls instrumentation to handle CRI so we can provide the same level of protection to any CRI container as we have been to Docker Engine -based environments, including both monitoring and granular prevention of unauthorized activities such as file, executable or network access.

With OpenShift, CoreOS, and now Azure supplying CRI connectors for Kubernetes, we’re ready to take the plunge. If you’re interested in joining our private beta of runtime security for CRI based containers - let us know!