Container-based system administration

Methods, computing systems and computer program products implement embodiments of the present invention that include defining a first multiple of software container configurations and a second multiple of permission sets, and receiving, by a first computer, a request to perform a service operation on a second computer having multiple resources. Upon identifying one or more of the resources that are required for the service operation, a given software container configuration and a given permission set are selected based on the identified one or more resources, and the given software container configuration and the given permission set are conveyed to the second computer. Upon the second computer receiving the given software container configuration and the given permission set, a software container is generated. The software container is opened on the host computer prior to performing the service operation, and closed upon completing the service operation.

FIELD OF THE INVENTION

This invention relates generally to system administration, and specifically to constraining and controlling system administration via software container encapsulation.

BACKGROUND

Operating system virtualization technologies include hypervisors that implement virtual machines and software containers that provide “thin” layers of abstraction and automation of operating-system-level virtualization. Although virtual machines implement hardware-level virtualization that provide great encapsulation, their overhead makes them too costly for system administration, and their high level of isolation makes resource sharing more difficult. On the other hand, software containers enable controlled access of the host operating system and do not require a hypervisor. Containers are lightweight and provide better performance, thereby enabling faster provisioning for efficient system management.

SUMMARY

There is provided, in accordance with an embodiment of the present invention a method, including defining a first multiple of software container configurations and a second multiple of permission sets, receiving, by a first computer, a request to perform a service operation on a second computer having multiple resources, identifying one or more of the resources that are required for the service operation, selecting, based on the identified one or more resources, a given software container configuration and a given permission set, and conveying the given software container configuration and the given permission set to the second computer.

There is also provided, in accordance with an embodiment of the present invention a computing facility, including multiple computers configured to communicate over a network, wherein a first given computer is configured to define a first multiple of software container configurations and a second number of permission sets, to receive a request to perform a service operation on a second given computer having multiple resources, to identify one or more of the resources that are required for the service operation, to select, based on the identified one or more resources, a given software container configuration and a given permission set, and to convey the given software container configuration and the given permission set to the second given computer.

There is further provided, in accordance with an embodiment of the present invention a computer program product, the computer program product a non-transitory computer readable storage medium having computer readable program code embodied therewith, the computer readable program code executing on a first computer and including, computer readable program code configured to define a first multiple of software container configurations and a second multiple of permission sets, computer readable program code configured to receive a request to perform a service operation on a second computer having multiple resources, computer readable program code configured to identify one or more of the resources that are required for the service operation, computer readable program code configured to select, based on the identified one or more resources, a given software container configuration and a given permission set, and computer readable program code configured to convey the given software container configuration and the given permission set to the second computer.

DETAILED DESCRIPTION OF EMBODIMENTS

System administrators are typically granted a set of permission levels that enable them to fully control and modify a running system. By default, a full set of permissions is typically granted to system administrators in order to perform service operations. However, the full set of permissions is rarely required to perform a given service operation, and consequently, rogue system administrators can utilize the permissions to steal sensitive user data that can be protected without impacting the service operation.

With the proliferation of cloud computing, entrusting a system administrator with an appropriate set of permissions becomes even more critical, since cloud customers need to trust a system administrator that may not be part of their organization. In some instances, the administrator may be employed by a competing company.

Embodiments of the present invention provide methods and systems for providing a lightweight and scalable administration platform that allows cloud provider environments to both monitor and restrict system administrator privileges and actions in order to avoid data leakages and other security breaches. As described hereinbelow, a first multiple of software container configurations and a second multiple of permission sets are defined, and upon receiving, by a help desk computer, a request to perform a service operation on a host computer, one or more resources on the host computer that are required for the service operation are identified.

The resources comprise hardware modules such as storage devices and software modules such as file systems. For example, if the service operation comprises configuring the host computer to access a table on a database server, the resources may comprise database client software (that enables the host computer to communicate with the database server), and permission to access the table.

The help desk computer can select, based on the identified one or more resources, a given software container configuration and a given permission set, and convey the given software container configuration and the given permission set to the host computer. Upon receiving the given software container configuration and the given permission set, the host computer can generate, using the given software container configuration and the given permission set, a software container, and start executing the generated software container, thereby enabling a system administrator to perform the service operation. In some embodiments, the container can be opened upon receiving a login command from the system administrator, and the container can be closed upon receiving a logout command from the system administrator.

