Kata does not support hostpid

[amshinde]

Kubernetes provides ability for a pod to share host Pid namespace:
https://kubernetes.io/docs/concepts/policy/pod-security-policy/#host-namespaces

Like so:

apiVersion: v1
kind: Pod
metadata:
  name: view-pid
  namespace: default
spec:
  hostPID: true
  containers:
    - name: container-view-pid
      image: alpine
      command:
        - sleep
        - "3600"

In Kata, we cannot really share the host Pid namespace due to VM boundary. We could potentially translate this to sharing the pid namespace of the agent.
I am not too inclined for doing this, as this potentially opens up the agent processes. We may just choose not to implement this as list this as a limitation.

[amshinde]

cc @bergwolf @gnawux @egernst @jodh-intel
Let me know what you think about this.

The way namespaces are handled in the runtime and agent, this option results in a behaviour silimar to sharePid namespace where all the containers share the Pid namspace of the pause container.

[jodh-intel]

Hi @amshinde - I don't like the idea of sharing the agent namespace:

• for security reaons as you mention.
• because the agent PID namespace isn't the host PID namespace anyway :)

I think we should just add this to the limitations document and if someone comes up with a very compelling use-case, we could then consider it. Exposing so much of the host environment to the container does beg the question, "Why not just run $thing on the host?"

[c3d]

I agree with @jodh-intel

If you want to really expose the host PID, then you probably also need to "fake" /proc and quite a few other things, and it gets really messy really fast.

If you don't expose the host PID but something else (e.g. guest / agent PID namespace), then whatever bizarre contraption expected the host PID will probably faceplant.

What are the actual use cases? I could imagine a few contorted ones (host instrumentation from within a container, that kind of things), or things like a DaemonSet that would monitor some host process. Without a good understanding of the use cases, it would be hard to implement anything sensible.

[amshinde]

@jodh-intel @c3d
We have a use case where a user wants to run auditd in a sidecar container in a pod. To be able to do this, the sidecar container needs to have access to the agent namespace.
This could potentially be achieved by supporting a flavor of hostpid that allows a container access to the agent namespace.
Today in Kata, we support a notion of privileged that is specific to the VM, I think we could do the same for hostPid.

[Xiaohua-Shen]

@jodh-intel @c3d @amshinde
We have a similar requirement of running auditd in a privileged sidecar container to monitor what was executed in the kata container too.
usually we used sysdig for container monitoring, but that doesn't work for kata container.
if auditd sidecar can access agent namespace, then we can use auditd to do the monitor.

[jodh-intel]

@amshinde has now raised kata-containers/agent#788. If we do this, I think that:

• The feature should be disabled by default:
  • Kata should continue to be as secure as possible by default.
  • Most users won't need this.
  • It's intrusive and has security implications.
• We should create a "well-known" log message so that it's clear to anyone reading the logs that this feature is enabled.
• If the agent was started with the feature disabled, any request to use this feature should be denied (with a clear log message explaining why).

[amshinde]

@jodh-intel @bergwolf I have raised #2723 and kata-containers/agent#788 in the runtime and agent repos respectively to address this issue. Please take a look and let me know what you think.

• The feature should be disabled by default:

  • Kata should continue to be as secure as possible by default.
  • Most users won't need this.
  • It's intrusive and has security implications.

• We should create a "well-known" log message so that it's clear to anyone reading the logs that this feature is enabled.

• If the agent was started with the feature disabled, any request to use this feature should be denied (with a clear log message explaining why).

I have addressed all of these in the runtime PR.

cc @wenlxie. I know you were interested in the use case as well to run audit containers with pid namespace as the agent. I have come up with this initial implementation.
During our discussions with the community, @bergwolf mentioned if we could make the audit container work with it running in its own namespace. Can you provide a summary of how you are using the audit sidecar (possibly providing an example yaml) and why it was necessary to run it in the agent pid namespace.