Patent Application
20230214248
The present disclosure relates generally to computer security. More specifically, but not by way of limitation, this disclosure relates to controlling container commands issued in a distributed computing environment.
Distributed computing environments (e.g., cloud computing systems, data grids, and computing clusters) have recently grown in popularity given their ability to improve flexibility, responsiveness, and speed over conventional computing systems. The way in which software programs are deployed inside distributed computing environments has also evolved in recent years. Software programs such as applications and microservices are often now deployed in distributed computing environments using containers. A container is a relatively isolated virtual environment that can be generated by leveraging resource isolation features (e.g., cgroups and namespaces) of the Linux kernel. Deploying software programs inside containers can help isolate the software programs from one another and provide other benefits.
To help automate the deployment, scaling, and management of software programs inside containers, some distributed computing environments may include container orchestration platforms. Container orchestration platforms can help manage containers to reduce the workload on users. One example of a container orchestration platform is Kubernetes. Distributed computing environments running Kubernetes can be referred to as Kubernetes environments. Some orchestration platforms, like Kubernetes, have an application programming interface (API) that serves as a centralized administrative user interface through which users can issue commands.
Container orchestration platforms may include an application program interface (API) that serves as a central administrative control system to which users may issue container commands to configure software applications running within containers. For example, a user may issue an “exec” command to the API to cause a container to execute certain functions. Another example, a user may issue a “port-forward” command to the API to configure certain port-forwarding functions. But the API often lacks security controls. As a result, users may be able bypass their security restrictions by issuing commands to the API. For example, a distributed computing environment may have rule-based access controls (RBAC) that completely prevent non-privileged users from executing certain commands, regardless of the situation. These RBAC rules are broadly applicable and may be over-inclusive as a result. Beyond being over-inclusive, in some cases the RBAC rules can be circumvented, at which point users can then issue commands to specific containers and container pods using the API. With this approach, users can indirectly issue commands to specific containers and container pods via the API to avoid their security restrictions. This lack of security can introduce an attack vector to containers that may be exploited by malicious actors. While one solution may be to configure the API to prevent all execution of certain commands, like the exec command and port-forward command, this solution is overbroad and prevents the legitimate use of such commands. For example, the exec command and port-forward commands are often used for legitimate troubleshooting purposes. Completely forbidding execution of such commands may result in a loss of important troubleshooting functionality.
Some examples of the present disclosure can overcome one or more of the abovementioned problems by introducing a security system to govern authorization of container commands issued through the API. A container command can be a command issued to the API for controlling some aspect of the operation of a container managed by the container orchestration platform. More specifically, the security system may intercept a container command issued to the API. The security system can intercept the container command using a webhook, in some examples. In response to intercepting the container command, the security system may determine whether the container command complies with or violates a security policy. There can be one or more security policies with various conditions that may need to be met to allow the execution of the container command. If the security system determines that the container command does not violate one or more security policies, the security system can allow execution of the container command. If the security system determines that the container command does violate the one or more security policies, the security system may prevent the container command from being executed. The security system can also record the attempted container command for later evaluation by security personnel. In this way, the security system can monitor and control how and when certain container commands are allowed to execute. This may allow for a more granular level of control over the execution of such commands, for example so that malicious activities may be prevented while legitimate troubleshooting activities may be allowed.
In some examples, the security policy may be evaluated using various data collected by a data collector. The data collector can be a software application that collects data from various components for use by the security system in evaluating container commands associated with a target container against the security policy. Examples of this various data may include the operating system version of the target container, the name of the target container, or the number of processor cores the target container is permitted to use. For instance, a container command may be found to be in violation of a security policy if execution of the container command is attempted for a target container that has an operating system version for which the container command is prohibited.
In some examples, the security system could serve as a common exception framework through which users accessing a distributed computing environment may be granted or denied the ability to execute certain container commands based on a common (i.e., the same) set of factors, as defined in the security policy. This may be different from, for example, granting or denying access to certain container commands or features based on user-specific privileges or roles, or based on user- or group-specific RBACs.
These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements but, like the illustrative examples, should not be used to limit the present disclosure.
The secured cluster 101 includes an admission controller 103 and a data collector 107. The admission controller 103 includes a policy engine 105 that can be executed in response to a validating webhook 109. The validating webhook 109 may be triggered in response to a container command 113 issued to an application programming interface (API) 127 of the first container orchestration platform 126. The validating webhook 109 may have a corresponding configuration object. The corresponding configuration object may specify which container command or commands trigger the validating webhook 109. The policy engine 105 may evaluate the container command 113 against one or more predefined security policies 129, which may take into account various types of information 123 from the data collector 107 in the evaluation process. If the policy engine 105 determines that the container command 113 violates the one or more security policies 129, the policy engine 105 can issue an alert 125 to the data collector 107, which in turn may pass the alert 125 on to the central cluster 115 usable to manage the secured cluster 101. The central cluster 115 may contain a database 117 in which such alerts 125 may be stored and further evaluated.
More specifically, the validating webhook 109 may be designed to intercept a container command 113. Examples of the container command 113 can include an exec command and a port-forward command. The exec command can allow the user to control a target container and cause it to execute certain functions. The port-forward command can allow the user to establish port forwarding to a target container.
Container commands, such as the exec command and the port forward command, can allow the user to bypass security restrictions. Another example container command, a delete command, may allow deletion of container resources by filename, standard input stream, or by label sector. Another example container command, rollout undo, can undo a previous rollout of container elements. The container command 113 may be issued by a user using a user interface of either the first container orchestration platform 126 or the second container orchestration platform 128. An example of the user interface may be the API 127 described above. The validating webhook 109 may detect the container command 113 and, in response, generate an admission review request 121 associated with the container command 113. The validating webhook 109 can then transmit the admission review request 121 to the policy engine 105. The validating webhook 109 may enable enforcement of the security policy 129 by intercepting the container command 113 before the container command 113 can execute. The policy engine 105 may return a response 119 (e.g., an allowance or denial) of the container command 113 to the validating webhook 109, or another component of the admission controller 103, after evaluating the container command 113 against the one or more predefined security policies 129.
The policy engine 105 may receive various kinds of information 123 from the data collector 107 for use in its evaluation process. For example, the policy engine 105 may have one or more predefined security policies 129, which may include one or more policy criteria. Some of the policy criteria may depend on the various kinds of information 123 gathered from the data collector 107, as described in greater detail later on.
The admission controller 103 may be deployed in the secured cluster 101 and may be monitored by the central cluster 115. The admission controller 103 may be designed to be unalterable by the container command 113. The admission controller 103 may accept security policies 129 or policy criteria from the central cluster 115, via the data collector 107, and pass it to the policy engine 105 for use in the evaluation process. The admission controller 103 may execute the policy engine 105 to perform a policy evaluation.
In some examples, the admission controller 103 may evaluate the list of policy criteria against various kinds of information 123 associated with an attempt of the container command 113. The various kinds of information 123 may include, but is not limited to, the examples listed in Table 1 below. The admission controller 103 may alert 125 an administrator in response to detecting a policy violation. For example, the admission controller 103 can transmit the alert 125 to a computing device associated with the administrator to warn the administrator of the attempted container command 113. The computing device may be any suitable type of user device, such as a mobile phone, laptop computer, or tablet. Alternatively, the computing device may be part of the central cluster 115, which can be used to manage multiple secured clusters and can be monitored by the administrator. The administrator can also receive the alert 125 via JIRA®, Slack®, e-mail, text message, Microsoft Teams®, Pager Duty®, or any other form of communication. The alert 125 can contain a categorization of the security policy violated.
In some examples, the data collector 107 may act as an intermediary between the admission controller 103 and the central cluster 115, though other embodiments are also contemplated herein that may exclude the data collector 107 or integrate its functionality into other components of the system such as the admission controller 103. The data collector 107 may be aware of the policy criteria within the policy engine 105. Based on the policy criteria, the data collector 107 may perform introspection into the secured cluster 101 to collect various types of information 123 usable by the policy engine 105 in its evaluations. Examples of such information may include the hardware and software components of the secured cluster 101, and the configurations or settings thereof. Some specific examples of the information 123 are described in Table 1 below. The following examples are to be understood within the context of a target container for which a container command has been issued, and the container image usable to deploy the target container.
The data collector 107 can collect some or all of the above information for a target container or the container orchestration platform 126, 128 associated with the container command 113. The data collector 107 can then provide this information to the policy engine 105, which can evaluate the one or more security policies 129 using this information. As one specific example, the policy engine 105 can determine that a container command 113 violates the security policy 129 because the target container associated with the container command 113 has a prohibited resource name. Another example can involve the policy engine 105 determining a container command 113 is in violation because the security policy 129 prohibits the execution of the container command 113 for clusters or containers with a specified container CPU limit. Another example can involve the policy engine 105 allowing the container command 113 because, although the security policy 129 prohibits the container command 113 for containers with a specified volume name, the target container's filesystem does not have the specified volume name.
Although
The processor 203 can include one processor or multiple processors. Non-limiting examples of the processor 203 include a Field-Programmable Gate Array (FPGA), an application-specific integrated circuit (ASIC), a microprocessor, etc. The processor 203 can execute instructions 207 stored in the memory 205 to perform operations. In some examples, the instructions 207 can include processor-specific instructions generated by a compiler or an interpreter from code written in a suitable computer-programming language, such as C, C++, C #, etc.
The memory 205 can include one memory or multiple memories. The memory 205 can be non-volatile and may include any type of memory that retains stored information when powered off. Non-limiting examples of the memory 205 include electrically erasable and programmable read-only memory (EEPROM), flash memory, or any other type of non-volatile memory. At least some of the memory 205 can include a non-transitory, computer-readable medium from which the processor 203 can read instructions 207. A computer-readable medium can include electronic, optical, magnetic, or other storage devices capable of providing the processor 203 with computer-readable instructions or other program code. Non-limiting examples of a computer-readable medium include magnetic disk(s), memory chip(s), ROM, random-access memory (RAM), an ASIC, a configured processor, optical storage, or any other medium from which a computer processor can read the instructions 207.
In some examples, the processor 203 can execute the instructions 207 to perform some or all of the functionality described herein. For example, the processor 203 can intercept, using the validating webhook 109, a container command 113 issued to a user interface 209, such as the API 127, of a container orchestration platform 200. The container command 113 may correspond to (e.g., be designated for) a particular container 211 managed by the container orchestration platform 200. In response to intercepting the container command 113, the processor 203 can determine that the container command 113 may violate a security policy 129. In response to determining that the container command 113 violates the security policy 129, the processor 203 may prevent the container command 113 from being executed in relation to a container 211 of the container orchestration platform 200.
In some examples, the processor 203 can implement some or all of the steps shown in
In block 301, the processor 203 may intercept a container command 113 using the validating webhook 109. The validating webhook 109 may be software designed to be automatically triggered in response to certain events, such as issuance of the container command 113. The validating webhook 109 may forward the container command 113 to the policy engine 105, or may generate an admission review request 121 based on the container command 113. The container command 113 may originate from a user interacting with a user interface 209 of a container orchestration platform 200, such as the first container orchestration platform 126 or the second container orchestration platform 128. In some examples, the container command 113 may be a port-forward command or another type of command.
In block 303, the processor 203 may determine that the container command 113 violates a security policy 129. The admission controller 103 may be executed by the processor 203 to determine the violation of the security policy. The admission controller 103 may govern how container commands issued in a secured cluster 101 are evaluated and validated. The policy engine 105 may perform the evaluation of the admission controller 103. The admission controller 103 may reference various kinds of information 123 gathered from the data collector 107 to make the allowability determination for the container command 113. The various kinds of information 123 may include the examples listed above in Table 1.
In block 305, the processor 203 can prevent the container command 113 from being executed in relation to a container 211 of the container orchestration platform 200. In some examples, preventing the container command 113 from being executed may prevent access to ports of the corresponding container 211. In other examples, preventing the container command 113 from being executed may prevent alterations to the container 211 or execution of certain commands by the container 211. The processor 203 may alert a system administrator of the prevented container command. Additionally or alternatively, the processor 203 may log an instance of the prevented container command in a central database 117 associated with a central management cluster 115.
In some examples, the processor 203 can implement some or all of the steps shown in
In block 401, the processor 203 may intercept the container command 113 using a validating webhook 109. The validating webhook 109 may forward the container command to the policy engine 105 or may generate an admission review request 121 based on the container command 113. The container command may originate from a user interacting with a user interface 209 of a container orchestration platform 200. In some examples the container command may be a port-forward command or another type of command.
In block 403, the processor 203 may determine the container command complies with a security policy. The admission controller 103 may be executed by the processor 203 to determine compliance with the security policy 129. The admission controller 103 may govern how container commands issued in a secured cluster are evaluated and validated. The policy engine 105 may perform the evaluation of the admission controller 103. The admission controller 103 may reference various kinds of information 123 gathered from the data collector 107 to make the allowability determination for the container command. The various kinds of information 123 may include the examples listed above in Table 1.
In block 405, the processor 203 may allow the execution of the container command 113 in relation to a container 211 of the container orchestration platform 200. In some examples, the processor 203 may alert a system administrator of the executed container command 113. The processor 203 may log an instance of the executed container command in a central database 117 associated with a central management cluster 115.
The foregoing description of certain examples, including illustrated examples, has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications, adaptations, and uses thereof will be apparent to those skilled in the art without departing from the scope of the disclosure. For instance, any example(s) described herein can be combined with any other example(s) to yield further examples.
