International Business Machines Corporation

Harshal S Patil

Christoph Raisch

Kishorekumar G Pillai

Alol Antony Crasta

Nishant Ranjan

Pradipta Kumar Banerjee

Manjunath Kumatagi

Pooja Kulkarni

Nitesh Konkar

Hemant K Shaw

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.

Hardware memory encryption and protection for containers

Described are techniques for secure workload configuration including a method comprising receiving a workload definition file at a worker node and from a master node, where the workload definition file comprises an encrypted immutable definition, a partially immutable definition with a predefined range of values and a first value modified by the master node, and a variable definition with a second value modified by the master node. The method further comprises decrypting, by the worker node, the encrypted immutable definition to generate a decrypted immutable definition. The method further comprises verifying, by the worker node, that the first value satisfies the predefined range of values. The method further comprises, in response to decrypting the encrypted immutable definition and verifying that the first value satisfies the predefined range of values, executing a workload based on the workload definition file in a virtual computing environment.

Secure workload configuration

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&#x2014;checkpoint/restore in userspace.

Dynamically changing containerized workload isolation in response to detection of a triggering factor

A method, computer program product, and system includes a processor(s) connecting a first computer system to a boot swarm, initiating formation of a peer to peer network. The processor(s) receive a request from a second computer system, a request for a file. The processor(s) configure the second computer system, including implementing a client application hosted from a resource in the first computer system, to facilitate the second computer system joining the peer to peer network. The processor(s) determine immediate peer(s) in the peer to peer network available to provide the file to the second computer system. The processor(s) generate a magnet link that includes a listing of address(es) of the immediate peer(s), ranking address(es) from best source to worst source for downloading the file. The processor(s) provide the second computer system with the magnet link to utilize in downloading the file from a peer.

Network booting in a peer-to-peer environment using dynamic magnet links

A computer system includes a first server including a first data management module and a second server including a second data management module, and a first and second storage controller. The first and second storage controllers are interconnected by a network configured for reliable data multicasting. The computer system further includes a cross system manager for controlling one or more core storage functions on each of the first and second storage controllers. The computer system further includes computer program instructions to, responsive to a core storage function triggered by the cross system manager: Create a multicast group for each of the first server and the second server in the network, wherein the multicast group is created by a reliable multicast mechanism, and Multicast data write operations of each of the first server and the second server to the first storage controller and the second storage controller of the multicast group.

Updating data objects on a system

A blockchain of transactions may be used for various purposes and may be later accessed by interested parties for ledger verification. One example method of operation may include one or more of monitoring one or more applications to identify application events, identifying one or more application events, determining a hash of a log message payload associated with the application events and logging the hash of the log message payload in a blockchain.

Distributed logging of application events in a blockchain

Aspects include creating a network multicast group in a storage area network (SAN) for a first computer system and a second computer system that are connected by the SAN and that each include a local cache for a shared storage device. Prior to one of the first or second computer system writing write data to the shared storage device: the write data is written to the local cache of the one of the first or second computer system; the write data is sent to the multicast group; based on the send operation completing, the write data is written to the shared storage device; and based on the write operation completing, the write completion is signaled to an operating system or hypervisor of the first and second computer systems.

Growing community of inventors

Bengaluru, India

Harshal S Patil