Cascade signable article of container instances

Abstract

The invention relates to an article for instantiating and / or configuring a container instance of a container runtime environment, having:-at least one first parameter, the at least one first parameter having a first cryptographic signature,-at least one second parameter, the at least one second parameter having a second cryptographic signature, and-a clear description of at least one second parameter with respect to signatability by means of a second cryptographic signature, the at least one second parameter having no cryptographic signature, and / or the at least one second parameter being modifiable. The invention also relates to a container instance, a container runtime environment, and a method for creating an article for instantiation and / or configuration of a container instance of a container runtime environment.

Description

Technical Field

[0001] The present invention relates to an artifact for instantiation and / or configuration of a container instance of a container runtime environment. In addition, the present invention relates to an associated container instance, a container runtime environment, and a method for creating an artifact for instantiation and / or configuration of a container instance of a container runtime environment. Background Art

[0002] To provide integrity and authenticity protection to a container image and its container deployment configuration, both the container image and the container deployment configuration—both of which may also be generally referred to as “container artifacts”—may be signed.

[0003] In most container signing methods, the problem arises that the container image must be re-signed whenever it is copied to another registry, because the registry's Uniform Resource Locator (URL) is also included in the calculation of the signature. If in a containerized environment it is desired to provide containerized components at different registries (at the customers and at their customers), such signing methods can only be used to a limited extent, because an updated signing procedure is required at each registry, and the verification of the original information provided at the first registry (at the manufacturer or creator) is lost.

[0004] However, with the updated signature, a party that obtains the component and wants to process it further (in particular, wants to execute it on a runtime environment or incorporate it into further processing such as image creation) cannot check whether the container image provided in the downstream registry is authentic or has been modified by the operator of the downstream registry.

[0005] The same applies to operators of containerized Industrial IoT runtime environments (provided, for example, in edge devices) who want to identify that an application consisting of one or more container instances present on the device and in the container runtime environment actually came from the original creator.

[0006] There are various signing methods for container images, such as Notary Version 1, Notary Version 2, Cosign or Redhat Container Signature, which support signing of artifacts such as container images and deployment configurations and are also used in the container space. All of them use the basic principle that once an artifact is signed, it cannot be changed and must be re-signed after modification.

[0007] Notarization version 1, joint signatures, and Redhat container signatures are also based on the fact that the URL of the container image's registry - the origin location - is incorporated into the calculation of the signature.

[0008] Furthermore, the signatures in the case of notarization version 1, joint signatures and Redhat container signatures are not part of the signed artifact, but are stored externally and, for example, saved in a registry. If the signed artifact is relocated to another registry, an updated signing process must be performed, so that the original context of the build artifact, in particular the context of the container image or deployment configuration, will be lost.

[0009] In case of Notarization Version 2, the signature is an integral part of the image, so a so-called ORAS-Manifest is added to the container image. According to the Notarization Version 2 specification, it is also possible to explicitly define that specific areas of the artifact are excluded from the signature. Thus, repositioning of the image is possible, but tools such as notation for signature generation and verification do not provide the creator of the signature with the possibility to control which parameters of the build artifact will be incorporated into the signature calculation and which will not, so that when generating the signature, the scope of the integrity and authenticity protection cannot be defined, or multiple signatures covering different areas of the artifact (deployment configuration or container image) can be applied simultaneously.

[0010] The object of the present invention is to provide an artifact with improved integrity and authenticity for instantiation and / or configuration of container instances for a container runtime environment. Summary of the invention

[0011] The invention is derived from the features of the independent claims. Advantageous further developments and embodiments are the subject matter of the dependent claims. Embodiments, possible applications and advantages of the invention are apparent from the following description and the drawings.

[0012] The present invention relates to an article of manufacture for instantiation and / or configuration of a container instance of a container runtime environment, having: - at least one first parameter, wherein the at least one first parameter has a first cryptographic signature, - at least one second parameter, and - explicit information about at least one second parameter relating to the signability by means of a second cryptographic signature, wherein the at least one second parameter does not have a cryptographic signature, and / or Wherein the at least one second parameter is modifiable.

[0013] At least one second parameter does not have a cryptographic signature.

