Security-based container scheduling

#Software containers have emerged to address the increasing portability needs of software applications. A container bundles an application and all its dependencies and libraries into an isolated, resource controlled and easy-to-deploy building block that can run on any operating system in any computing environment. Containers can be deployed on either physical or virtual machines in private, public or hybrid clouds, thereby facilitating workload management of large scale applications. Multiple containers can run on a single machine and share the operating system kernel, while keeping processes and resources such as memory, CPU and disks isolated from each other. This makes container deployment efficient, fast and lightweight.

#There are several popular container development and management systems available, such as for example. Docker, Rocket and Kubernetes. These systems include tools for creating and running container images, which are the files that make up the applications that run inside a container. Image files contain all the requirements for running a single container, as well as metadata delineating information and attributes associated with the container.

#System administrators can use container orchestration engines to manage and schedule the allocation and deployment of containers to a server or cluster of servers. Container orchestration engines such as Kubernetes and Docker Swarm provide basic scheduling capabilities, focusing mainly on CPU, memory and storage requirements. Poor management and scheduling of containers can lead to an inefficient utilization of underlying resources and a mismatch between workloads and resources.

#The present application may be more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:

#FIG. 1 illustrates a schematic diagram of an environment where a security-based container scheduling system is used in accordance with various examples;

#FIG. 2 is a block diagram of an example security-based container scheduling system which may be incorporated into the environment of FIG. 1;

#A security-based container scheduling system for scheduling a software container to a node is disclosed. The security-based container scheduling system automates container scheduling while taking into account security requirements of the container's workload. Each container is allocated to a node with security attributes that match the security requirements of the container's workload, thereby ensuring that security is automatically integrated upfront and maintained throughout container development and deployment. Maintaining security is critical for many container workloads, such as those that deal with sensitive data or those that are deployed in a multi-tenant cloud environment.

#As generally described herein, a node refers to a computing device on a network, either a virtual or physical machine, such as a personal computer, a cell phone, a printer, or a server, among others. Security attributes associated with a node may include, for example, whether secure boot or a Federal Information Processing Standard (“FIPS”) mode is enabled, whether the node has Trusted Platform Module (“TPM”) hardware, whether the node has a specific firmware version that contains hot security fixes, or any other security attribute that may be associated with a node. Each node may have metadata associated with it, which may be in the form of labels or annotations specifying different attributes (e.g., security attributes) related to the node. Likewise, a container image may have metadata specifying different requirements and attributes associated with the container image. An example security attribute associated with a container image may be that the container image is required to run on a node with a specific version x of Secure Sockets Layer (“SSL”).

#In various examples, the security-based container scheduling system is implemented with a discovery engine and a translation engine. The discovery engine discovers a node and its node security attributes automatically. The translation engine enables container security attributes identified in container image's metadata to be converted into node selectors for templates or passed as parameters in Command Line Interfaces (“CLIs”) or Application Program interfaces (“APIs”) used in container creation. In the SSL example above, a node selector specifying “SSL_version=x” may be added to a container creation template or passed as a parameter in a container creation CLI/API. A container scheduler scans metadata associated with nodes, such as for example, nodes that are part of a cluster of nodes, to select a node that has node security attributes listed in its metadata that match the node selectors in the container's creation template or CLI/API. The container is then allocated to the selected node to ensure that its security requirements are maintained throughout its deployment.