github/kata-containers
1
0
Fork 2
mirror of https://github.com/kata-containers/kata-containers.git synced 2025-10-22 12:29:49 +00:00
Code Issues Projects Releases Wiki Activity

docs: Document privileged_without_host_devices=false as unsupported

Browse Source 
Document that privileged containers with
privileged_without_host_devices=false are not generally supported.

When you try the above, the runtime will pass all the host devices to Kata
in the OCI spec, and Kata will fail to create the container for various
reasons depending on the setup, e.g.:

 - Attempting to hotplug uninitialized loop devices.
 - Attempting to remount /dev devices on themselves when the agent had
   already created them as default devices (e.g. /dev/full).
 - "Conflicting device updates" errors.
 - And more...

privileged_without_host_devices was originally created to support
Kata [1][2] and lots of people are having issues when it's set to
false [3].

[1] https://github.com/kata-containers/runtime/issues/1568
[2] https://github.com/containerd/cri/pull/1225
[3] https://github.com/kata-containers/kata-containers/issues?q=is%3Aissue%20%20in%3Atitle%20privileged

Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
This commit is contained in:
Aurélien Bombo
2025-10-01 16:40:32 -05:00
parent 285aaad13e
commit 6ff78373cf
2 changed files with 18 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/Limitations.md
View File

@@ -171,14 +171,12 @@ See [this issue](https://github.com/kata-containers/runtime/issues/2812) for mor
### Privileged containers ### Privileged containers
Privileged support in Kata is essentially different from `runc` containers. Privileged support in Kata is essentially different from `runc` containers.
The container runs with elevated capabilities within the guest and is granted The container runs with elevated capabilities within the guest.
access to guest devices instead of the host devices.
This is also true with using `securityContext privileged=true` with Kubernetes. This is also true with using `securityContext privileged=true` with Kubernetes.
The container may also be granted full access to a subset of host devices Importantly, the default behavior to pass the host devices to a
(https://github.com/kata-containers/runtime/issues/1568). privileged container is not supported in Kata Containers and needs to be
disabled, see [Privileged Kata Containers](how-to/privileged.md).
See [Privileged Kata Containers](how-to/privileged.md) for how to configure some of this behavior.
# Appendices # Appendices

25
docs/how-to/privileged.md
View File

@@ -1,22 +1,25 @@
# Privileged Kata Containers # Privileged Kata Containers
> [!WARNING]
> Whilst this functionality is supported, it can decrease the security of Kata Containers if not configured correctly.
Kata Containers supports creation of containers that are "privileged" (i.e. have additional capabilities and access Kata Containers supports creation of containers that are "privileged" (i.e. have additional capabilities and access
that is not normally granted). that is not normally granted).
## Warnings ## Enabling privileged containers without host devices
**Warning:** Whilst this functionality is supported, it can decrease the security of Kata Containers if not configured > [!TIP]
correctly. > When Kata Containers is installed through
> [kata-deploy](/tools/packaging/kata-deploy/helm-chart/README.md#kata-deploy-helm-chart), this mitigation is configured
> out of the box, hence there is no action required in that case.
### Host Devices By default, a privileged container attempts to expose all devices from the host. This is generally not supported in Kata
Containers as the container is running a different kernel than the host.
By default, when privileged is enabled for a container, all the `/dev/*` block devices from the host are mounted Instead, the following sections document how to disable this behavior in different container runtimes. Note that this
into the guest. This will allow the privileged container inside the Kata guest to gain access to mount any block device mitigation does not affect a container's ability to mount *guest* devices.
from the host, a potentially undesirable side-effect that decreases the security of Kata.
The following sections document how to configure this behavior in different container runtimes. ## Containerd
#### Containerd
The Containerd allows configuring the privileged host devices behavior for each runtime in the containerd config. This is The Containerd allows configuring the privileged host devices behavior for each runtime in the containerd config. This is
done with the `privileged_without_host_devices` option. Setting this to `true` will disable hot plugging of the host done with the `privileged_without_host_devices` option. Setting this to `true` will disable hot plugging of the host
@@ -43,7 +46,7 @@ See below example config:
- [How to use Kata Containers and containerd with Kubernetes](how-to-use-k8s-with-containerd-and-kata.md) - [How to use Kata Containers and containerd with Kubernetes](how-to-use-k8s-with-containerd-and-kata.md)
- [Containerd CRI config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) - [Containerd CRI config documentation](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
#### CRI-O ## CRI-O
Similar to containerd, CRI-O allows configuring the privileged host devices Similar to containerd, CRI-O allows configuring the privileged host devices
behavior for each runtime in the CRI config. This is done with the behavior for each runtime in the CRI config. This is done with the