Answers: <p>I think there is a way to do this on <a href="https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface" rel="nofollow noreferrer">docker</a>:</p>
  
  <blockquote>
    <p>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 <strong>non uid-0</strong> user outside the container, which can help to mitigate the risks of container breakout. This facility is available but not enabled by default.</p>
  </blockquote>
  
  <p>You can map the root user inside docker container to specific user from the host machine (uid).  </p>
  
Answers: CC BY-SA 4.0
Answers: 2019-02-25T19:10:17.027Z
Answers: Unfortunately, user namespaces only supports [one user mapping at a time](https://github.com/moby/moby/issues/34474). It looks like you can accomplish it in K8s using `runas` [security policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-reference).  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.
Answers: orodbhen
Answers: CC BY-SA 4.0
Answers: 2019-02-24T23:30:01.613Z
Answers: 2019-04-15T02:11:11.003Z
Answers: 2019-04-15T02:11:11.003Z
Answers: milki
Body: <p>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. </p>
  
  <p>The problem is essentially this: How to track operations such as Linux system calls back to the user who created the container? </p>
  
  <p>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.</p>
  
  <p>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. </p>
  
  <p>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. </p>
  
  <p>It's seems like it would be possible to do this by:</p>
  
  <p>1 - Require a user to authenticate when starting a container.</p>
  
  <p>2 - Send the user name when starting the container on each node.</p>
  
  <p>3 - Preserve the user ID in a process attribute. </p>
  
  <p>For <code>2</code>, to work, the user would have to be known to each host, and not just the container daemon.</p>
  
  <p>A trivial case of <code>3</code>, 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.  </p>
  
  <p>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. </p>
  
  <p>Here are some links regarding proposals for implementing this in the kernel:</p>
  
  <ul>
  <li><a href="https://lwn.net/Articles/740621/" rel="nofollow noreferrer">https://lwn.net/Articles/740621/</a></li>
  <li><a href="https://lwn.net/Articles/699819/" rel="nofollow noreferrer">https://lwn.net/Articles/699819/</a></li>
  <li><a href="https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html" rel="nofollow noreferrer">https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html</a></li>
  </ul>
  
Comments: CC BY-SA 4.0
Comments: 2019-03-04T16:30:46.793Z
Comments: 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.
Comments: simbo1905
Comments: CC BY-SA 4.0
Comments: 2019-03-04T19:32:02.240Z
Comments: https://opensource.com/article/18/10/podman-more-secure-way-run-containers
Comments: orodbhen
Comments: CC BY-SA 4.0
Comments: 2019-03-04T22:42:18.237Z
Comments: Thanks for the link. OKD runs pods with a high uid https://blog.openshift.com/jupyter-on-openshift-part-6-running-as-an-assigned-user-id/ 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 https://blog.openshift.com/crictl-vs-podman/
Comments: simbo1905
Comments: CC BY-SA 4.0
Comments: 2019-03-14T16:26:12.410Z
Comments: 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.
Comments: orodbhen
Comments: CC BY-SA 4.0
Comments: 2019-03-14T18:36:14.013Z
Comments: 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.
Comments: simbo1905
Comments: CC BY-SA 4.0
Comments: 2019-03-15T12:57:06.967Z
Comments: Fair enough. But I think the links that I posted indicate that people want to do these things. It's unfortunate, but I think it's kind of gone in the direction of making the problem fit the solution, rather than the other way around. A lot of times, people just want to "contain" things, for both their build and runtime environments, without incurring all the unnecessary overhead and latency. That may fit well for web apps, but container technology can be applied to just about any application running on Linux. Thanks for the feedback.
Comments: orodbhen
Tags: <docker><kubernetes><containers><audit>
Title: Process auditing in containers
UserDisplayName: orodbhen
ThreadText: # Process auditing in containers
  
  (Asked by: username_0 on 2019-02-22)
  
  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:
  
  * <https://lwn.net/Articles/740621/>
  * <https://lwn.net/Articles/699819/>
  * <https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html>
  
  **Tags:** docker, kubernetes, containers, audit
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_0**: https://opensource.com/article/18/10/podman-more-secure-way-run-containers  
  > **username_1**: Thanks for the link. OKD runs pods with a high uid https://blog.openshift.com/jupyter-on-openshift-part-6-running-as-an-assigned-user-id/ 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 https://blog.openshift.com/crictl-vs-podman/  
  > **username_0**: 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.  
  > **username_1**: 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.  
  > **username_0**: Fair enough. But I think the links that I posted indicate that people want to do these things. It's unfortunate, but I think it's kind of gone in the direction of making the problem fit the solution, rather than the other way around. A lot of times, people just want to "contain" things, for both their build and runtime environments, without incurring all the unnecessary overhead and latency. That may fit well for web apps, but container technology can be applied to just about any application running on Linux. Thanks for the feedback.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-02-24. Score: 1
  
  I think there is a way to do this on [docker](https://docs.docker.com/engine/security/security/#/docker-daemon-attack-surface):
  
  > 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).
  
  > **Comments:**
  > **username_0**: Unfortunately, user namespaces only supports [one user mapping at a time](https://github.com/moby/moby/issues/34474). It looks like you can accomplish it in K8s using `runas` [security policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#policy-reference).  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.  
  
  ---
  
  