Providing multiple namespace support to an application in a container under KUBERNETES

Abstract

This disclosure describes techniques for providing multiple namespace support to an application in a container under Kubemetes without breaking containment boundaries or escalating privileges of the application. A namespace service executing on a physical server can communicate with a containment process executing on the physical server by utilizing a Unix Domain Socket (UDS) endpoint in a file system of each container, the namespace service can execute on the physical server with escalated privileges, allowing the namespace service to create sockets in the namespace and provide permissions and rights to utilize the sockets to processes in separate namespaces.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Provisional Application No. 62 / 958,969, filed January 9, 2020; and U.S. Application No. 16 / 985,720, filed August 5, 2020, which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to providing a process with access to multiple namespaces by utilizing privileged services to create sockets in any namespace on a computing device and to provide access to sockets in individual namespaces on the computing device. Background Technology

[0004] Cloud computing provides users with access to computing resources to meet their needs. In some examples, service providers can manage and provide cloud computing resources to users to meet their needs without requiring users to invest in and maintain their own computing infrastructure. Cloud computing typically involves the use of data center networks, which contain servers, routers, and other devices that provide users with computing resources, such as computing resources, network resources, storage resources, database resources, application resources, etc.

[0005] To support applications or workloads using cloud computing, application containerization is used as a wrapper mechanism to abstract applications from the environment in which they actually run. Typically, a single physical server can run multiple applications or services using virtualization technologies such as virtual machines, application containers, or services. Containers provide a clear separation between applications, services, and other network workloads, allowing for lightweight implementations to ensure security across containerized workloads. Some container orchestration systems (such as Kubemetes) employ a namespace-based networking strategy to ensure that containers assigned to different namespaces do not interfere with each other. For example, a namespace can be assigned to a container, configured to reject traffic from other namespaces while allowing traffic from the same namespace to which the container is assigned.

[0006] When running specific network workloads with a particular set of features (e.g., virtual network functions on virtual machines, containers, etc.), you may find that Virtual Network Functions (VNFs) use the Berkeley Software Distribution (BSD) socket API, which is primarily or specifically designed for communication, and must reside in different Virtual Router and Forwarder (VRF) instances (e.g., different interfaces in different VRFs within a network). However, some container orchestration systems (e.g., Kubemetes) may restrict the functionality of certain applications, preventing containers from accessing multiple namespaces (standard Linux best practices for separating interfaces and routing tables). There may be techniques, such as privilege escalation, to break this constraint and address this issue. However, these techniques typically require giving an application control over the container platform, thus complicating support to the point that allowing multiple VNFs from different service providers on the same container platform can effectively be denied. Attached Figure Description

[0007] The following is a detailed description with reference to the accompanying drawings. In the drawings, the leftmost numeral of the reference numeral indicates the first figure in which the reference numeral appears. The same reference numerals are used in different figures to indicate similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the figures may be depicted as not to scale relative to each other.

[0008] Figure 1 The system architecture diagram illustrates an example flow in an environment where a namespace service provides containerized processes, assigned to individual namespaces, with the sockets created within those namespaces and the permissions to utilize them.

[0009] Figure 2 A flowchart illustrates an example method for a namespace service to receive a request from a containerization process assigned to a namespace to create a socket in a separate namespace and to provide the socket file descriptor to the containerization process.

[0010] Figure 3 A flowchart illustrates an example method for a containerization process assigned to a namespace to send a request to a namespace service to create a socket in a separate namespace and to receive a socket file descriptor from the namespace service.

[0011] Figure 4 A computing system diagram illustrating the configuration of a data center is shown, which can be used to implement aspects of the techniques disclosed herein.

[0012] Figure 5 This is a computer architecture diagram illustrating an illustrative computer hardware architecture for implementing a server device that can be used to implement aspects of the various technologies proposed herein. Detailed Implementation

[0013] Overview

[0014] The aspects of the invention are set forth in the independent claims and preferred features are set forth in the dependent claims. A feature of one aspect may be applied to any aspect alone or in combination with other aspects.

[0015] This disclosure describes techniques for performing a namespace service on a physical server, the namespace service being configured to create namespaces and provide sockets from the namespaces to individual namespaces. The method includes executing a process on a computing device running in a first container allocated to a first namespace, the first container being assigned a first privilege that restricts the first container's access to the first namespace. The method also includes performing a namespace service on the computing device, the namespace service being assigned a second privilege that allows the namespace service to access both the first and second namespaces. The method further includes receiving a request from the namespace service for the process to create a socket in a second namespace to allow the process to communicate with a second container allocated to the second namespace. The method also includes the namespace service creating the socket in the second namespace. Finally, the method includes providing the process with a file descriptor associated with the socket from the namespace service.

[0016] Additionally or alternatively, the method includes executing a process on a computing device running in a first container allocated to a first namespace, the first container being granted a first privilege that restricts the first container's access to the first namespace. The method also includes executing a namespace service on the computing device, the namespace service being granted a second privilege that allows the namespace service to access both the first and second namespaces. The method further includes sending a request to the namespace service and from the process to create a socket in the second namespace to allow the process to communicate with the second container allocated to the second namespace. The method also includes receiving, at the process, a file descriptor associated with the socket and a third privilege allowing the process to use the socket from the namespace service.

[0017] Furthermore, the techniques described herein can be implemented by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described above.

[0018] Example Implementation