[0014] At least one second parameter is modifiable. "Modifiable" may also be referred to herein as "changeable". Thus, at least one second parameter can be changed in a downstream registry or by a user and / or customer. Thus, at least one second parameter is not specified by the manufacturer and is not controlled by the manufacturer.

[0015] Signability by the second cryptographic signature of the at least one second parameter means that the at least one second parameter can be signed by the at least one second cryptographic signature. This is explicitly specified for the article.

[0016] The unambiguous specification of the at least one second parameter can include further details about the at least one second parameter (name, position, reference). However, it is also explicitly stated according to the claims that the at least one second parameter can be signed.

[0017] The first encrypted signature may also be referred to as a “previous signature.” The second encrypted signature may also be referred to as a “subsequent signature.”

[0018] Therefore, a fundamental aspect of the invention is that the artifact to be created, in particular a deployment configuration or a container image: - can be signed multiple times by different entities, and - The creator of the preceding signature can control in that signature which areas of the artifact are allowed to change, since these parameters are not the basis of the signature.

[0019] Therefore, the present invention provides a signing method that enables a creator to provide an article that can be changed by a subsequent user in areas that have not been signed so far. The areas that can be changed by the subsequent user are defined by the creator. The areas that the creator has signed cannot be changed by the subsequent user. Therefore, the creator can limit the data that can be modified later. For the method of the present application, the previous creator of the article can specifically release areas of the article for subsequent processing steps, that is to say, they can be left unsigned. These areas can then be modified or extended and then signed by subsequent operators, thereby preventing further modifications.

[0020] In the sense of the present invention, a "region" is to be understood as metadata of an artifact, not a layer of a base image.

[0021] Furthermore, creators of containerized applications may also wish to be able to control which downstream registries the application can be made available to, since only registries that meet certain criteria are considered trustworthy. At the same time, these trusted downstream registries should allow certain information to be added or processed within the image (such as, in particular, defined image tags) in order to thereby enable customer-specific image parameterization to be performed on the downstream registries.

[0022] The same requirements also apply to deployment configurations, which, if necessary, refer to multiple signed images and should at the same time be modified and extended in specific parts by the operators of the individual registries in order to implement enterprise-specific security requirements within the central registry, in particular within industrial edge management, for example by assigning specific deployment information (e.g. tags or labels for providing meta-information or assigning or revoking specific privileges).

[0023] In summary, the present invention thus provides a solution that enables developers deploying configurations or container images to protect the integrity and authenticity of their applications across multiple downstream registries, and at the same time enables certain changes released by the developer within the downstream registries that can then also be verified on the runtime environment. This provides the possibility to improve the integrity and authenticity checking of the entire processing chain of container artifacts.

[0024] In an extension of the invention, at least one first cryptographic signature protects at least one first parameter from being modified. "Modification" may also be referred to as "change". Thus, at least one first parameter can no longer be changed in a downstream registry or by a user and / or customer. Thus, the at least one first parameter is established by the manufacturer and is controlled by the manufacturer.

[0025] In another embodiment of the present invention, there is no intersection between at least one first parameter and at least one second parameter. Intersection can also be referred to as overlap. Therefore, at least one first parameter and at least one second parameter are separate.

[0026] In another embodiment of the invention, the at least one first parameter and / or the at least one second parameter is designed as: - a univocal identifier, and / or - references, and / or - the initial URL, and / or -Container Image URI, and / or - the initial container image tag, and / or -Blob information, and / or -Container image tags.

[0027] In the case of container images, it is thus possible, for example, to define and also add an initial Uniform Resource Locator (URL) or an initial image tag and to create integrity and authenticity protection for the binary large object (BLOB) information provided therewith, but the specific image tags should be modified by the responsible integrator, for example, before archiving in a subsequent registry and should not be included in the signature calculation.

[0028] The unambiguous identifier is in particular designed as a container image label and / or a container image tag.

[0029] The reference to the layer to be signed is in particular designed as BLOB information.

[0030] The initial URL and / or the container image URL is a reference to the location of the image.

[0031] In a further development of the invention, at least one first cryptographic signature specifies at least one first parameter.

