TECHNICAL FIELD

The invention relates to methods, deployment servers, execution servers, computer programs and computer program products using a security module with a software container.

BACKGROUND

Recently, microservices have become a popular architecture to build modern Web services. Microservices are small modular services that are

independently deployable and independently executable. By breaking down a complex monolithic application into small independent microservices, it becomes possible to develop services that are more resilient to error and more scalable. For example, if a particular microservice would fail, it would not affect the entire service. However, if a component part of a monolithic service would fail, the entire service would have to be restarted. Also, the only way to scale a monolithic service is to duplicate the whole monolith by adding more instances of it. In a microservice based architecture on the other hand, only the services that need to be scaled need to be duplicated.

Software containers are commonly used to implement microservice-based architectures and make sure services can run independently of each other. In contrast to virtual machines, software containers are more lightweight and can instantly be started, similar to standard Unix processes, assuming the server has all images required to start the software container. An image is a container file containing a collection of files used to deploy the software container. The image can contain both program code and metadata, defining an initial state of the software container. Another advantage is that software containers provide a reliable execution environment allowing developers to develop and test their services locally on their machine and then upload the image to a cloud platform and still be sure the software containers behave similarly as running them locally. Docker is an example of a software container runtime that has recently gained popularity. By allowing container images to be stacked in a so-called union file system, container images can be distributed more efficiently.

When the software containers communicate with external entities, such as other software containers, this communication sometimes needs to be encrypted. However, it is cumbersome and inefficient to modify the affected software containers for encrypted communication when necessary.

SUMMARY

It is an object to provide software containers with a convenient and efficient way to implement secure communication.

According to a first aspect it is presented a method performed in a

deployment server, the deployment server being configured to deploy a software container. The method comprises the steps of: receiving a trigger to deploy a software container; obtaining an image intended for the software container comprising a set of at least one module; injecting a security module in the image; obtaining a container specification of the image, the container specification comprising information of at least one service exposed by the set of at least one module; configuring the security module to forward incoming communication to the set of at least one module in accordance with the obtained container specification; modifying the container specification such that the at least one service is accessed externally only via the security module and that all outgoing communication, from the set of at least one module, is directed via the security module; publishing the modified container specification in a service discovery repository; and deploying the software container on at least one execution server.

The method may further comprise the steps of: obtaining an identifier of the image; creating a credential for the image, the credential comprising a public key and a private key; publishing the public key in a distributed security repository; and providing the private key to the security module. The step of creating a credential may be performed in the security module. In this case, the method further comprises the steps of: providing an access token to the security module for enabling access to the distributed security repository. The method may further comprise the steps of: adding the identifier of the image to a container group of the distributed security repository; and providing an identifier of the container group to the security module.

The distributed security repository may be a blockchain database.

The service discovery repository may be a distributed peer-to-peer service discovery repository.

According to a second aspect it is presented a deployment server being configured to deploy a software container. The deployment server comprises: a processor; and a memory storing instructions that, when executed by the processor, cause the deployment server to: receive a trigger to deploy a software container; obtain an image intended for the software container comprising a set of at least one module; inject a security module in the image; obtain a container specification of the image, the container specification comprising information of at least one service exposed by the set of at least one module; configure the security module to forward incoming

communication to the set of at least one module in accordance with the obtained container specification; modify the container specification such that the at least one service is accessed externally only via the security module and that all outgoing communication, from the set of at least one module, is directed via the security module; publish the modified container specification in a service discovery repository; and deploy the software container on at least one execution server.

The deployment server may further comprise instructions that, when executed by the processor, cause the deployment server to: obtain an identifier of the image; create a credential for the image, the credential comprising a public key and a private key; publish the public key in a distributed security repository; and provide the private key to the security module.

The instructions to create a credential may be performed in the security module. In this case, the deployment server further comprise instructions that, when executed by the processor, cause the deployment server to:

provide an access token to the security module for enabling access to the distributed security repository.

The deployment server may further comprise instructions that, when executed by the processor, cause the deployment server to: add the identifier of the image to a container group of the distributed security repository; and provide an identifier of the container group to the security module.