[0019] Typically, containerization is used in cloud computing networks to separate applications, services, and other network workloads to ensure security and prevent interference between applications. Some container orchestration systems (such as Kubemetes) employ a namespace-based networking strategy to ensure that containers located in different namespaces do not interfere with each other. For example, each Virtual Router and Forwarder (VRF) instance on the platform can be mapped to a corresponding namespace. Namespaces can be populated with network interfaces, such as external network interfaces moved from the default namespace to a newly created namespace, loopback interfaces created within the namespace, etc. In some examples, a namespace can be assigned to a container, configured to reject traffic from different namespaces while allowing traffic from the same namespace to which the container is assigned.

[0020] Some container orchestration systems (such as Kubemetes) may restrict the functionality of certain applications, preventing containers from accessing multiple namespaces (a standard Linux best practice for separating interfaces and routing tables). However, in some cases, applications may want to use multiple network namespaces. For example, an application might want to communicate with its users while being controlled by communication from its administrator. To ensure security and avoid interference, applications can be containerized and bound to other applications on the platform. However, containerized applications may lack the privileges required to create or obtain file descriptors for sockets in separate namespaces. There may be techniques, such as privilege escalation, to break this constraint and address this issue. However, these techniques typically require giving an application control over the container platform, thus complicating support to the point that allowing multiple VNFs from different service providers on the same container platform would be effectively denied. Furthermore, escalating application privileges in this way can lead to interference with other applications and security risks.

[0021] This disclosure describes techniques for providing multiple namespace support to applications within containers under Kubemetes without breaking tether boundaries or application upgrade privileges. As mentioned above, container orchestration systems (such as Kubemetes) prevent access to multiple namespaces from a single container, and applications within such containers typically lack the privileges required to access and / or create sockets in individual namespaces. The techniques described herein involve executing a namespace service on a computing device. The namespace service may have connections, such as Unix domain sockets (UDS), to which each container running on the computing device consuming the UDS connects. The namespace service may have upgrade capabilities within the system, allowing it to perform various operations that other applications in the system cannot, such as interface configuration, IP firewall management, modification of routing tables, etc. (i.e., the CAP_NET_ADMIN capability in Linux systems). The namespace service can handle requests for new sockets in a second namespace received via an associated first UDS connection from processes assigned to the first namespace. The namespace service can verify credentials and determine whether a process should be allowed to access the second namespace. It can also create and obtain file descriptors for sockets in the second namespace by connecting the second namespace to an associated second UDS connection with the namespace service. The namespace service can then transfer the file descriptors and socket privileges to the process in the first namespace via the first UDS connection, thus allowing the process to use both the first and second namespaces simultaneously without escalating process privileges.

[0022] In some examples, the namespace service is executed when the physical server starts. The system may allow the namespace service to execute in various ways, such as, but not limited to, as a system process, on a virtual machine, as an application, or as a containerized application. The namespace service may have upgrade capabilities within the system, allowing it to perform various operations that other applications on the system cannot. In some examples, the namespace service may run with root privileges, providing it with many upgrade capabilities, such as the Linux CAP_NET_ADMIN capability. During execution, the namespace service may obtain information from additional services configured to create namespaces when the physical server starts, notifying the namespace service of namespaces on the system. In some examples, the namespace service may utilize namespaces that are statically created and defined by configuration files. For example, configuration files may include preferences associated with a namespace, such as interfaces associated with a namespace, routing tables associated with a namespace, etc. Additionally or alternatively, the namespace service may be configured to dynamically change namespaces, or utilize additional services configured to dynamically change namespaces, and may modify preferences defined in the associated configuration files. In some examples, the namespace service can create Unix domain sockets (UDS) to access each namespace in the system. In some examples, when containers are deployed in the system, the containers can be configured so that the UDS is consumed by the container during execution, allowing applications running within the container to communicate with the namespace service regardless of their assigned namespace. In some examples, the UDS is deployed within the filesystem of each container on a physical server.

[0023] A process (or application) may begin execution in a first container on a physical server. In some examples, the first container may be assigned to a first namespace. Additionally or alternatively, the first container may be assigned first-level privileges (or capabilities) restricting access to the first namespace by the first container, preventing processes and applications executing in the first container from accessing additional namespaces. The first namespace may utilize interfaces to communicate with other processes and applications. Additionally or alternatively, the first container may include a UDS, allowing the first container to communicate with the namespace service through the UDS. In some examples, the UDS may be consumed or utilized by any process and / or application executing in the first container.

[0024] In some examples, a process running in a first container can gain access to sockets in a second namespace where access to the first container is restricted. For example, a process can use a UDS to send a request to a namespace service to create a socket in the second namespace. Additionally or alternatively, the request may include desired attributes associated with the socket, which may include, but are not limited to, the desired Internet Protocol version, datagram or stream socket, or any other attributes associated with the socket. In some examples, the namespace service can perform multiple authorization checks associated with the process requesting the socket. For example, the namespace service can verify that the second namespace does not include any restrictions regarding the process and / or the first namespace. Additionally or alternatively, the namespace service can verify that the second namespace does not include restrictions on any external namespaces. Additionally or alternatively, the namespace service can verify that at least one container allocated to the second namespace includes a UDS, such that the namespace service can transmit instructions for creating the socket via the UDS to the second namespace.

