By default the SecurityContext for Container activation can contain a Username
UID, GID. The order of precedences is username, UID, GID. If none of these
options are specified as a last resort attempt to set the ImageSpec username.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
Only compose full container log path if neither of the paths is empty. Otherwise container won't start properly.
Signed-off-by: Cong Liu <conliu@google.com>
This bumps the containerd and sys packages in CRI
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Remove runtime-tools
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Update tests for oci opts package
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Because RunPodSandbox and CreateContainer will access metadata
without check, pod or container config file without metadata will
crash containerd.
This patch add checks to handle the issue.
Fixes: #1009
Signed-off-by: Hui Zhu <teawater@hyper.sh>
To match expectations of users coming from Docker engine runtime, add
the HOSTNAME to the environment of new containers in a pod.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
Also add new dependencies on github.com/xeipuuv/gojson* (brought up by
new runtime-tools) and adapt the containerd/cri code to replace the APIs
that were removed by runtime-tools.
In particular, add new helpers to handle the capabilities, since
runtime-tools now split them into separate sets of functions for each
capability set.
Replace g.Spec() with g.Config since g.Spec() has been deprecated in the
runtime-tools API.
Signed-off-by: Filipe Brandenburger <filbranden@google.com>
Some CRI compatible runtimes may not support provileged operations.
Specifically hypervisor based runtimes (like kata-containers, cc-runtime
and runv) do not support privileged operations like:
- Provide access to the host namespaces
- Create fully privileged containers with access to host devices
Hypervisor based runtimes create container workloads within virtual machines.
When a running host privileged containers using them,
they wont provide support to requested the privileged opertations.
This commits add the new options to define two runtimes:
Trusted runtime : Used when a privileged container is requested.
Default runtime : for non-privileged workloads.
A container that belongs to a privileged pod will inherent this property
an will be created with the trusted runtime.
- Add options to define trusted runtime
- Add logic to decide if a sanbox is trusted
- Export annotation containers below to a trusted sandbox
Signed-off-by: Jose Carlos Venegas Munoz <jose.carlos.venegas.munoz@intel.com>
