Re: [PATCH 2/9] Implement containers as kernel objects

> I believe we are going to need a container ID to container definition > (namespace, etc.) mapping mechanism regardless of if the container ID > is provided by userspace or a kernel generated serial number. This > mapping should be recorded in the audit log when the container ID is > created/defined. Agreed. > > As was suggested in one of the previous threads, if there are any events not > > associated with a task (incoming network packets) we log the namespace ID and > > then only concern ourselves with its container serial number or container name > > once it becomes associated with a task at which point that tracking will be > > more important anyways. > > Agreed. After all, a single namespace can be shared between multiple > containers. For those security officers who need to track individual > events like this they will have the container ID mapping information > in the logs as well so they should be able to trace the unassociated > event to a set of containers. > > > I'm not convinced that a userspace or kernel generated UUID is that useful > > since they are large, not human readable and may not be globally unique given > > the "pets vs cattle" direction we are going with potentially identical > > conditions in hosts or containers spawning containers, but I see no need to > > restrict them. > > From a kernel perspective I think an int should suffice; after all, > you can't have more containers then you have processes. If the > container engine requires something more complex, it can use the int > as input to its own mapping function. PIDs roll over. That already causes some ambiguity in reporting. If a system is constantly spawning and reaping containers, especially single-process containers, I don't want to have to worry about that ID rolling to keep track of it even though there should be audit records of the spawn and death of each container. There isn't significant cost added here compared with some of the other overhead we're dealing with.