[0032] The creator of the container image signs his artifacts in his developer infrastructure, thus in his signing service, and in doing so specifies which regions should be included in the signature in order to calculate the signature.

[0033] Therefore, from at least one first encrypted signature, it is possible to infer what the first signature was formed from. Optionally, this can be stated directly in the metadata of the first signature.

[0034] Thus, the parameters to be signed are not initially specified in the artifact; instead, the parameters to be signed are predetermined by the creator of the first signature. Other restrictions - in particular conditions for further signatures or second signatures - are specified in the corresponding previous signatures after the initial signature (first signature) and / or in additional metadata introduced before the signing process, which in turn is signed.

[0035] In a further embodiment of the invention, the article and / or the at least one first cryptographic signature has: - metadata, wherein the metadata specifies the at least one first parameter, and The metadata has integrity protection and / or authenticity protection.

[0036] Therefore, which parameters were used to create the first signature are defined in the metadata of the signature, which metadata is likewise integrity and authenticity protected.

[0037] All signatures can be provided together within the artifact as part of the metadata, or can be stored externally - in particular in a database, on a web server, on a blockchain - or as in the case of already existing solutions in a code repository.

[0038] In a further development of the invention, the first cryptographic signature has a reference to at least one second parameter.

[0039] Thus, on the one hand, it is inferred from the previous signature, in particular when requirements such as nesting depth are specified, and on the other hand from parameter criteria stored locally by the signature creator, which parameters were combined for the calculation when creating the second signature of at least one second parameter.

[0040] Thus, the at least one second parameter is defined directly or indirectly by the at least one first cryptographic signature.The article itself has an explicit specification of the at least one second parameter.

[0041] In another embodiment of the invention, the product further comprises: - at least one data field having at least one first parameter, and / or - at least one second data area having at least one second parameter.

[0042] When at least one data area is signed, not only the parameters therein are signed, but also the entire data area - that is, possibly the entire part or a subset of the part - as long as this part has changeable areas for subsequent steps, which can be defined by previous signatures and / or in predecessor signatures.

[0043] In other words, therefore, at least one first parameter is possessed by a first data area of ​​the product and / or at least one second parameter is possessed by a second data area of ​​the product.

[0044] Due to the previous embodiment, there is no overlap between the first data area and the second data area.

[0045] In a further development of the invention, a signature depth value is assigned to the at least one second signature, wherein the signature depth value indicates the maximum possible number of signatures permitted for the article.

[0046] The "maximum possible number" may also be referred to as a "limited number". From this follows the specified upper limit of signatures and how often an artifact can be signed. This is specified in the metadata.

[0047] At the same time, there should also be the possibility that starting from a certain signature depth, various data can no longer be changed, in such a way that this is specified in the metadata of the signature, and there should also be the possibility that specific subsequent image URLs are restricted by the creator of the signature.

[0048] Alternatively or additionally, it can be defined that only certain subsequent signatures may be applied retroactively to an image, in particular by specifying a reference to the permitted subsequent signature metadata or to the issuing authority and by also storing a reference to the public key of the issuing authority.

[0049] It is also possible that a reference contains multiple possible key references, one of which must be satisfied in a subsequent step. In this case, if the metadata is specified so that it is always valid for the corresponding step, it can be additionally specified who must sign in each additional step. So, in step 2, the signature of a, b, or c; in step 3, the signature of c, d, or e, etc.

[0050] If signature depth is defined for parameter variability or sequencing is required, it is necessary for subsequent signing services that they do not have to re-sign the complete artifact (including the data protected by the initial signature), but only include the checksum of the previous signature in the calculation of the subsequent signature.

[0051] In another embodiment of the present invention, the product further comprises: - at least one third parameter, wherein the at least one third parameter can be signed by at least one third cryptographic signature.

[0052] It follows from this that at least one third parameter does not have a cryptographic signature and that at least one third parameter is modifiable.

[0053] In another embodiment of the invention, the product is configured as follows: - container deployment configuration, or -Container images.

[0054] Furthermore, the present invention comprises container embodiments based on the preparation according to the present invention.

[0055] Furthermore, the invention comprises a container runtime environment having at least one container instance according to the invention.