The distributed security repository may be a blockchain database.

The service discovery repository may be a distributed peer-to-peer service discovery repository. According to a third aspect it is presented a deployment server comprising: means for receiving a trigger to deploy a software container; means for obtaining an image intended for the software container comprising a set of at least one module; means for injecting a security module in the image; means for obtaining a container specification of the image, the container

specification comprising information of at least one service exposed by the set of at least one module; means for configuring the security module to forward incoming communication to the set of at least one module in accordance with the obtained container specification; means for modifying the container specification such that the at least one service is accessed externally only via the security module and that all outgoing communication, from the set of at least one module, is directed via the security module;

means for publishing the modified container specification in a service discovery repository; and means for deploying the software container on at least one execution server. According to a fourth aspect it is presented a computer program comprising computer program code which, when run on a deployment server being configured to deploy a software container causes the deployment server to: receive a trigger to deploy a software container; obtain an image intended for the software container comprising a set of at least one module; inject a security module in the image; obtain a container specification of the image, the container specification comprising information of at least one service exposed by the set of at least one module; configure the security module to forward incoming communication to the set of at least one module in accordance with the obtained container specification; modify the container specification such that the at least one service is accessed externally only via the security module and that all outgoing communication, from the set of at least one module, is directed via the security module; publish the modified container specification in a service discovery repository; and deploy the software container on at least one execution server.

According to a fifth aspect it is presented a computer program product comprising a computer program according to the fourth aspect and a computer readable means on which the computer program is stored.

According to a sixth aspect it is presented a method for establishing a connection of between a local software container of a local execution server and a remote software container of a remote execution server. The method is performed in the local software container of the local execution server and comprising the steps of: receiving a request from the remote software container to establish a connection between the remote software container and the local software container, the request comprising an identifier of the remote software container; obtaining a public key of the remote software container from a distributed security repository using the identifier of the remote software container; validating the request using the public key of the remote software container; when the request is found to be valid, obtaining container group data from the distributed security depository, and

proceeding with connection establishment when both the remote software container and the local software container belong to the same container group.

The request may comprise an identifier of a container group to which the remote software container belongs. The step of validating may comprise validating the request by validating a signature of the request using a digital signature of the request.

The distributed security repository may be a blockchain database.

According to a seventh aspect it is presented an execution server for establishing a connection of between a local software container of the execution server, being a local execution server, and a remote software container of a remote execution server. The local execution server comprises: a processor; and a memory storing instructions that, when executed by the processor, cause the local execution server to: receive a request from the remote software container to establish a connection between the remote software container and the local software container, the request comprising an identifier of the remote software container; obtain a public key of the remote software container from a distributed security repository using the identifier of the remote software container; validate the request using the public key of the remote software container; and when the request is found to be valid, obtain container group data from the distributed security

depository, and proceeding with connection establishment when both the remote software container and the local software container belong to the same container group.

The request may comprise an identifier of a container group to which the remote software container belongs.

The step of validating may comprise validating the request by validating a signature of the request using a digital signature of the request.

The distributed security repository may be a blockchain database. According to an eighth aspect it is presented an execution server comprising: means for receiving a request from a remote software container of a remote execution server to establish a connection between the remote software container and a local software container of the execution server, being a local execution server, the request comprising an identifier of the remote software container; means for obtaining a public key of the remote software container from a distributed security repository using the identifier of the remote software container; means for validating the request using the public key of the remote software container; and means for, when the request is found to be valid, obtaining container group data from the distributed security depository, and proceeding with connection establishment when both the remote software container and the local software container belong to the same container group.

According to a ninth aspect it is presented a computer program for establishing a connection of between a local software container of an execution server, being a local server, and a remote software container of a remote execution server. The computer program comprises computer program code which, when run on the local execution server causes the local execution server to: receive a request from the remote software container to establish a connection between the remote software container and the local software container, the request comprising an identifier of the remote software container; obtain a public key of the remote software container from a distributed security repository using the identifier of the remote software container; validate the request using the public key of the remote software container; and when the request is found to be valid, obtain container group data from the distributed security depository, and proceeding with