By utilizing software container technology, embodiments of the present invention can restrict a system administrator to a limited view of the host's operating system and system services that is sufficient for handling an administrative task. In some embodiments, a set of containers which correspond to specific administrative tasks can be preconfigured in order to limit the power of the system administrator, while at the same time providing enough capabilities to accomplish specific tasks.

In additional embodiments, every action made by the system administrator can be monitored and logged. Examples of system administrator actions (also referred to herein as events) include, but are not limited to, file system interactions, networking requests and data movement, and service control (launch, stop, etc.). Additionally, some dynamic prevention actions may be taken based on on-line monitoring analysis (e.g., container blocking if an attack was discovered). Therefore systems implementing embodiments of the present invention can avoid data leakages and other security breaches (including cloud security exposure) by (a) controlling and limiting a set of capabilities given to the system administrator, and (b) recording all the system administrator's actions, which enables detection and containment of security infringements.

FIG. 1is a block diagram that schematically illustrates a computing facility20configured to perform container-based system administration, in accordance with an embodiment of the present invention. Computing facility20comprises a help desk computer22(also referred to as a first computer), a host computer22(also referred to herein as a second computer) and a monitoring computer24(also referred to herein as a third computer) that communicate via a local area network (LAN)28.

First computer22comprises a first processor30and a first memory32. In operation, processor30executes, from memory32, a ticket handler application34that generates service tickets (not shown) for host computer24. While the configuration inFIG. 1shows a single host computer24, facility20may comprise multiple host computers24, and application34can be configured to generate a given service ticket for any given host computer24.

Second computer24comprises a second processor38that executes an operating system40from a second memory42. In a first non-virtualized embodiment, processor38receives, from computer22, a given container configuration50and a given permission set51, and uses the received container information and the received permission set to generate software container36. A second virtualized environment is described in the description referencingFIG. 2hereinbelow.

In embodiments of the present invention, processor30can store, in memory32, a container configuration list48comprising multiple preconfigured container configurations50, each of the preconfigured container configurations corresponding to a specific administrative task, and providing, to a system administrator, access to a subset of the resources on host computer24. A given container configuration50may comprise a software application that is needed to perform the service operation (e.g., an updated version of database client software), and may also indicate one or more branches of a file system that need to be accessed while performing the service operation.

Processor30also stores, in memory32, permission set list49comprising multiple preconfigured permission sets51, each of the preconfigured permission sets corresponding to a specific administrative task, and providing, to a system administrator, permissions to a subset of the resources on host computer24.

In embodiments of the present invention, upon receiving a given container configuration50and a given permission set51, processor38generates (e.g., by executing container management software such as Docker™) a container36, thereby enabling a system administrator to perform a required service operation. While executing container36(i.e., during the service operation), processor38may execute one or more software processes. For example, while being serviced, processor38may execute, within container36, a spreadsheet application, a web browser, and a database application.

Third computer26comprises a third processor54and a third memory56that stores an event log58comprising multiple events60. When processor38executes container36while host computer24is being serviced, the second processor can convey, to event log58, all “events” that a system administrator performs during the service operation. Examples of events60include, but are not limited to, keyboard input and file operations.

While the configuration inFIG. 1shows event log58managed by processor54, and stored on computer26, the event log can be managed by any of the processors and stored on any of the computers in facility20, not including the host computer being serviced. For security purposes, computer26is typically not collocated with any host computer24, thereby preventing system administrators performing service operations from accessing and modifying log58.

When managing event log58, processor54can trace and audit all actions taken by the system administrator during the process of resolving the ticket. The information can be easily collected by a service (such as Guardium™) that will allow a cloud provider to meet current and future regulations regarding its IT personnel.

To generating container36, application34can augment the ticket creation phase with a feature extraction process that generates a ticket profile comprising features such as:Operating-System-Type (e.g., Linux™, and Windows™)Ticket-Class (e.g., “access”, “installation issue” and “performance”).Ticket-Area (e.g., “network”, “storage”, “GPU” and “multi-tier application”).Ticket-Locality-Type (e.g., single or multiple hosts).Service-Type (e.g., “DNS”, “Swift™”, “Keystone™” and “Guardium™”).