[0025] In some examples, the namespace service can send instructions via UDS for creating sockets in a second namespace. Additionally or alternatively, the second namespace can create the sockets under the control of the namespace service. In some examples, the namespace service can send attributes associated with the socket to the second namespace, such that the socket includes the desired attributes when it is created. The second namespace can then generate a permission object, including permissions to utilize the newly created socket. In some examples, the permission object can only allow processes to utilize the socket. Additionally or alternatively, the permission object can allow any process associated with the first namespace to utilize the socket. The namespace service can receive file descriptors associated with the sockets from the second namespace via UDS. In some examples, the second namespace can transfer permission objects to the namespace service via UDS.

[0026] The namespace service can send file descriptors associated with sockets to processes in the first container assigned to the first namespace via a UDS. Additionally or alternatively, the namespace service can transfer permission objects to processes via a UDS. Additionally or alternatively, the namespace service can transfer permission objects to the first namespace.

[0027] Processes can use file descriptors to access newly created sockets in a second namespace. Using the sockets in the second namespace, processes can utilize the second namespace interface, allowing processes assigned to the first namespace to access ports that only processes assigned to the second namespace have access privileges to. In some examples, the first container can use a privilege object to allow processes to utilize the sockets. Additionally or alternatively, the first container can consume the privilege object, causing the privileges associated with the first container to be escalated. For example, after consuming the privilege object, the privileges associated with the first container can be escalated to allow processes in the first container to access multiple namespaces, such as the first namespace provided by the Container Network Interface (CNI) associated with the first container, and the second namespace, without escalating the process's privileges (e.g., escalating process privileges to the global root and / or CAP_NET_ADMIN level).

[0028] The techniques described in this paper offer various improvements and efficiencies for containerized applications. For example, the techniques described in this paper can allow unprivileged containerized applications to access multiple namespaces without escalating the application's privileges to an insecure level. Furthermore, by leveraging a single namespace service running on a physical server, security between workloads in different containers is maintained, and network interference is avoided.

[0029] Certain implementations and embodiments of this disclosure will now be described more fully with reference to the accompanying drawings, in which various aspects are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. As stated herein, this disclosure includes variations of the embodiments. The same numerals always refer to the same elements.

[0030] Figure 1 A system architecture diagram illustrating an example process in environment 100 is shown, in which a namespace service provides containerized processes assigned to individual namespaces within a cloud computing network 102 with sockets created in those namespaces and the permissions to utilize those sockets. The cloud computing network 102 may include one or more data centers 104, which include various network devices, such as physical servers 106. Data centers 104 may be located across geographical regions, and the cloud computing network 102 may be a distributed network through which users (typically clients) can interact via user devices to manage or otherwise interact with services provided by the cloud computing network 102.

[0031] Cloud computing network 102 can provide on-demand availability of computing system resources of physical server 106, such as data storage, computing power (e.g., CPU, GPU, etc.), networking, databases, etc., without requiring direct user management. In some examples, cloud computing network 102 can be managed and maintained by a service provider, eliminating the need for users to invest in and maintain computing infrastructure for their computing resource needs. Typically, users can be provided with access to or allocation of a portion of the computing resources of physical server 106 within cloud computing network 102. Cloud computing network 102 can be scaled based on individual user needs, for example, by accelerating or decelerating resources. Portions of cloud computing network 102 can be allocated using hardware virtualization, allowing portions of cloud computing network 102 to be configured and managed by users (e.g., security configuration, load balancing configuration, etc.). However, cloud computing network 102 does not need to be managed by a service provider and can be managed by any entity, including the users running applications or services themselves.

[0032] In some examples, physical server 106 may host one or more virtual containers 108(1)-(N), where N is any integer greater than "1". Each container 108 may be configured to perform one of various operations and act as one or more virtual components of cloud computing network 102. In some examples, containers 108(1)-(N) in cloud computing network 102 may host at least one process 110(1)-(N) and may include container network interface (CNI) 112(1)-(N), where N is any integer greater than "1". Additionally or alternatively, physical server 106 may host one or more namespaces 114. In some examples, containers 108 may be assigned to namespace 114. In some examples, containers 108 may be assigned to namespace 114 at least in part based on CNI 112, such that CNI 112 is configured to interact with the assigned namespace 114.

[0033] In some examples, physical server 106 may host namespace service 116. In some examples, namespace service 116 may have upgrade capabilities within the physical server, allowing it to perform various operations that other processes 110 in the system cannot. In some examples, namespace service 116 may run with root privileges, providing it with numerous upgrade capabilities, such as the Linux CAP_NET_ADMIN capability, thereby allowing it to access and perform various actions in multiple namespaces 114 running on physical server 106. Additionally or alternatively, namespace service 116 may have connections, such as Unix domain sockets (UDS) 118, that connect to namespace service 116 for each container 108 executing on physical server 106 consuming UDS 118.

[0034] Typically, the number of containers 108 can be scaled based on the number of users 120 interacting with the cloud computing network 102. Users 120 may include one or more individual users, user groups, organizations, enterprises, or other entities interacting with the cloud computing network 102 through corresponding user devices. User devices can be any type of computing device capable of connecting to the cloud computing network 102 via a suitable data communication network 122, such as, but not limited to, laptop or desktop computers, tablet computing devices, server computers, televisions, or mobile phones. Administrative users used by the operator of the cloud computing network 102, such as administrators managing the operation of the cloud computing network 102, can also connect to, manage, and utilize resources provided by the service provider network 102 in a similar manner.

[0035] User 120 can provide input data 124 via network 122 to interact with services supported by container 108 running on server 106. For example, user 120 can submit requests to process data, retrieve data, store data, etc., thereby causing the virtual machine hosting container 108 to speed up or slow down to process requests on demand.