connection establishment when both the remote software container and the local software container belong to the same container group.

According to a tenth aspect it is presented a computer program product comprising a computer program according to the ninth aspect and a computer readable means on which the computer program is stored. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is now described, by way of example, with reference to the accompanying drawings, in which:

Fig l is a schematic drawing illustrating an environment in which

embodiments presented herein can be applied;

Fig 2 is a schematic drawing illustrating one execution server of those shown in Fig l; Figs 3A-B are schematic drawings illustrating the use of a security module for incoming communication in a software container of Fig 2 according to one embodiment;

Figs 4A-B are schematic drawings illustrating the use of a security module for outgoing communication in a software container of Fig 2 according to one embodiment;

Figs 5A-B are flow charts illustrating embodiments of methods performed in the deployment server of Fig 1;

Fig 6 is a flow chart illustrating embodiments of a method performed in the execution server of Fig 2; Fig 7 is a flow chart illustrating embodiments of a method where a

configuration for two communicating software containers is created; Fig 8 is a schematic diagram illustrating components of the deployment server of Fig l;

Fig 9 is a schematic diagram illustrating components of the execution server of Fig 2; Fig 10 is a schematic diagram showing functional modules of the deployment server of Fig l according to one embodiment;

Fig 11 is a schematic diagram showing functional modules of the execution server of Fig 2 according to one embodiment; and

Fig 12 shows one example of a computer program product comprising computer readable means.

DETAILED DESCRIPTION

The invention will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout the description. Fig 1 is a schematic drawing illustrating an environment in which

embodiments presented herein can be applied.

There are here a number of execution servers 4a-e forming part of a set 8 of execution servers. While, in this example, there are eight execution servers 4a-e shown, the set 8 of execution servers can contain any suitable number of execution servers and the number can vary over time. Each one of the execution servers 4a-e can execute software containers when required, as described in more detail below. Each execution server can execute zero, one or more software containers (in parallel, when applicable). In this example, there is a first software container 2a in a first execution server 4a and a second software container 2b in a second execution server 4b. The first software container 2a and the second software container 2b can

communicate with each other when needed. According to embodiments here, the communication between the software container 2a, 2b can occur in a secure manner.

For instance, the software containers can be containers running on a Docker platform. The software containers are distributed as images being files (images are here not to be confused with illustrations/photographs). An image contains in itself a collection of files which are used to deploy the software container. The collection of files contains at least one module, being a software module, and optionally one or more specification documents. Moreover, a method called process injection is used to add additional modules into the image. As is explained in more detail below, the process injection is used to add a security module to images prior to deployment to thereby provide secure communication capability.

A deployment server 1 is used when a set of software containers are to be deployed. One image can be used for multiple instances of a software container. The deployment server 1 only needs to deploy (at least) one software container and a deployment configuration. Additional software containers of the same type can then optionally be deployed without further management by the software containers themselves. In other words, the deployment server 1 is needed for initial deployment of a new software container, but the number of concurrent instances running of a particular software container can optionally be managed by the software containers.

The set of execution servers 8 is organised in a decentralized peer-to-peer network, which can be implemented on an underlying network, such as an IP (Internet Protocol) network.

To provide the decentralized solution, this can be based on a Distributed Hash Table (DHT) algorithm, such as Kademlia, Chord or Pastry. Fig 2 is a schematic drawing illustrating one execution server 4 shown in Fig 1. The execution server 4 can be any of the execution servers 4a-e shown in Fig 1.

The execution server 4 contains zero, one or more software containers 2 which are executable by the execution server 4. When present, each software container 2 is a deployment based on an image and contains at least one original module 12 performing the desired function of the software container 2. Additionally, according to embodiments presented herein, a security module 13 has been injected in the software container to allow transparent secure communication to and from the at least one original module 12.

The software container 2 makes use of a service discovery repository 10 for its own discovery and for discovery of other software containers. The service discovery repository 10 can be implemented as a peer-to-peer repository, e.g. using DHT as described above. Moreover, a distributed security repository 11 can be used, e.g. for storing public keys of credentials, as described in more detail below. The distributed security repository 11 can be implemented as a tamper resistant database, e.g. a blockchain.

