Abstract: In an approach for securing container workloads, a processor encrypts workload binaries. A processor uploads the workload binaries to a software repository. A processor encrypts a workload definition. A processor replaces the workload definition with a mock workload definition. A processor references the encrypted workload definition in the mock workload definition. A processor submits the mock workload definition to a master node.

Abstract: Method, apparatus, and computer program product are provided for dynamically changing containerized workload isolation in response to detection of a triggering factor. In some embodiments, workload is containerized using a default container runtime (e.g., runC) that spawns one or more cgroup-based containers on a compute node using resource limiting capabilities of the compute node's host kernel including cgroups and namespaces. In some embodiments, in response to a triggering factor, such as a host kernel vulnerability, at least some of the containerized workload is migrated from running in the one or more cgroup-based containers to one or more virtual machines (VMs) launched by a standby container runtime (e.g., runV). In some embodiments, the cgroups and namespaces of the one or more cgroup-based containers are live migrated, without service interruption, to one or more VM runtimes on the one or more VMs using CRIU—checkpoint/restore in userspace.

Abstract: In an approach for securing container workloads, a processor encrypts workload binaries. A processor uploads the workload binaries to a software repository. A processor encrypts a workload definition. A processor replaces the workload definition with a mock workload definition. A processor references the encrypted workload definition in the mock workload definition. A processor submits the mock workload definition to a master node.

Abstract: Method, apparatus, and computer program product are provided for dynamically changing containerized workload isolation in response to detection of a triggering factor. In some embodiments, workload is containerized using a default container runtime (e.g., runC) that spawns one or more cgroup-based containers on a compute node using resource limiting capabilities of the compute node's host kernel including cgroups and namespaces. In some embodiments, in response to a triggering factor, such as a host kernel vulnerability, at least some of the containerized workload is migrated from running in the one or more cgroup-based containers to one or more virtual machines (VMs) launched by a standby container runtime (e.g., runV). In some embodiments, the cgroups and namespaces of the one or more cgroup-based containers are live migrated, without service interruption, to one or more VM runtimes on the one or more VMs using CRIU—checkpoint/restore in userspace.