[0036] When physical server 106(1) starts, namespace service 116 may begin execution. Namespace service 116 may execute on the physical server in various ways, such as, but not limited to, executing a system process, on a virtual machine, as an application, as a containerized application, etc., without being limited to any particular method. During execution, namespace service 116 may be configured to obtain information from additional services and / or utilize configuration files to identify information. This information may include an identifier for namespace 114 in the system and may be used by namespace service 116 to identify each namespace 114 executed on the physical server. In some examples, namespace service 116 may utilize namespace 114 that is statically created and defined by a configuration file. For example, the configuration file may include preferences associated with namespace 114, such as interfaces associated with namespace 114, routing tables associated with namespace 114, etc. Additionally or alternatively, namespace service 116 may be configured to dynamically change namespace 114, or utilize additional services configured to dynamically change namespace 114, and may change preferences defined by associated configuration files. Namespace service 116 can then create Unix domain sockets (UDS) 118 to access each namespace 114 in the system (e.g., namespace A and namespace B). In some examples, when containers 108(1), (2) are deployed in the system, containers 108(1), (2) can be configured such that, at runtime, UDS 118 is consumed by containers 108(1), (2), creating endpoints in the file systems of containers 108(1), (2) to allow communication to be passed between namespace service 116 and containers 108(1), (2) via UDS 118. Additionally or alternatively, the UDS 118 endpoints can be configured to be set within the file systems of containers 108(1), (2).

[0037] When process 110(1) executes in container 108(1) assigned to namespace A 114, container 108(1) utilizes CNI 112(1) to facilitate communication received and sent from process 110(1) in namespace A 114. However, process 110(1) is restricted by container 108(1) and cannot send and / or receive communication in namespace B 114. Additionally or alternatively, container 108(1) may be assigned Level 1 privileges (or capabilities) that restrict container 108(1) to access namespace A, such that processes and / or applications executing in container 108(1) cannot access namespace B 114.

[0038] In some examples, process 110(1) running in container 108(1) may gain access to a socket in namespace B 114, where access to container 110(1) is restricted. For example, process 110(1) may use UDS 118(1) to send a request to namespace service 116 to create a socket in namespace B 114. Additionally or alternatively, the request may include desired attributes associated with the socket, which may include, but are not limited to, the desired Internet Protocol version, datagram or stream socket, or any other attributes associated with the socket. In some examples, namespace service 116 may perform multiple authorization checks associated with process 110(1) requesting the socket. For example, namespace service 116 may verify that namespace B 114 does not contain any restrictions regarding process 110(1) and / or namespace A. For example, namespace service 116 may perform various authorization checks. Additionally or alternatively, namespace service 116 may verify that namespace B 114 does not include restrictions on any external namespace (e.g., namespace A). Additionally or alternatively, namespace service 116 may verify that at least one container 108(2) assigned to namespace B 114 includes UDS 118(2), such that namespace service 116 may transmit instructions for creating sockets to namespace B 114 via UDS 118(2).

[0039] Namespace service 116 can send instructions to create a socket in namespace B 114 via UDS 118(2). Additionally or alternatively, namespace B 114 can create the socket under the control of namespace service 116. In some examples, namespace service 116 can send attributes associated with the socket to namespace B 114 such that the socket includes the desired attributes when it is created. Namespace B 114 can then generate a permission object, including permissions to utilize the newly created socket. In some examples, the permission object can allow only process 110(1) to utilize the socket. Additionally or alternatively, the permission object can allow any process 110 associated with namespace A 114 to utilize the socket. Additionally or alternatively, the permission object can allow any process 110 associated with container 108(1) to utilize the socket. Namespace service 116 can receive the file descriptor associated with the socket from namespace B 114 via UDS 118(2). In some examples, namespace B 114 can pass the permission object to the namespace service via UDS 118(2).

[0040] Namespace service 116 can send the file descriptor associated with the socket to process 110(1) in container 108(1) assigned to namespace A via UDS 118(1). Additionally or alternatively, namespace service 116 can transfer permission objects to process 110(1) via UDS 118(1). Additionally or alternatively, namespace service 116 can transfer permission objects to namespace A 114 via UDS 118(1).

[0041] A process can use a file descriptor to access a newly created socket in namespace B 114. Using the socket in namespace B 114, process 110(1) can utilize an interface accessible only in namespace B 114, thereby allowing process 110(1) assigned to namespace A to access ports that only processes 110(2), (3) assigned to namespace B 114 have access privileges to. In some examples, container 108(1) can utilize a privilege object to allow process 110(1) to utilize the socket. Additionally or alternatively, container 108(1) can consume the privilege object, causing the privileges associated with container 108(1) to be elevated. For example, after consuming the privilege object, the privileges associated with container 108(1) can be upgraded to allow process 110(1) in container 108(1) to access multiple namespaces, such as namespace A 114 and namespace B 114 provided by container network interface (CNI) 112(1) associated with container 108(1), without upgrading the privileges of process 110(1) (e.g., upgrading process privileges to the global root and / or CAP_NET_ADMIN level).

[0042] At "1", namespace service 116 can begin execution on physical server 106 in cloud computing environment 102. In some examples, namespace service 116 can execute on each physical server 106 in cloud computing environment 102. In some examples, namespace service 116 can have privilege or capability levels that allow namespace service 116 to access namespace A and namespace B. In some examples, the privilege or capability level can correspond to the global root and / or CAP_NET_ADMIN privilege levels.