Now an embodiment of the peer-to-peer networks for the execution servers will be described based on Bitverse. Bitverse is a framework to build decentralized peer-to-peer application. Bitverse is based on the Kademlia DHT algorithm and provides a messaging API (Application Programming Interface) and a key value store API. In both APIs, self-generated SHA-i (Secure Hash Algorithm-i) strings are used to identify node end-points and data objects. Bitverse is thus a DHT implementation of a decentralised repository.

Bitverse consists of two different types of nodes, super nodes and edge nodes. Edge nodes are connected using web sockets to a super node and thus forms a star topology. An edge node can either run as a library in a web browser client or in an execution server component directly. Super nodes communicate using UDP (User Datagram Protocol). Messages are routed using a routing table provides by Kademlia. The routing table consists of 160 buckets where each bucket contains a limited list of contacts (typically 20) discovered by the super node. XOR (Exclusive OR) is used to determine the distance between two different nodes in the network and which bucket a contact should be stored in. This makes it possible to implement an iterative protocol where a node calculates which contacts in its routing table that has the shortest distance to a particular string, or the SHA- 1 of the string to be more specific. These contact are then queries until there are no more nodes to query. This makes it possible to find the nodes in the whole network that has the shortest distance to a particular string. Like all DHTs, this procedure is very efficient, typically 0(log n) messages need to be sent, where is n is the number of nodes in the network and O denotes order.

By calculating a SHA-i of the key it becomes possible to calculate which nodes in the network a particular key-value pair should be stored, and thus implement a distributed data repository where data is replicated in the network. In Bitverse, the value is represented as an unordered set, which makes it possible to store multiple values associated with a specific key. This special key-value(s) pair is called a SetMap. Below is an example of SetMap storing 5 values, identified by the key "hello".

"hello" => {value2, valuei, values, value4, values}

The SetMap provides a simple API, for example setmap = bitverse.getSetMapC'hello") setMapAddValue("value6") It is also possible to set a time-to-live (TTL) on a value stored in a SetMap, e.g. setMapAddValueTTLC'mykey", "value/', 2) In this case, valuez is automatically purged after 2 seconds. The TTL mechanism can optionally be combined with a tracking mechanism where a client is notified when a value is added or removed to implement service discovery. If a client stops adding a specific value with a TTL, the value will automatically be purged when the TTL expired, thus causing a tracking event to other clients which can then take appropriate actions. This is one mechanism which can be used by the lifecycle mechanism described below.

The SetMap is also used internally in Bitverse to provide a messaging service. When an edge node connects to a super node, the super node will store the IP number and UDP port of the super node as a value in a SetMap, where the self-generated SHA-i identity of the edge node is used as a key. This makes it possible for an edge node to send messages to any other edge node in the network, by allowing the super nodes to use the information stored in the SetMap to set up tunnels between different super nodes. Below is an example of a messaging API call to send a message to a remote edge node, where 4cd7ei8o4bad563d32a4i6dfsf9i5eft>boi3ee6f is the address of the remote edge node. bitverse.sendMessageC'4cd7ei8o4bad563d32a4i6df5f9i5efbboi3ee 6f', "hello") The message is sent to edge node's local super node, which will tunnel the message to a foreign super node where the remote edge node is connected, assuming the remote edge is not directly connected to the local super node. In this case, the message can be send directly without using a tunnel link.

Figs 3A-B are schematic drawings illustrating the use of a security module for incoming communication in a software container 2 of Fig 2 according to one embodiment. Fig 3A illustrates incoming communication according to the prior art. The at least one original module 12 of the software container receives incoming communication 20, e.g. from a remote software container. Looking now to Fig 3B, the security module 13 first receives encrypted incoming communication 20'. The encrypted incoming communication 20' is decrypted by the security module 13 to decrypted incoming communication 20 (same as in Fig 3A) and provided to the at least one original module 12. In this way, encrypted communication is enabled without requiring any modification to the at least one original module 12.

