In my previous blog, I discussed the challenges and solutions of gaining accurate insight into container images. Now, it’s time to deploy these container images in production. Container images can be scheduled and orchestrated across various locations and hosts based on the need and usage of each individual container. You now need to understand what the running container is doing, commonly known as dynamic analysis.
In order to monitor and analyze these containers in production, one must understand the key difference of containers — the lack of an operating system. Simply defined, a container is a runtime instance of a container image, consisting of the following:
- A container image
- An execution environment
- A standard set of instructions
Unlike static analysis, the execution environment and standard set of instructions cannot be analyzed until the container is actually running. Traditional application monitoring and security tools struggle to meet the requirements of containers. These tools require an agent that runs on the same host as the application. However, in a container-based, microservices environment, it is not feasible to run a monitoring agent inside a container. This creates a new set of challenges, as you need to constantly monitor changes in a running container’s state and execution paths. Additionally, you need to monitor any code changes that are applied to the application. Let’s look at each of these challenges, and their corresponding solutions, separately.
Monitoring Container Activity
The first challenge is understanding what the container is actually doing. Not just application activity, but system, network, storage, and application activity. Monitoring container activity is critical for developers, operations, and security teams, as they run and secure applications.
In order to best monitor the activity of containers, dynamic, adaptive analysis within the running container is required. The best adaptive analysis approach injects security probes within the container binary to monitor the application. By injecting security probes within the binary, this approach does not impact the development process or business logic of the application. It also does not impact the source code of the application.This approach allows monitoring of all system, network, storage, and application activity from inside the container. All without impacting the development process, meaning zero-touch to development.
Understanding Container and Microservice Connectivity
The next challenge is understanding container connectivity. Containers are typically deployed within a microservices-based architecture, improving speed and scalability. However, this means that suspicious activity will likely involve multiple containers, communicating with multiple microservices, across various hosts. As different applications often share the same microservices, monitoring tools must be able to dynamically identify which instance of a microservice is communicating with each application.
By continuously monitoring system, network, storage, and application activity from inside the container, you can understand connectivity. This includes each application, container, and microservice across the entire environment. Finally, visualizing this connectivity map instantly identifies which containers and microservices are communicating normally and abnormally.
Building Activity and Behavior Profiles
The last challenge is building ongoing activity and behavior profiles for enforcement. Dynamic protection of the running container itself is the next evolution of container security. This requires the establishment of a normal baseline, and ongoing analysis, that can be enforced at runtime.
During observation of the running container, the injected security probes monitor both activity and behavior. This allows the creation of profiles that establish a normal baseline. These profiles are then converted into security policies to enforce runtime behavior, which is the next blog post.