In operation, application34can utilize the extracted features to choose container configurations50that should both be suitable for handling the issue described in the ticket and also near minimal in term of granted capabilities. To generate container configurations50, application34can:Denote a ticket with Ti.For each Ti, extract a set of K[Ti] features:F={f1, f2, . . . , fK[Ti]}.For each set F obtain a potential container configuration set:I={Im1, Im2, . . . , Imn}.calculate a placement map. For example, for each container configuration to be deployed, associate a set of machines that will host the container:∀ImjεI, Hj={hj,1, hj,2, . . . , hj,1j}

Upon calculating the map, application34can automatically deploy the container configurations and update the ticket with the set of container credentials that will be used by the system administrator to connect to the container configurations for resolving the ticket. Additionally, once the ticket is resolved by the system administrator application34can automatically revokes all tokens and removes the containers from their associated host computer(s).

When configuring container configurations50, ticket handler application34can use the following mechanisms to enable fine-grained control over system administrator activities:Administrative tool-set deployment and management. A system administrator may expect a set of tools to exist in a standard server installation. In some embodiments, ticket handler application34can create layered container configurations50in order to provide a “tuned” container36for a specific ticket. In other words, host computer24may comprise a set of resources, and each container configuration50has access to a respective subset of the resources. Additionally, ticket handler application34can allow for additional installations via a dedicated repository.File system overlays. Ticket handler application34can define a set of files that are visible from within a given container configuration50(and their associated permissions).Process control. In order to be able to administer host computer24(or virtual machine46), ticket handler application34can enable container36to control a subset of processes running at its containing host computer (for example, using Linux™ DBus to interact with the system administrator), or a virtual machine within the host computer. This can be more secure that granting a system administrator full root services on host computer24, as the ticket handler application can control and audit interaction with the host computer.Ticket handler application34can utilize IPC and network isolation in order to limit connectivity of administrative containers to the minimum set, thereby preventing a system administrator from connecting to an arbitrary computer at an arbitrary time.Ticket handler application34can constrain, within container36, resource availability to the system administrator via mechanisms such as ‘cgroups’. This mechanism enables ticket handler application34to control any overhead incurred by administrative containers running on a specific host24.Device access control. Unless physical device access is required, ticket handler application34can define device access rights.Tapping, Masquerading and Omission. Embodiments of the present invention enable injection of runtime logic directly into the data path. Specifically, by monitoring network packets, file system data access and command line interaction embodiments of the present invention can identify security threats originating from administrators.

The following comprise sample uses for the proposed monitoring logic:Detecting a download multimedia content (e.g. *.jpg, *.mp4, etc.) over network28, thereby enabling facility20to monitor the actions of a rogue administrator trying to download sensitive data from a remote server and to block them immediately upon breach discovery.Detecting sensitive data that is “masqueraded”. For example, an administrator my attempt to view a file containing credit card numbers will only see “****-*******-****” instead of the real numbers. This may be used, for instance, when the administrator is given permissions to read the file (for instance in order to check that it can indeed be read) while on the other hand preventing him/her from accessing the actual sensitive data of the file.By tracking command line history, facility20can audit reports of administrator's actions, e.g., an input to host computer24that will enable the administrator to further constrain the container configurations, and granted permissions based on a specific ticket, training, etc.

FIG. 2is a block diagram that schematically illustrates an alternative configuration of host computer24, in accordance with an embodiment of the present invention. In the configuration shown inFIG. 2, processor38executes, from memory42, a hypervisor44that creates a virtual machine46in the second memory, and the second processor generates and executes container36within the virtual machine. While the configuration inFIG. 1shows a single virtual machine46in memory42, hypervisor44may define multiple virtual machines46in the second memory, and processor38can generate and execute container36within any given virtual machine46.

Processors30,38and54comprise general-purpose central processing units (CPUs) or special-purpose embedded processors, which are programmed in software or firmware to carry out the functions described herein. The software may be downloaded to computers22,24and26in electronic form, over a network, for example, or it may be provided on non-transitory tangible media, such as optical, magnetic or electronic memory media. Alternatively, some or all of the functions of the processor may be carried out by dedicated or programmable digital hardware components, or using a combination of hardware and software elements.

These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

Service Ticket Processing Using Custom Software Containers

FIG. 3is a flow diagram that schematically illustrates a method of selecting metadata (e.g., a given container configuration50and a given permission set51) that host computer24can use to generate software container36for use when processing a service ticket for the host computer, in accordance with an embodiment of the present invention. In definition step70, processor30initializes facility20by defining software container configurations50and permission sets51, and in a receive step72, the first processor receives a request to open a service ticket for performing a service operation on host computer24.