Figs 4A-B are schematic drawings illustrating the use of a security module for outgoing communication in a software container of Fig 2 according to one embodiment. Fig 4A illustrates outgoing communication according to the prior art. The at least one original module 12 of the software container sends outgoing communication 22, e.g. to a remote software container.

Looking now to Fig 4B, the security module 13 first receives the outgoing communication 22. The outgoing communication 22 (same as in Fig 3A) is encrypted by the security module 13 to encrypted outgoing communication 22' and is sent to the receiver. In this way, encrypted communication is enabled without requiring any modification to the at least one original module 12.

The communication shown in Figs 3B and 4B are combined to provide transparent secure communication for the software container 2. In this way, secure communication can be provided for all communication to and from the software container 2, which can be usable in what is called zero trust. In zero trust, no communication network is assumed to be safe, whereby all communication is encrypted. Using the embodiments presented herein, this is achieved without placing a burden on the application developer, since the encryption and decryption is achieved transparently using the security module.

Figs 5A-B are flow charts illustrating embodiments of methods performed in the deployment server of Fig 1. As explained above, the deployment server is configured to deploy a software container. In a receive deployment trigger step 40, a trigger to deploy a software container is received. This can be a deployment message commanding a particular software container is to be deployed using the one or more execution servers. In an obtain software container step 42, an image intended for the software container is obtained. The image is a file system which comprises a set of at least one module.

In an inject security module step 44, a security module in the image is injected, e.g. illustrated by the security module 13 forming part of the software container 2 of Fig 2.

In an obtain software specification step 46, a container specification of the image is obtained. The container specification can e.g. be obtained from the distributed security repository (11 of Fig 2). The container specification comprises information of at least one service exposed by the set of at least one module. The container specification describes the services that the software container offers and the remote services which are intended to be consumed. Moreover, the container specification can include a remote network address intended to be used to contact each such remote service. The remote network address can be a virtual address, i.e. a placeholder address which is replaced by a proper address at a later stage.

In a configure security module step 47, the security module is configured to forward incoming communication to the set of at least one module in accordance with the obtained container specification. Moreover, the security module can be configured in accordance with expected outgoing

communication of the set of at least one module.

In a modify container specification step 48, the container specification is modified such that the at least one service is accessed externally only via the security module and that all outgoing communication, from the set of at least one module, is directed via the security module. In a. publish container specification step 60, the modified container specification is published in a service discovery repository. As explained above, the service discovery repository can be a distributed peer-to-peer service discovery repository. In a deploy software container step 62, the software container is deployed on at least one execution server.

Looking now to Fig 5B, only new or modified steps compared to the methods illustrated by Fig 5A will be described.

In an optional provide access token step 50, an access token is provided to the security module for enabling access to the distributed security repository. As explained above, the distributed security repository may be a blockchain database.

In an optional obtain identity of the software container step 51, an identifier of the image is obtained. This identity can be generated, obtained from the image or it can be retrieved from a local or remote storage.

In an optional create credential step 52, a credential for the image is created. The credential comprises a public key and a private key. When the provide access token step 50 is performed, the create credential step 52 is performed in the security module. In an optional publish public key step 54, the public key is published in a distributed security repository, in association with the identity of the software container to allow the public key to be found.

In an optional provide private key step 55, the private key is provided to the security module. The private key can later be used for decrypting

communication encrypted using the public key.

In an optional add id (identifier) of software container to group step 56, the identifier of the image is added to a container group of the distributed security repository. In an optional provide group id step 58, an identifier of the container group is provided to the security module.

Fig 6 is a flow chart illustrating embodiments of a method performed in the execution server of Fig 2. The method is performed for establishing a connection of between a local software container of a local execution server and a remote software container of a remote execution server. The method is performed in the local software container of the local execution server. More specifically, the method can be performed in the security module which has been injected in the software container in accordance with the methods described above with reference to Figs 5A-B.

In a receive connection request step 140 a request is received from the remote software container to establish a connection between the remote software container and the local software container. The request comprises an identifier of the remote software container. Optionally, the request comprises an identifier of a container group to which the remote software container belongs.

