The ability to handle KVM based runtimes with SELinux has been added as
part of d715d00906.
However, that commit introduced some logic to check whether the
"container_kvm_t" label would or not be present in the system, and while
the intentions were good, there's two major issues with the approach:
1. Inspecting "/etc/selinux/targeted/contexts/customizable_types" is not
the way to go, as it doesn't list the "container_kvm_t" at all.
2. There's no need to check for the label, as if the label is invalid an
"Invalid Label" error will be returned and that's it.
With those two in mind, let's simplify the logic behind setting the
"container_kvm_t" label, removing all the unnecessary code.
Here's an output of VMM process running, considering:
* The state before this patch:
```
$ containerd --version
containerd github.com/containerd/containerd v1.6.0-beta.3-88-g7fa44fc98 7fa44fc98f
$ kubectl apply -f ~/simple-pod.yaml
pod/nginx created
$ ps -auxZ | grep cloud-hypervisor
system_u:system_r:container_runtime_t:s0 root 609717 4.0 0.5 2987512 83588 ? Sl 08:32 0:00 /usr/bin/cloud-hypervisor --api-socket /run/vc/vm/be9d5cbabf440510d58d89fc8a8e77c27e96ddc99709ecaf5ab94c6b6b0d4c89/clh-api.sock
```
* The state after this patch:
```
$ containerd --version
containerd github.com/containerd/containerd v1.6.0-beta.3-89-ga5f2113c9 a5f2113c9fc15b19b2c364caaedb99c22de4eb32
$ kubectl apply -f ~/simple-pod.yaml
pod/nginx created
$ ps -auxZ | grep cloud-hypervisor
system_u:system_r:container_kvm_t:s0:c638,c999 root 614842 14.0 0.5 2987512 83228 ? Sl 08:40 0:00 /usr/bin/cloud-hypervisor --api-socket /run/vc/vm/f8ff838afdbe0a546f6995fe9b08e0956d0d0cdfe749705d7ce4618695baa68c/clh-api.sock
```
Note, the tests were performed using the following configuration snippet:
```
[plugins]
[plugins.cri]
enable_selinux = true
[plugins.cri.containerd]
[plugins.cri.containerd.runtimes]
[plugins.cri.containerd.runtimes.kata]
runtime_type = "io.containerd.kata.v2"
privileged_without_host_devices = true
```
And using the following pod yaml:
```
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
runtimeClassName: kata
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
```
Fixes: #6371
Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
Skip this test until this error can be evaluated and the appropriate
test fix or environment configuration can be determined.
Signed-off-by: Derek McGowan <derek@mcg.dev>
The OCI image spec did a v1.0.2 security release for CVE-2021-41190, however
commit 09c9270fee, depends on MediaTypes that
have not yet been released by the OCI image-spec, so using current "main" instead.
full diff: 5ad6f50d62...693428a734
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
As like other integration tests, Windows integration tests should not
fail-fast. So developers can see whether an issue is platform-specific
or not.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
I noticed we were using some different versions of the same test
images, so changing them to be the same (can help with find/replace
if we need to update them).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It seems that the default ACLs inherited from the parent folder
on Windows Server 2022, does not include "CREATOR OWNER" as it
does on Windows Server 2019. This sets explicit ACLs on test
files.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
GA for ws2022 github actions VMs launched a couple weeks ago so seems like
it's time to try out the CI on this new SKU.
This involved adding new ws2022 runs for the OS matrices in the CI, fixing up
a test in the platforms package and adding a mapping for the ws2022 container image in
integration/client.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
With the ghcr images now built and working, switch over to
use these new images and update the default name.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Limit the scope of GITHUB_TOKEN to only have write access to packages
and read access to metadata. By default it seems to be granted access
equal to that of the github.actor that triggered the workflow, which
may include access to more than the workflow needs.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
This will help to reduce the amount of runc/libcontainer code that's used in
Moby / Docker Engine (in favor of using the containerd implementation).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
