LWN: Comments on "Audit, namespaces, and containers"

Audit, namespaces, and containers

Wajih — Sun, 06 Nov 2016 20:56:27 +0000

Sorry I mean roqscheer.

Audit, namespaces, and containers

Wajih — Sun, 06 Nov 2016 20:54:55 +0000

Hi Aravinda, Can you elaborate more on this? I am trying to separate audit/event logs of each docker container. But I do not see separate session ID for each separate container event logs. All logs have same session ID.

Audit, namespaces, and containers

roqscheer — Wed, 19 Oct 2016 13:24:06 +0000

A quick-and-dirty trick would be to use the existing session ID as the container ID. That is, the container orchestration engine (Docker daemon, runC, rkt) uses setsid to become a new session leader. The session/container ID will then be inherited by all processes spawned inside the container. I think this will not bend the session concept too much: we will just add a new use for the session ID (container session) to the existing terminal and daemon session ID usages. Session IDs are already recorded in the audit log entries.

Any process can easily become a new session leader, but these events should be being logged. Thus one analysing the audit log might need to backtrace a session ID's ancestry to link it to its respective container, if that is the case. Another solution would be to restrict setsid inside containers (using seccomp, for instance) so the ID would remain constant for all processes inside the same container.

Audit, namespaces, and containers

Aravinda — Tue, 13 Sep 2016 09:37:44 +0000

>> An alternative would be to add a "container ID" that would be set by the orchestration system and tracked in the task structure

Adding a "container ID" would also help to enable container-aware tracing support.

We are working on filtering container specific events when perf tool is executed inside a container [1]. One of the challenges is that the kernel has no concept of a container. This makes it difficult to identify whether an event was triggered inside a container or not. We have attempted two solutions for this. The first solution adds a new perf namespace [1] and the second uses the existing cgroup namespace as the container identifier in the kernel [2]. However, we think setting the "container ID" by the orchestration system is a clean solution.

+1 for the above suggestion of adding a "container ID".

[1] https://lwn.net/Articles/691298/
[2] https://lkml.org/lkml/2016/8/25/404