[0043] At “2”, process 110(1) may begin running in container 108(1) on physical server 106. In some examples, container 108(1) may be assigned to namespace A 114. Alternatively or additionally, container 108(1) may be assigned to a default namespace at execution time and may be assigned to namespace A 114 at a later time. In some examples, container 108(1) may be associated with a privilege or capability level that restricts container 108(1)'s access to namespace A 114.

[0044] At “3”, namespace service 116 may receive a request from process 110(1) executing in container 108(1) in namespace A 114. In some examples, the request may include a request to create a socket in namespace B 114, allowing process 110(1) in namespace A 114 to communicate with container 108(2) in namespace B 114 without requiring privileges regarding system upgrade process 110(1) and / or container 108(1). In some examples, namespace service 116 may receive a request from process 110(1) via Unix domain socket (UDS) 118(1). In some examples, namespace service 116 may perform various authorization operations associated with process 110(1) requesting the socket. In some examples, the request may include information for defining attributes associated with the socket.

[0045] At point “4”, namespace service 116 may create a socket in namespace B 114. In some examples, namespace service 116 may send instructions to create a socket in namespace B 114 via UDS 118(2). Additionally or alternatively, namespace B 114 may create a socket under the control of namespace service 116. In some examples, namespace service 116 may send properties associated with the socket to namespace B 114 such that the socket includes the desired properties when it is created.

[0046] At point “5”, namespace service 116 can provide process 110(1) with the information required to utilize the socket. In some examples, namespace service 116 can send the file descriptor associated with the socket to process 110(1) via UDS 118(1). In some examples, namespace service 116 can provide process 110(1) with a permission object associated with the socket, such that the permission object allows process 110(1) to utilize the socket in namespace B 114.

[0047] Figure 2 and Figure 3 Flowcharts of example methods 200 and 300 are shown, illustrating at least in part the methods described above. Figure 1 This describes aspects of the functions performed by the cloud computing network 102. This article is about... Figure 2 and 3 The described logical operations can be implemented as (1) a series of computer-implemented actions or program modules running on a computing system and / or (2) as interconnected machine logic circuits or circuit modules within the computing system.

[0048] The implementation of the various components described herein depends on the choice of computing system performance and other requirements. Therefore, the logical operations described herein are referred to differently as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented using software, firmware, special-purpose digital logic, and any combination thereof. It should also be understood that it is possible to perform operations that are more complex than... Figure 2 and 3 The number of operations shown may be more or fewer and is described herein. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. Although the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented with fewer components, more components, different components, or any configuration of components.

[0049] Figure 2 A flowchart illustrates an example method for a namespace service to receive a request to create a socket in a separate namespace from a process within a container and assigned to a namespace, and to provide the socket file descriptor to the containerized process. This process may execute on one or more processors of a physical server 106 included in a cloud computing network 102. The physical server 106 may include one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions (e.g., process 110, container 108, namespace 114, etc.) that, when executed by the one or more processors, cause the one or more processors to perform method 200.

[0050] At 202, process 110(1) may execute on computing device 106 in cloud computing network 102. In some examples, process 110(1) may run in container 108(1) assigned to a first namespace (namespace A114). Additionally or alternatively, container 108(1) may be assigned to a default namespace at execution time and may be assigned to the first namespace at a later time. In some examples, a first privilege restricting container 108(1)'s access to the first namespace may be assigned to container 108(1).

[0051] At position 204, namespace service 116 may begin execution on computing device 106 in cloud computing environment 102. In some examples, namespace service 116 may execute on each physical server 106 in cloud computing environment 102. In some examples, namespace service 116 may be assigned privileges or capabilities that allow namespace service 116 to access a first namespace (namespace A 114) and a second namespace (namespace B 114). In some examples, the privileges or capabilities may correspond to the global root and / or CAP_NET_ADMIN privilege levels.

[0052] At 206, namespace service 116 may receive a request from process 110(1) executing in container 108(1) in the first namespace. In some examples, the request may include a request to create a socket in the second namespace, enabling process 110(1) in the first namespace to communicate with container 108(2) in the second namespace without requiring privileges regarding system upgrade process 110(1) and / or container 108(1). In some examples, namespace service 116 may receive the request from process 110(1) via Unix domain socket (UDS) 118(1). In some examples, namespace service 116 may perform various authorization operations associated with process 110(1) requesting the socket. In some examples, the request may include information for defining attributes associated with the socket.

[0053] At 208, namespace service 116 can create a socket in the second namespace. In some examples, namespace service 116 can send instructions to create a socket in the second namespace via UDS 118(2). Additionally or alternatively, the second namespace can create the socket under the control of namespace service 116. In some examples, namespace service 116 can send properties associated with the socket to the second namespace, such that the socket includes the desired properties when it is created.

[0054] At 210, namespace service 116 can provide process 110(1) with the information required to utilize the socket. In some examples, namespace service 116 can send the file descriptor associated with the socket to process 110(1) via UDS 118(1). In some examples, namespace service 116 can provide process 110(1) with a permission object associated with the socket, such that the permission object allows process 110(1) to utilize the socket in a second namespace.

[0055] Figure 3 A flowchart of an example method 300 is shown, illustrating how a containerized process assigned to a namespace sends a request to a namespace service to create a socket in a separate namespace and receives a socket file descriptor from the namespace service.

