4

I've read numerous articles on this going back to 2013, but what I wasn't able to ascertain is whether a reliable method has yet been devised for auditing processes inside a container. This question applies primarily to Linux, as I'm not very familiar with containerization on other platforms.

The problem is essentially this: How to track operations such as Linux system calls back to the user who created the container?

With Docker, that information is lost because the container is started by a daemon, and Docker doesn't have an authentication mechanism in place for identifying the user.

Podman takes the approach of creating a container as a process fork, rather than using a client/daemon, which preserves the loginuid, but what about across a cluster.

Kubernetes has auditing functionality, but I haven't been able to determine from the documentation whether that applies to processes running in containers, or only to K8s API calls.

It's seems like it would be possible to do this by:

1 - Require a user to authenticate when starting a container.

2 - Send the user name when starting the container on each node.

3 - Preserve the user ID in a process attribute.

For 2, to work, the user would have to be known to each host, and not just the container daemon.

A trivial case of 3, would be for the user in the container to have the same UID, and the authorization stage could enforce that. But that's pretty limiting.

Has anyone managed to address this successfully, or is it still an open issue? Either a global solution, or for a particular containerization technology/orchestrator.

Here are some links regarding proposals for implementing this in the kernel:

Improve this question
6
  • With kubernetes who runs the pod is who runs the pod (operations user) and who does something in the app is who is authenticated to the app in the pod. So I don't get what you are trying to achieve and why it is a problem.
    – simbo1905
    Commented Mar 4, 2019 at 16:30
  • opensource.com/article/18/10/…
    – orodbhen
    Commented Mar 4, 2019 at 19:32
  • Thanks for the link. OKD runs pods with a high uid blog.openshift.com/… and that uid won’t be able to modify the host. The vast majority of businesses running it will he running webapps and will want the pods to be immutable except databases. So in practice for most businesses using kubernetes this isn’t seen as an open issue. Docker demon running as root is seen as a problem in the kubernetes world hence cri-o which this article says will in the future move towards podman blog.openshift.com/crictl-vs-podman
    – simbo1905
    Commented Mar 4, 2019 at 22:42
  • Right, my use case is in development, where I want to be able to allow developers to design and launch their own containers, but still need to maintain an audit trail of who did what. It seems like it may be possible to use access controls to force the user to run under their own UID, but that's ugly and inflexible IMHO. A robust solution would need to come from the kernel. Orchestrators can provide logging facilities, but that won't monitor syscalls. I've added a few links on this wise.
    – orodbhen
    Commented Mar 14, 2019 at 16:26
  • sounds odd that developers create containers and need to be monitored for what system calls they make. normally developers write code and scripts that are used to make containers that are recreated by a build pipeline with full traceability and review. then those clean built containers will be run without any developer access. the intention being to not let developers create anthing that isn't repeatable from source code and auditable in a traditional manner. I think this is why you are looking for a feature that doesn't exist as you are trying to solve a problem other people don't encounter.
    – simbo1905
    Commented Mar 14, 2019 at 18:36

1 Answer 1

Reset to default
1

I think there is a way to do this on docker:

As of Docker 1.10 User Namespaces are supported directly by the docker daemon. This feature allows for the root user in a container to be mapped to a non uid-0 user outside the container, which can help to mitigate the risks of container breakout. This facility is available but not enabled by default.

You can map the root user inside docker container to specific user from the host machine (uid).

Improve this answer
1
  • Unfortunately, user namespaces only supports one user mapping at a time. It looks like you can accomplish it in K8s using runas security policies. This is more elegant, IMHO, and still works in a cluster. You'd also have to restrict access to the container shell, so another user can't just shell in and run a command.
    – orodbhen
    Commented Feb 25, 2019 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.