You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Related to #270 , it would be extremely convenient to be able to use a Kubernetes native driver to run both image content tests (the currently supported test types using --driver tar) as well as command tests that could run as pods against an image-under-test.
This is an oversimplification but at a HL, a new driver of type kubernetes is created which can use an existing user's KUBECONFIG context and executes kubectl run cst-pod-randomid --image=image-under-test --command -- <cmd> <args...> for each command test indicated. Instead of inspecting the Docker/containerd socket for completion status, verify pod status, exit code, etc.
There are some obvious edge cases such as running pods in a secure environment (gVisor, Openshift, clusters with PodSecurityContext, etc) that may prevent this outright. But I'd still like to entertain the idea for those in shared environments that may not have access to a Docker/containerd host directly.
The text was updated successfully, but these errors were encountered:
Related to #270 , it would be extremely convenient to be able to use a Kubernetes native driver to run both image content tests (the currently supported test types using
--driver tar
) as well as command tests that could run as pods against an image-under-test.This is an oversimplification but at a HL, a new driver of type
kubernetes
is created which can use an existing user's KUBECONFIG context and executeskubectl run cst-pod-randomid --image=image-under-test --command -- <cmd> <args...>
for each command test indicated. Instead of inspecting the Docker/containerd socket for completion status, verify pod status, exit code, etc.There are some obvious edge cases such as running pods in a secure environment (gVisor, Openshift, clusters with PodSecurityContext, etc) that may prevent this outright. But I'd still like to entertain the idea for those in shared environments that may not have access to a Docker/containerd host directly.
The text was updated successfully, but these errors were encountered: