untrusted runtime should support privileged

[egernst]

Being able to run an untrusted runtime, such as kata-runtime, as privileged should be allowed. In this case, all device nodes, etc, would be made available to it. Note, none of the host available features would be available.

If a workload explicitly is marked as untrusted but has --privileged, allow the configuration.

I still think we should return an error if they are asking for namespaces of the host (the node).

This should address the TODO @ [1] in the short term while we wait for runtimeClass to be implemented.

[1] https://github.com/containerd/cri/blob/master/pkg/server/sandbox_run.go#L610

[egernst]

/cc @Random-Liu @jcvenegas

[egernst]

I'll put together a PR accordingly. Want to follow similar logic as to what is introduced with cri-o/cri-o#1701

[Random-Liu]

@egernst Current integration is experimental.

@tallclair is working on the RuntimeClass. kubernetes/enhancements#585 And that will define what features will be supported by a runtime, which includes privileged. I prefer we make the behavior consistent with that.

@tallclair Do you think we should support privileged for sandbox container?

[egernst]

Sounds good @Random-Liu. I expect this to become more clear once runtime class is supported. In the meantime there are many use cases where having privileged support in the sandboxed runtime (ie, kata in my scenario) makes sense (device node access, update the guest kernel, etc).

I didn't want to wait until 1.12 to start using these patterns.

[tallclair]

I don't think we should block this on RuntimeClass. I don't see any reason to forbid privileged (or equivalently, elevated capabilities) in the sandboxed runtimes. The sandbox implementation (kata-containers) should correctly handle this to avoid privilege escalations in most cases.

Note that this does weaken the sandbox, as the guest OS is no longer an extra security layer, but I think the tradeoff is worthwhile for the enhanced useability, and can also be prevented through policy (PodSecruityPolicy).

See also https://docs.google.com/document/d/1WzO_QjJFfedhsiBtfcVB2QzTWRXHEPX1xOyqDGXxO-0/edit#bookmark=id.rjvemjh24lw9