[0056] At 302, process 110(1) may execute on computing device 106 in cloud computing network 102. In some examples, process 110(1) may run in a first container 108(1) assigned to a first namespace (namespace A114). Additionally or alternatively, container 108(1) may be assigned to a default namespace at execution time and may be assigned to the first namespace at a later time. In some examples, a first privilege restricting container 108(1)'s access to the first namespace may be assigned to container 108(1).

[0057] At 304, namespace service 116 may begin execution on computing device 106 in cloud computing environment 102. In some examples, namespace service 116 may execute on each physical server 106 in cloud computing environment 102. In some examples, namespace service 116 may be assigned privileges or capabilities that allow namespace service 116 to access a first namespace (namespace A 114) and a second namespace (namespace B 114). In some examples, the privileges or capabilities may correspond to the global root and / or CAP_NET_ADMIN privilege levels.

[0058] At 306, process 110(1), executing in first container 108(1) within the first namespace (namespace A 114), may send a request to namespace service 116 to create a socket in the second namespace (namespace B 114) to allow process 110(1) to communicate with second container 108(2) assigned to the second namespace. In some examples, process 110(1) may send the request to namespace service 116 via Unix domain socket (UDS) 118(1). In some examples, the request may include information for defining attributes associated with the socket.

[0059] At 308, process 110(1) can receive information about using the socket from namespace service 116 via UDS 118(1). In some examples, process 110(1) can receive a file descriptor associated with the socket. In some examples, process 110(1) can receive a permission object associated with the socket from namespace service 116, such that the permission object allows process 110(1) to use the socket in a second namespace.

[0060] Figure 4 This is a computing system diagram illustrating the configuration of data center 400, which can be used to implement aspects of the techniques disclosed herein. Figure 5The example data center 400 shown includes several server computers 402A-402E (which may be referred to herein simply as "server computer 402" or in the plural as "server computer 402") for providing computing resources. In some examples, server computer 402 may include or correspond to server 106 described herein.

[0061] Server computer 402 may be a standard tower, rack, or blade server computer, appropriately configured to provide the computing resources described herein. As described above, the computing resources provided by cloud computing network 102 may be data processing resources, such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, network resources, etc. Some of the servers 402 may also be configured to execute resource managers capable of instantiating and / or managing computing resources. For example, in the case of VM instances, the resource manager may be a hypervisor or other type of program configured to enable the execution of multiple VM instances on a single server computer 402. Server computer 402 in data center 400 may also be configured to provide network services and other types of services.

[0062] exist Figure 5 In the example data center 400 shown, a suitable LAN 408 is also used to interconnect server computers 402A-402E. It should be understood that the configurations and network topologies described herein have been greatly simplified, and many more computing systems, software components, networks, and network devices can be used to interconnect the various computing systems disclosed herein and provide the aforementioned functionality. Suitable load balancing devices or other types of network infrastructure components can also be used to balance the load between data centers 400, between each server computer 402A-402E in each data center 400, and potentially between computing resources within each server computer 402. It should be understood that references... Figure 5 The configuration of the data center 400 described is illustrative only and other implementations may be used.

[0063] In some examples, server computers 402 may each execute one or more containers 108, which support services or applications provided across a set or group of servers 402. Virtual endpoints 112 on each server computer 402 may support a single application or service, or multiple applications or services (for one or more users).

[0064] In some cases, the cloud computing network 102 can provide computing resources permanently or on demand, such as application containers, VM instances, and storage. In other types of functions, the computing resources provided by the cloud computing network 102 can be used to implement the various services mentioned above. The computing resources provided by the cloud computing network 102 can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, network resources, data communication resources, network services, etc.

[0065] Each type of computing resource provided by the cloud computing network 102 can be general-purpose or available in many specific configurations. For example, data processing resources can be used as physical computers or VM instances in a variety of different configurations. VM instances can be configured to run applications, including web servers, application servers, media servers, database servers, some or all of the aforementioned network services and / or other types of programs. Data storage resources can include file storage devices, block storage devices, etc. The cloud computing network 102 can also be configured to provide other types of computing resources not specifically mentioned herein.

[0066] In one embodiment, the computing resources provided by the cloud computing network 102 may be enabled by one or more data centers 400 (which may be referred to herein as "data center 400" in the singular or plural). A data center 400 is a facility for housing and operating computer systems and associated components. A data center 400 typically includes redundant and backup power, communication, cooling, and security systems. Data centers 400 may also be located in geographically distinct locations. The following will discuss... Figure 5 An illustrative embodiment of a data center 400 that can be used to implement the techniques disclosed herein is described.

[0067] Figure 5 An example computer architecture is shown for a server computer 402 capable of executing program components for achieving the above-described functions. Figure 5 The computer architecture shown illustrates conventional server computers, workstations, desktop computers, laptop computers, tablets, network devices, e-readers, smartphones, or other computing devices, and can be used to execute any of the software components presented herein. In some examples, server computer 402 may correspond to the physical server 108 described herein.

[0068] Computer 402 includes a substrate 502 or “motherboard,” which is a printed circuit board to which multiple components or devices can be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”) 504 operate in conjunction with a chipset 506. The CPU 504 may be a standard programmable processor necessary to perform the arithmetic and logic operations required to operate computer 402.

[0069] The CPU 504 performs operations by manipulating switching elements to transition from one discrete physical state to the next. These switching elements distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides an output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, and more.

[0070] Chipset 506 provides an interface between CPU 504 and the remaining components and devices on substrate 502. Chipset 506 may provide an interface to RAM 508, which serves as the main memory in computer 402. Chipset 506 may further provide an interface to a computer-readable storage medium, such as read-only memory (“ROM”) 510 or non-volatile RAM (“NVRAM”), for storing information that facilitates booting computer 402 and transferring information between various components and devices. ROM 510 or NVRAM may also store other software components necessary for operating computer 402 according to the configuration described herein.