[0056] Furthermore, the present invention comprises a method for creating an artifact for instantiation and / or configuration of a container instance of a container runtime environment, having the following steps: - checking at least one first cryptographic signature signing the first parameter, - creating, based on the result of the checking, at least one second cryptographic signature signing the second parameter, The first parameter and the second parameter are possessed by a product according to one of the preceding claims.

[0057] The advantages of the method according to the invention are summarized as follows. The method allows the integrity and authenticity of artifacts such as deployment configurations and container images to be protected and at the same time allows: - in subsequent processing steps, changes to individual parameters and metadata that are not protected in terms of integrity and authenticity, - Restrictions on subsequent repositories.

[0058] If an expiration date is specified for the first or subsequent signatures, the method can also be limited in time for the defined repository. The expiration date can also be used in downstream repositories to actively look for new versions in the previous repository.

[0059] Furthermore, by means of the described approach, the provider of the artifact can more precisely restrict which modifications are allowed in the artifact or metadata in subsequent processing steps. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] The particularities and advantages of the present invention will become apparent from the following description of a number of embodiments according to the schematic drawings.

[0061] Figure 1 A flow chart showing sites involved in creating a signature, and Figure 2 A flow chart showing the process required to create a second signature. DETAILED DESCRIPTION

[0062] Figure 1 The flow is shown in which the creator of the container image 11 signs his artifact 11 in his developer infrastructure 1 in his signing service 12 and specifies which regions are to be included in the signature in order to calculate the signature.

[0063] An infrastructure 1 is provided at a developer's site, which includes an artifact 11 , in particular a container image 11 or a deployment configuration 11 , and a first signing service 12 , which is designed to create a first signature of at least one first parameter.

[0064] The article 11 is provided in a first registry 2 , in particular in an Industrial Edge Hub.

[0065] In this way, the artifact 11 arrives in the central customer-specific infrastructure 3. The latter contains an extended pipeline, in particular an extended pipeline of the customer's enterprise security team 31, and a second signature service 32 configured to create a second signature of at least one second parameter.

[0066] The artifact 11 is then provided in a second registry 4, in particular in a customer-specific containerized Industrial Internet of Things runtime environment.

[0067] A runtime environment 51 is provided in a device 5 in a secure customer environment. The runtime environment verifies and eventually executes the artifact 11.

[0068] Figure 2 The sequence required to create a second encrypted signature 12 is shown. If the parameters of a subsequent signature conflict with the integrity and authenticity protection requirements 11 of a preceding signature 8, 9, the creation of the subsequent signature is interrupted 13.

[0069] Specifically, in Figure 2 : After the start 6, the artifact to be signed is checked 7. It is checked whether the signature from the previous step exists 8. If yes, the previous signature is evaluated 9, wherein it is checked whether the parameters protected by the previous signature have been modified. If yes, the process ends 13. If no, the parameter criteria of the artifact are checked 11, then the signature is performed 12 and the method ends 12.

[0070] If there is no signature from the previous step (No) 8 , the parameter criteria of the artifact 11 are likewise checked, then the signature is performed 12 and the method ends 12 .

[0071] In this case, a specific embodiment is a signed Docker Compose file of an application for a containerized IIoT runtime environment, which is signed by the initial creator and then uploaded to a central registry, which is in particular provided on a central industrial edge hub or an independent application store. The creator defines in this case that, for example, the Docker Compose file is only allowed to be provided in a downstream registry of a specific customer and defines this in the metadata that the integrity and authenticity of the signature is secure. Various reference possibilities can be considered in this case. You can specify the DNS name directly It can be defined that subsequent signing must be performed by a private key issued by a specific certification authority. At the same time, as described above, it can also be provided that changes or additions of specific parameters are allowed only in the first downstream registry, which can be provided in particular on the industrial edge management system. These parameters can be specified directly or by specification of regular expressions within the metadata of the first signature. In subsequent signing instances, it is first checked whether the conditions defined in the previous signature are met and whether the previous signature is valid. By verifying the first signature, it is ensured that no other instances have performed unauthorized changes between the first signature and the signature now to be performed.

[0073] If multiple signatures are applied, they are verified by sequential verification. Incompatibilities due to incompatible modifications can arise either by the developer performing modifications including signed areas or other values, for example, by unauthorized modifications. In order to directly identify both modifications, it is recommended to verify in the same order in which they were applied.