In an obtain public key of remote container step 142, a public key of the remote software container is obtained from a distributed security repository using the identifier of the remote software container. As explained above, the distributed security repository can be a blockchain database. For instance, the distributed security repository can be based on Apache Hyperledger. Nevertheless, it is possible to implement the distributed security repository using other blockchain implementations and also conventional approaches with servers linked by a distributed consensus protocol. However, a blockchain-based approach has the added benefit of an immutable history of actions and transactions in the system and can thus be viewed as a tamper resistant database in which no party alone can manipulate data without consensus from other parties. The transaction history also creates traceability and transparency without exposing sensitive security information. l8

In a conditional valid request step 144, it is determined whether the request is valid using the public key of the remote software container. This

determination is e.g. based on validating a signature of the request using a digital signature of the request. If the request is valid, the method proceeds to a conditional same group step 146. Otherwise, the method ends.

In the conditional same group step 146, container group data is obtained from the distributed security depository. It is then determined whether both the remote software container and the local software container belong to the same container group. If this is the case, the method proceeds to an establish connection step 148. Otherwise, the method ends.

In the establish connection step 148, a connection is established. The connection is a connection between the local software container of the local execution server and the remote software container of the remote software container. Fig 7 is a flow chart illustrating embodiments of a method where a

configuration for two communicating software containers is created.

In a create user step 200, a user U account is created. This can only be done by the system owner, e.g. the owner of the distributed security depository. The public part (self-generated identifier + public key) of the credentials for user U is stored in the distributed security depository, while user U stores the private part of the key locally. The key generation is done by the client so the private key is never sent to the distributed security depository.

In an assign account to deployment server step 202, the deployment server, hereinafter denoted deployer, is assigned an account, i.e. a self-generated identifier and a public-private key pair. The identifier and the associated public key is published to the distributed security depository similar to the procedure described in the create user step 200.

In a create group step 204, user U employs his private credentials to create a group G, which a policy document stores in the distributed security depository. The policy document is also assigned a self-generated identifier. The group G also contains identifiers of all components that are allowed to communicate and optionally additional policies regulating the components behaviour within the group. User £7 also adds the deployer to group G (i.e. the identifier of the deployer is added to the policy document). User £7 then delegates group modification capabilities by adding a rule granting the deployer the rights to add new container identifiers to group G belonging to the same application. Finally, user U also adds a default rule stating how software containers are allowed to communicate, for example a policy stating that all software containers belonging to the same group is allowed to communicate with each other.

In a create credentials step 206, when a software container is deployed by the deployer, it first creates a credential for the security module of the software container. Similar to steps 200 and 202, the public part of the credential (self-generated identifier + public key) is published to the distributed security depository. The deployer also configures the security module of the software container to connect to the distributed security depository. Alternatively, the security module of the software container could create its own credential but in this case the deployer must pass a token to the security module allowing it to access the distributed security depository. The identifier of the spawned software container is passed back to the deployer, which then adds it to group G. The deployer also notifies the security module of the software container which group it belongs to.

Two software containers, Ci and C2 are spawned according to the procedure described for the create credentials step 206.

In an initialise connection step 208, when a connection is established from Ci to C2, the first part of the communication is an initialisation message sent by Ci to C2 that contains the identifier of Ci as well as the identifier of group G. The message is also signed with the private key of Ci. When the message is received by software container C2, the identity of Ci is verified by getting the public key associated with Ci from the distributed security depository and then verifying the signature using the downloaded public key. If distributed security depository is implemented using blockchain technologies, nobody except Ci can modify the published public key once it has been stored in the distributed security depository. In a verify group and policy step 2io,the identity of Ci is now confirmed. Next, it is checked if C2 belongs to the same group as Ci and enforce defined policies. The security module running on Ci now downloads the policy document describing group G from the distributed security depository.

Communication between C2 and Ci is only allowed if C2 can confirm the presence of both Ci and C2 in group G. Additionally, C2 enforces any additional policies stored in group G if such are present. Note that group G can only by manipulated by sending a message to the distributed security depository and signing the message with the private key of user U or an entity with delegated responsibility by user U. Note that C2 trusts Ci since C2 knows that only user U (or an entity with responsibility delegated by user U) can add Ci to group G, which C2 also belongs to.