[0071] Computer 502 can operate in a networked environment using logical connections to remote computing devices and computer systems via a network (e.g., network 408). Chipset 506 may include functionality for providing network connectivity via NIC 512, such as a Gigabit Ethernet adapter. NIC 512 enables computer 402 to connect to other computing devices via network 408 (or 122). It should be understood that multiple NICs 512 may be present in computer 402 to connect the computer to other types of networks and remote computer systems.

[0072] Computer 402 can be connected to storage device 518, which provides non-volatile storage for the computer. Storage device 518 can store operating system 520, programs 522, and data, which have been described in more detail herein. Storage device 518 can be connected to computer 402 via storage controller 514 connected to chipset 506. Storage device 518 can consist of one or more physical storage units. Storage controller 514 can interface with physical storage units via Serial Attached SCSI (“SAS”) interface, Serial Advanced Technology Attached (“SATA”) interface, Fibre Channel (“FC”) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0073] Computer 402 can store data on storage device 518 to reflect the information being stored by transforming the physical state of the physical storage units. In different embodiments of this specification, the specific transformation of the physical state can depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage units, whether storage device 518 is characterized as primary or secondary storage, etc.

[0074] For example, computer 402 can issue instructions via storage controller 514 to store information in storage device 518 to alter the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this description; the foregoing examples are provided merely for the purpose of illustration. Computer 402 can further read information from storage device 518 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0075] In addition to the aforementioned high-capacity storage device 518, computer 402 can access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and is accessible by computer 402. In some examples, operations performed by cloud computing network 102 and / or any components included therein can be supported by one or more devices similar to computer 402. In other words, some or all of the operations performed by cloud computing network 102 and / or any components included therein can be performed by one or more computer devices 402 operating in a cloud-based arrangement.

[0076] By way of example and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (“EPROM”), electrically erasable programmable ROM (“EEPROM”), flash memory or other solid-state storage technologies, optical disc ROM (“CD-ROM”), digital versatile optical disc (“DVD”), high-definition DVD (“HD-DVD”), Blu-ray or other optical storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0077] As described above, storage device 518 may store operating system 520 for controlling the operation of computer 402. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a Microsoft Corporation from Redmond, Washington. SERVER operating system. According to a further embodiment, the operating system may include one of the UNIX operating systems or variants thereof. It should be understood that other operating systems may also be used. Storage device 518 may store other systems, applications, and data used by computer 402.

[0078] In one embodiment, storage device 518 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 402, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 402 by specifying how CPU 504 transitions between states. According to one embodiment, computer 402 can access a computer-readable storage medium storing computer-executable instructions that, when executed by computer 402, perform the above-described... Figure 1-4 The various processes described herein. Computer 402 may also include a computer-readable storage medium having instructions stored thereon for performing the operations of any other computer implementation described herein.

[0079] Computer 402 may also include one or more input / output controllers 516 for receiving and processing input from multiple input devices, such as a keyboard, mouse, touchpad, touchscreen, electronic pen, or other types of input devices. Similarly, input / output controllers 516 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices. It should be understood that computer 402 may not include... Figure 5 All components shown may include those not listed. Figure 5 Other components explicitly shown in the document, or those that may be used with Figure 5 The architecture shown is completely different.

[0080] Server computer 402 may support virtualization layer 524, such as one or more containers 108, namespace service 116, and / or container network interface 112 running on server computer 402. In some examples, virtualization layer 524 may be supported by a hypervisor that provides one or more virtual machines running on server computer 402 to perform the functions described herein. Virtualization layer 524 may typically support virtual resources that perform at least a portion of the techniques described herein. Processes contained in container 108 may utilize permissions and file descriptors associated with sockets in individual namespaces received from namespace service 116, thereby allowing process 108 to send and receive communications to and from multiple namespaces.

[0081] In summary, this disclosure describes techniques for providing multiple namespace support to applications within containers under Kubemetes without breaking tether boundaries or escalating application privileges. A namespace service executing on the physical server can communicate with the containing processes executing on the physical server by leveraging Unix Domain Socket (UDS) endpoints in each container's filesystem. The namespace service can execute on the physical server with escalated privileges, allowing the namespace service to create sockets within namespaces and provide processes in individual namespaces with the permissions and rights to utilize those sockets.

[0082] While the invention has been described with reference to specific embodiments, it should be understood that the scope of the invention is not limited to these specific embodiments. Since other modifications and alterations made to suit specific operating requirements and environments will be readily apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0083] Although this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions are merely illustrative embodiments falling within the scope of the claims of this application.

Claims

1. A system comprising: One or more processors; and One or more computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations including: Execute a process on a computing device that runs in a first container allocated to a first namespace, the first container being granted a first privilege that restricts the first container's access to the first namespace; A namespace service is executed on the computing device, and the namespace service is granted a second privilege that allows the namespace service to access the first namespace and the second namespace; The namespace service creates the first socket in the first container; The namespace service receives a request from the process via the first socket to create a second socket in a second container allocated to the second namespace. The second socket allows the process to access the second namespace from outside the second container without elevating the first privilege associated with the first process. The second socket is created in the second container through the namespace service; and The namespace service provides the process with a file descriptor associated with the second socket via the first socket. The file descriptor is associated with a third privilege that allows the process to access the network interface associated with the second namespace.

