Skip to content
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.

untrusted runtime should support privileged #855

Closed
egernst opened this issue Jul 20, 2018 · 5 comments
Closed

untrusted runtime should support privileged #855

egernst opened this issue Jul 20, 2018 · 5 comments
Labels
kind/feature
Milestone
v1.11

Comments

@egernst
Copy link
Contributor

egernst commented Jul 20, 2018

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
Copy link
Contributor Author

egernst commented Jul 20, 2018

/cc @Random-Liu @jcvenegas

@egernst
Copy link
Contributor Author

egernst commented Jul 20, 2018

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

egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: seperate host accessing workload and privileged
637adb1 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
@egernst egernst mentioned this issue Jul 20, 2018
Merged
egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: separate host accessing workload and privileged
25f0cdf 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: separate host accessing workload and privileged
f4e61b3 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
@Random-Liu
Copy link
Member

@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
Copy link
Contributor Author

egernst commented Jul 20, 2018

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
Copy link
Contributor

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

@Random-Liu Random-Liu added this to the v1.11 milestone Jul 20, 2018
egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: separate host accessing workload and privileged
98ddc99 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: separate host accessing workload and privileged
3ffd8e6 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
egernst pushed a commit to egernst/cri that referenced this issue Jul 20, 2018
sandbox: separate host accessing workload and privileged
a254bb0 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
egernst pushed a commit to egernst/cri that referenced this issue Jul 22, 2018
sandbox: separate host accessing workload and privileged
cd81cce 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
egernst pushed a commit to egernst/cri that referenced this issue Jul 22, 2018
sandbox: separate host accessing workload and privileged
9a01272 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Random-Liu pushed a commit to Random-Liu/cri-containerd that referenced this issue Jul 26, 2018
@Random-Liu
sandbox: separate host accessing workload and privileged
c037404 
VM isolated runtimes can support privileged workloads. In this
scenario, access to the guest VM is provided instead of the host.
Based on this, allow untrusted runtimes to run privileged workloads.

If the workload is specifically asking for node PID/IPC/network, etc.,
then continue to require the trusted runtime.

This commit repurposes the hostPrivilegedSandbox utility function to
only check for node namespace checking.

Fixes: containerd#855

Signed-off-by: Eric Ernst <eric.ernst@intel.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
kind/feature
Projects
None yet
Milestone
v1.11
Development

No branches or pull requests
3 participants
@Random-Liu @egernst @tallclair