Auditing Docker Containers in a DevOps Environment

Docker Audit

Special Thanks: This article was made possible by support from Linux Professional Institute

Thanks to the unremitting, ever-present threat of a multitude of attacks to which a Linux system can be subjected, it’s critical to capture important changes and events made by users and processes on your running systems.

Highlighting such changes could potentially point toward something as innocuous as a simple misconfiguration but, equally, might proactively help stop an impending attack dead in its tracks. Additionally, having trustworthy, detailed logging data is exceptionally useful for post-event forensic analysis, especially when you are trying to discern how an attacker originally managed to compromise your system and get a foothold.

One such package I have been using recently on a large AWS server estate is called auditd . Its man page states: “auditd is the userspace component to the Linux Auditing System.”

One of the pages on the Linux Audit Documentation project GitHub site describes its (very old) original design as being based around the following aims:

The main goals were to provide system call auditing 1) with as low overhead as possible and 2) without duplicating functionality that is already provided by SELinux (and/or other security infrastructures).

For the uninitiated, “system calls,” which are more commonly referred to as “syscalls,”occur when processes ask the kernel for a hand with something. The syscalls man page reports, “The system call is the fundamental interface between an

... comments powered by Disqus