2. The system according to claim 1, wherein: The namespace service is coupled to the first and second namespaces via Unix domain sockets (UDS); and The second socket is an Internet Protocol (IP) socket.

3. The system according to claim 1, wherein, The request includes credentials associated with the process, and the operation further includes determining, at least in part, at the namespace service that the process needs to access the second container based on the credentials.

4. The system according to claim 1, wherein, The request includes an identifier for the second namespace and one or more attributes associated with the second socket.

5. The system according to claim 1, wherein, The second privilege includes root privileges associated with the computing device.

6. The system according to claim 1, wherein the operation further includes: Send a request to create the second socket from the namespace service to the second namespace; and The file descriptor associated with the second socket is received from the second namespace at the namespace service.

7. The system according to claim 1, wherein, The operation also includes receiving communication from the attached process via the second socket in the second namespace at the process.

8. A method comprising: Execute a process on a computing device that runs in a first container allocated to a first namespace, the first container being granted a first privilege that restricts the first container's access to the first namespace; A namespace service is executed on the computing device, and the namespace service is granted a second privilege that allows the namespace service to access the first namespace and the second namespace; The namespace service creates the first socket in the first container; The namespace service receives a request from the process via the first socket to create a second socket in a second container allocated to the second namespace. The second socket allows the process to access the second namespace from outside the second container without elevating the first privilege associated with the first process. The second socket is created in the second container through the namespace service; and The namespace service provides the process with a file descriptor associated with the second socket via the first socket. The file descriptor is associated with a third privilege that allows the process to access the network interface associated with the second namespace.

9. The method according to claim 8, wherein, The request includes credentials associated with the process, and also includes a determination at the namespace service, at least in part, based on the credentials, that the process needs to access the second container.

10. The method according to claim 8, wherein, The request includes an identifier for the second namespace and one or more attributes associated with the second socket.

11. The method according to claim 8, wherein, The second privilege includes root privileges associated with the computing device.

12. The method according to claim 8, further comprising: Send a request to create the second socket from the namespace service to the second namespace; and The file descriptor associated with the second socket is received from the second namespace at the namespace service.

13. The method of claim 8, further comprising receiving, at the process, communication from the attached process via the second socket in the second namespace.

14. The method according to claim 8, wherein: The namespace service is coupled to the first and second namespaces via Unix domain sockets (UDS); and The second socket is an Internet Protocol (IP) socket.

15. A method comprising: Execute a process on a computing device that runs in a first container allocated to a first namespace, the first container being granted a first privilege that restricts the first container's access to the first namespace; A namespace service is executed on the computing device, and the namespace service is granted a second privilege that allows the namespace service to access the first namespace and the second namespace; The namespace service creates the first socket in the first container; The process serves the namespace via the first socket and sends a request from the process to create a second socket in a second container allocated to the second namespace, the second socket allowing the process to access the second namespace from outside the second container without escalating the first privilege associated with the first process; and At the process, a file descriptor associated with the second socket and a third privilege is received from the namespace service via the first socket, the third privilege allowing the process to access the network interface associated with the second namespace.

16. The method according to claim 15, wherein, The first privilege includes access permissions that are more advantageous than the second privilege.

17. The method of claim 15, further comprising receiving, at the process, communication from the attached process via the second socket in the second namespace.

18. The method of claim 15, wherein: The namespace service is coupled to the first and second namespaces via Unix domain sockets (UDS); and The second socket is an Internet Protocol (IP) socket.

19. The method according to claim 15, wherein, The request includes credentials associated with the process, which include an indication that the process needs to access the second container.

20. The method of claim 15, further comprising receiving, at the process, communication via the second socket from an additional process running in the second container.

21. An apparatus comprising: A means for executing on a computing device a process running in a first container allocated to a first namespace, the first container being assigned a first privilege that restricts the first container's access to the first namespace; A means for performing a namespace service on the computing device, the namespace service being granted a second privilege that allows the namespace service to access the first namespace and the second namespace; A means for creating a first socket in the first container by the namespace service; A means for receiving, at the namespace service, a request from the process via the first socket to create a second socket in a second container allocated to the second namespace, the second socket allowing the process to access the second namespace from outside the second container without escalating the first privilege associated with the first process; A means for creating the second socket in the second container via the namespace service; and A means for providing a file descriptor associated with a second socket to the process from the namespace service via the first socket, the file descriptor being associated with a third privilege that allows the process to access a network interface associated with the second namespace.

22. The apparatus of claim 21, further comprising means for carrying out the method of claims 9 to 14.

23. An apparatus comprising: A means for executing on a computing device a process running in a first container allocated to a first namespace, the first container being assigned a first privilege that restricts the first container's access to the first namespace; A means for performing a namespace service on the computing device, the namespace service being granted a second privilege that allows the namespace service to access the first namespace and the second namespace; A means for creating a first socket in the first container by the namespace service; A means for serving the namespace via the first socket and sending a request from the process to create a second socket in a second container allocated to the second namespace, the second socket allowing the process to access the second namespace from outside the second container without escalating the first privilege associated with the first process; and A means for receiving, at the process, a file descriptor associated with the second socket and a third privilege from the namespace service via the first socket, the third privilege allowing the process to access a network interface associated with the second namespace.

24. The apparatus of claim 23, further comprising means for carrying out the method of any one of claims 16 to 20.

25. A computer program product or computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 8 to 20.

Images