[0074] If a parameter is changed in a processing step (modification + signing process) and this parameter does not change again in a subsequent processing step, the introduced parameter will also be included in the signature.

[0075] To prevent the creator of a signature from being able to remove the initial signature and thereby deactivate the original verification requirement, it is assumed that the end device performing the verification (container runtime environment or industrial edge device) has a defined trust store that defines which possible initial entry signatures the signed artifact (deployment configuration or image) must have.

[0076] To do this, the public signing key of the first registry (e.g., an app store or an industrial edge center) must be stored directly or authorized by the certification authority, and the certification authority's key must be stored so that verification can be performed.

[0077] If verification of the signature applied on the end device fails, execution of the deployment configuration or container image is rejected and an error message is output.

[0078] Since the previously signed instance can not only restrict changes to the artifact itself in the metadata of the subsequently signed instance (e.g. the creation of additional process permissions), the described method can also be used to ensure that only authorized downstream registry environments are allowed to obtain and distribute the dedicated version. If the runtime environment is assumed to be trusted, the execution authorization can also be limited in time by assigning corresponding metadata in the previous signing process, for example by specifying an expiration date in the metadata and the instance can no longer be restarted with the provided version.

[0079] In this case, for the described method, it is assumed that the verification component on the container runtime environment also verifies the metadata specified with the signature.

[0080] By providing an expiration date and ensuring its integrity and authenticity, it is also possible to define that a repository looks for newer versions in its parent repository at the latest after the defined expiration date and restrict distribution to subsequent repositories or runtime environments.

[0081] Although the present invention has been specifically described and illustrated through the embodiments, the present invention is not limited to the disclosed examples, and those skilled in the art may derive other variations without departing from the scope of protection of the present invention.

Claims

1. An article of manufacture for instantiation and / or configuration of a container instance of a container runtime environment, having: - at least one first parameter, wherein the at least one first parameter has a first cryptographic signature, - at least one second parameter, and - an explicit statement of the signability of at least one second parameter by means of a second cryptographic signature, wherein the at least one second parameter does not have a cryptographic signature, and / or Wherein the at least one second parameter is modifiable.

2. The product according to claim 1, Wherein the at least one first cryptographic signature protects the at least one first parameter from being modified.

3. The article according to any one of the preceding claims, There is no intersection between at least one first parameter and at least one second parameter.

4. The article according to any one of the preceding claims, The at least one first parameter and / or the at least one second parameter is configured as follows: - a univocal identifier, and / or - references, and / or - the initial URL, and / or -Container Image URI, and / or - the initial container image tag, and / or -Blob information, and / or -Container image tags.

5. The article according to any one of the preceding claims, Wherein the at least one first cryptographic signature specifies the at least one first parameter.

6. The article according to any one of the preceding claims, wherein the article and / or the at least one first cryptographic signature has: - metadata, wherein the metadata specifies the at least one first parameter, and The metadata has integrity protection and authenticity protection.

7. The article according to any one of the preceding claims, Wherein the first cryptographic signature has a reference to at least one second parameter.

8. The article according to any one of the preceding claims, In addition, it has: - at least one data field having at least one first parameter, and / or - at least one second data area having at least one second parameter.

9. The article according to any one of the preceding claims, Therein, a signature depth value is assigned to the at least one second signature, wherein the signature depth value indicates the maximum possible number of signatures permitted for the artifact.

10. The article according to any one of the preceding claims, Also features: - at least one third parameter, wherein the at least one third parameter can be signed by at least one third cryptographic signature.

11. The article according to any one of the preceding claims, The article is constructed as follows: - container deployment configuration, or -Container images.

12. A container example based on the article according to any one of the preceding claims.

13. A container runtime environment having at least one container instance according to claim 12.

14. A method for creating an artifact for instantiation and / or configuration of a container instance of a container runtime environment, The following steps are involved: - checking at least one first cryptographic signature signing the first parameter, - creating, based on the result of the checking, at least one second cryptographic signature signing the second parameter, The first parameter and the second parameter are possessed by the product according to any one of claims 1 to 13.

Images