Using the embodiments presented herein, secure communication between software containers is achieved without additional strain on the developer of the original modules to implement the security layer. Also, by providing the transparent security layer for all communication, software containers can run across several platforms at the same time, for exampling using containers on both Docker and Kubernetes hosts spread across different data centres, which makes it suitable for distributed cloud environments such as edge computing. The solution works with any kind of applications running inside the software container, regardless of programming language; without adaptation.

Fig 8 is a schematic diagram illustrating components of the deployment server 1 of Fig 1. A processor 60 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor,

microcontroller, digital signal processor (DSP), application specific integrated circuit etc., capable of executing software instructions 67 stored in a memory 65, which can thus be a computer program product. The processor 60 can be configured to execute the methods described with reference to Figs 5A-B above.

The memory 65 can be any combination of read and write memory (RAM) and read only memory (ROM). The memory 65 also comprises persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

A data memory 66 is also provided for reading and/or storing data during execution of software instructions in the processor 60. The data memory 66 can be any combination of read and write memory (RAM) and read only memory (ROM).

The deployment server 1 further comprises an I/O interface 62 for

communicating with other external entities, e.g. execution servers. Other components of the deployment server 1 are omitted in order not to obscure the concepts presented herein.

Fig 9 is a schematic diagram illustrating components of the execution server 4 of Fig 2. A processor 160 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit etc., capable of executing software instructions 167 stored in a memory 165, which can thus be a computer program product. The processor 160 can be configured to execute the method described with reference to Fig 6 above.

The memory 165 can be any combination of read and write memory (RAM) and read only memory (ROM). The memory 165 also comprises persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. A data memory 166 is also provided for reading and/or storing data during execution of software instructions in the processor 160. The data memory 166 can be any combination of read and write memory (RAM) and read only memory (ROM). The execution server 4 further comprises an I/O interface 162 for

communicating with other external entities, e.g. a deployment server.

Other components of the execution server 4 are omitted in order not to obscure the concepts presented herein.

Fig 10 is a schematic diagram showing functional modules of the deployment server 1 of Fig 1 according to one embodiment. The modules are implemented using software instructions such as a computer program executing in the deployment server 1. Alternatively or additionally, the modules are

implemented using hardware, such as any one or more of an ASIC

(Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits. The modules correspond to the steps in the methods illustrated by Figs 5A-5B.

A receiver 70 corresponds to step 40. An obtainer 71 corresponds to steps 42, 46 and 51. An injector 72 corresponds to step 44. A modifier 73 corresponds to step 48. A publisher 74 corresponds to steps 54 and 60. A deployer 75 corresponds to step 62. A configurer 76 corresponds to step 47. A provider 77 corresponds to steps 50, 55 and 58. A credential creator 78 corresponds to step 52. A group adder 79 corresponds to step 56.

Fig 11 is a schematic diagram showing functional modules of the execution server 4 of Fig 2 according to one embodiment. The modules are

implemented using software instructions such as a computer program executing in the execution server 4. Alternatively or additionally, the modules are implemented using hardware, such as any one or more of an ASIC

(Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or discrete logical circuits. The modules correspond to the steps in the methods illustrated by Fig 6. A receiver 170 corresponds to step 140. An obtainer 172 corresponds to step 142. A validator 174 corresponds to step 144. A group checker 176

corresponds to step 146. A connection establisher 178 corresponds to step 148. Fig 12 shows one example of a computer program product comprising computer readable means. On this computer readable means a computer program 91 can be stored, which computer program can cause a processor to execute a method according to embodiments described herein. In this example, the computer program product is an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. As explained above, the computer program product could also be embodied in a memory of a device, such as the computer program product 65 of Fig 8 or the computer program product 165 of Fig 9. While the computer program 91 is here schematically shown as a track on the depicted optical disk, the computer program can be stored in any way which is suitable for the computer program product, such as a removable solid state memory, e.g. a Universal Serial Bus (USB) drive.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.