In an identification step74, processor30identifies one or more resources on host computer24that a system administrator requires (i.e., needs access to) in order to perform the service operation, and in a first select step76, the first processor selects, based on the required resources, a given software configuration50and a given permission set51. In some embodiments, the service operation to be performed by the system administrator may require resources on multiple host computers24, and the selected permission set may therefore include one or more networking permissions. When working with multiple host computers24while performing a single service operation, each of the host computers may execute its own separate container36.

In a first transmission step78, processor30conveys, via network28, the (selected) given software configuration and the given permission set to host computer24. In a first comparison step80, if processor30receives an insufficient permissions message from host computer24, then in a second selection step82, ticket handler application34updates the given permission set with additional permissions. As described in the description referencingFIG. 4hereinbelow, processor38conveys the insufficient permissions message to computer22if the service operation associated with the service ticket cannot be completed using the first given permission set.

In a second transmission step84, ticket handler application34conveys the updated given permission set to host computer24, and the method continues with step80. In some embodiments, ticket handler application34can, in step84, simply convey the permissions that were added in step82(i.e., instead of conveying the entire updated permission set).

Returning to step80, the method ends if processor30does not receive an insufficient permissions message. In some embodiments, processor30can receive a message from host computer indicating completion of the service operation and thereby indicating the first given permission set had sufficient privileges to perform the service operation.

FIG. 4is a flow diagram that schematically illustrates a method of generating container36, and using the software container while processing a service ticket on host computer24, in accordance with an embodiment of the present invention. In a first receive step90, processor38receives a given container configuration50and a given permission set51, and in a generation step92, the second processor uses the given container configuration and the given permission set to generate container36. To generate container36, processor38can execute, from memory42, a container application such as Docker™.

Upon receiving, in a second receive step94, a login command from a system administrator associated with container36, processor38starts executing (i.e., opens) software container36in an first execution step96, and starts synchronously recording events60(i.e., keyboard entries) to event log58in a recording step98. In embodiments of the present invention, in response to detecting the login by the system administrator, processor38start executing container36, which provides access to resources that the system administrator needs to perform the requested service operation.

While performing the requested service operation, processor38, in a second execution step100, starts executing a set of software processes52in response to input received from the system administrator. In a comparison step102, if there are sufficient permissions, in the received permission set, to process the service ticket, then processor38continues to process commands in response to input received from the system administrator while performing the service operation.

In an identification step104, processor38identifies any of processes52that are to continue to be executed upon the system administrator completing the service operation and closing software container36. In some embodiments, processor can identify one or more processes52based on input received from the system administrator. Upon completing the service operation, the system administrator inputs a logout command, and in response to receiving the logout command in a third receive step106, processor38closes software container36in a first closing step108, and conveys a message to processor54to close event log58in a second closing step110.

Finally, in a continuation step112, subsequent to closing software container36, processor38continues to execute one or more of the processes that were identified in step104, and the method ends. By leaving the one or more processes in a running state, embodiments of the present invention enable the system administrator to leave the host computer fully operational upon completing the service operation.

Returning to step102, if there are not sufficient permissions in the received permission set for the system administrator to perform the service operation, then processor38conveys an insufficient permissions message to computer22in a transmission step114, receives (in response to step84described supra) an updated permission set51in a fourth receive step116, and the method continues with step102.

FIG. 5is a flow diagram that schematically illustrates a method of processing an event log that monitors software container36, in accordance with an embodiment of the present invention. In a first receive step120, processor54receives, from container36, a command to open event log58. In a second receive step122, processor54receives a container event from container36, and in a recording step124, the third processor synchronously stores the container event to a respective event60in event log58.

In a first comparison step126, if the received container event indicates suspicious activity, then in a first closing step128, processor54conveys a command to processor38to close container36. For example, processor54may detect a sequence of container events that indicate that the system administrator is attempting to install malware on host computer24, and in response to detecting the sequence of container events, processor54initiates a closing of container36.

In a second closing step130, processor54closes event log58, and the method ends. Returning to step126, if the received container event does not indicate suspicious activity, then in a second comparison step132, processor54checks if the received container event indicates that processor38closed container36(i.e., upon the system administrator completing the service operation). If the received event indicates that processor38closed container36, then the method continues with step130. However, if the received event does not indicate that processor38closed container36, then the method continues with step122.