Artefact of a container instance, which artefact is signable in a cascaded manner

Abstract

The invention relates to an artefact for instantiating and / or configuring a container instance for a container runtime environment, comprising: - 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 specification of the at least one second parameter with regard to signability using 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. The invention also relates to a container instance, to a container runtime environment and to a method for creating an artefact for instantiating and / or configuring a container instance for a container runtime environment.

Description

[0001] Description

[0002] Cascaded signable artifact of a container instance

[0003] BACKGROUND OF THE INVENTION

[0004] Field of the invention

[0005] The present invention relates to an artifact for instantiating and / or configuring a container instance for a container runtime environment. The invention also relates to an associated container instance, a container runtime environment, and a method for creating an artifact for instantiating and / or configuring a container instance for a container runtime environment.

[0006] Description of the state of the art

[0007] To container images and their container depolyment

[0008] To provide the configuration with integrity and authenticity protection, both container images and the container deployment configuration, generally both can also be referred to as a container artifact, can be signed.

[0009] Most container signing procedures have the problem that container images must be re-signed if they are copied to another registry, because the registry's Uniform Resource Locator (URL) is included in the signature calculation. If you want to deploy containerized components in a containerized environment in different registries (at the customer's and their customers'), such signing procedures are of limited use, because a new signing process is required in each registry, and the validation of the original information provided in the first registry (at the manufacturer or creator's) is lost.However, by re-signing, the person who receives a component and wants to process it further (in particular by executing it on a runtime environment or integrating it into further processing steps such as image creation) cannot verify whether the container images provided in a downstream registry are authentic or have been modified by the operator of the downstream registry.

[0010] The same applies to the operator of a containerized industrial IoT runtime environment (which is provided, for example, on an edge device) who wants to recognize that the app on the device and in a container runtime environment consisting of one or more container instances actually comes from the original creator.

[0011] Various signature methods exist for container images, such as Notary Version 1, Notary Version 2, Cosign, or Redhat Container Signing, which support the signature of artifacts such as container images and deployment configurations and are also used in the container environment. All of them use the basic principle that once an artifact is signed, it is immutable and must be re-signed after any changes have been made.

[0012] Notary Version 1, Cosign and Redhat Container Signing are additionally based on the fact that the URL of the registry, i.e. the original location, of a container image is included in the calculation of the signature.

[0013] In addition, the signatures in Notary Version 1, Cosign and Redhat Container Signing are not part of the signed artifact, but are outsourced and stored externally, for example, in a registry. If the signed artifact is relocated to another registry, a new signature process must be performed, meaning that the original context of the build artifact, in particular the container image or the deployment configuration, is lost. In Notary v2, the signature is part of the image and is therefore added to the container image as a so-called ORAS manifest. According to the Notary v2 specification, it is also explicitly possible to define that certain areas of an artifact should be excluded from the signature.Relocation of the image is thus possible, but tools such as notation for signature generation and validation do not offer the signature creator any possibility of controlling which parameters of a build artifact should be included in the signature calculation and which should not, so that when creating a signature the scope of the integrity and authenticity assurance cannot be defined or several signatures can be applied simultaneously which refer to different areas of the artifact (deployment configuration or container image).

[0014] The object of the invention is to provide an artifact for instantiating and / or configuring a container instance for a container runtime environment that is improved in terms of integrity and authenticity.

[0015] SUMMARY OF THE INVENTION

[0016] The invention is based on the features of the independent claims. Advantageous developments and refinements are the subject of the dependent claims. Refinements, possible applications, and advantages of the invention will become apparent from the following description and the drawings.

[0017] The invention relates to an artifact for instantiating and / or configuring a container instance for a container runtime environment, comprising:

[0018] - at least one first parameter, wherein the at least one first parameter has a first cryptographic signature, - at least one second parameter, and

[0019] - an explicit specification of the at least one second parameter with regard to signability by 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.

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

[0021] The at least one second parameter is modifiable. Modifiable here also means changeable. The at least one second parameter is thus changeable in a downstream registry or by a user and / or customer. The at least one second parameter is therefore not specified by the manufacturer and is not subject to its control.

[0022] The signability of the at least one second parameter by the second cryptographic signature means that the at least one second parameter can be signed by at least one second cryptographic signature. This is explicitly specified for the artifact.

[0023] The explicit specification of the at least one second parameter may contain further details about the at least one second parameter (name, location, reference). However, according to the claim, it is also explicitly stated that the at least one second parameter can be signed.

[0024] The first cryptographic signature can also be referred to as the preceding signature. The second cryptographic signature can also be referred to as the succeeding signature.

[0025] A fundamental aspect of the invention is therefore that an 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 previous signature can control within this which areas of the artifact may be changed, since these parameters are not the basis of the signature.

[0026] The invention thus provides a signature method which enables a creator to provide an artifact which can be modified by a subsequent user in the previously unsigned areas. The areas which can be modified by the subsequent user are defined by the creator. Areas which the creator has already signed cannot be modified by the subsequent user. The creator can thus restrict the data which can be modified subsequently. For the method of the present application, a previous creator of the artifact can specifically release areas of artifacts for subsequent process steps, i.e. leave them unsigned. These areas can then be modified or expanded, then signed by subsequent processors and thus protected from further modification.

[0027] In the context of the present invention, areas are understood to mean metadata of the artifact, but not layers of a base image.

[0028] Furthermore, the creator of a containerized application may also want to be able to control which downstream registries an app may be deployed to, since only registries that meet certain criteria are considered trustworthy. At the same time, these trusted downstream registries should allow certain information (such as defined image tags) to be added or edited within an image, thus enabling customer-specific parameterization of the images in a downstream registry.

[0029] The same requirement also applies to a deployment configuration, which may reference several signed images and at the same time is to be modified and extended in certain sections by the operators of individual registries, so that, for example, within a central registry, in particular an Industrial Edge Management, company-specific security requirements can be enabled by assigning certain deployment information such as tags or labels to provide meta information or to assign or revoke certain privileges.

[0030] In summary, the invention thus provides a solution that enables a developer of a deployment configuration or a container image to secure the integrity and authenticity of their app across multiple downstream registries and, at the same time, to allow certain changes approved by the developer within the downstream registries, which can then also be validated in the runtime environment. This provides an opportunity for improved integrity and authenticity verification across the processing chain for the container artifacts.

[0031] In a further development of the invention, the at least one first cryptographic signature protects the at least one first parameter against modification. The modification can also be referred to as a change. The at least one first parameter can therefore no longer be changed in a downstream registry or by a user and / or customer. The at least one first parameter is therefore specified by the manufacturer and is subject to their control. In a further development of the invention, there is no overlap between the at least one first parameter and the at least one second parameter. The overlap can also be referred to as an overlap. The at least one first parameter and the at least one second parameter are thus separate.

[0032] In a further development of the invention, the at least one first parameter and / or the at least one second parameter are designed as:

[0033] - a unique identifier and / or

[0034] - a reference and / or

[0035] - an initial uniform resource locator and / or

[0036] - a container image uniform resource locator and / or

[0037] - an initial container image tag and / or

[0038] - a Binary Large Object Information and / or

[0039] - a container image label.

[0040] For a container image, it can be defined, for example, that the initial uniform resource locator (URL) or the initial image tag is added and an integrity and authenticity assurance of the supplied binary large object (BLOB) information is created, but special image labels, for example, are changed by the responsible integrator before being stored in subsequent registries and these should not be included in the signature calculation.

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

[0042] The reference for the layer to be signed is specifically configured as BLOB information. The initial Uniform Resource Locator and / or the container image Uniform Resource Locator are references to the location of the image.

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

[0044] The creator of a container image signs his artifact in his signature service in his developer infrastructure and specifies which areas should be included in the signature for calculating the signature.

[0045] Thus, the at least one first cryptographic signature can be used to determine what the first signature is based on. Alternatively, this can be specified directly in the metadata of the first signature.

[0046] Thus, parameters to be signed are not initially specified in the artifact; instead, the parameters to be signed are specified by the creator of the first signature. Further restrictions, particularly conditions for additional signatures or the second signature, are specified after an initial signature—the first signature—in the respective preceding signatures and / or in additional metadata introduced before the signing process, which are also signed.

[0047] In a further development of the invention, the artifact and / or the at least one first cryptographic signature comprises:

[0048] - Metadata, wherein the metadata specifies the at least one first parameter, and wherein the metadata has integrity protection and / or authenticity protection. The parameters used to create the first signature are thus defined in the signature's metadata, which are also integrity- and authenticity-protected.

[0049] All signatures can either be included within the artifact as part of the metadata or stored externally, in particular in a database, on a web server, a blockchain - or, as with existing solutions, within a code repository.

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

[0051] “Which parameters are included in the calculation when creating the second signature of the at least one second parameter is thus derived on the one hand from the previous signature, in particular if requirements such as a nesting depth are specified, and on the other hand from a parameter guideline stored locally by the creator of the signature, possibly artifact-specific.

[0052] The at least one second parameter is thus defined directly or indirectly by the at least one first cryptographic signature. The artifact itself contains the explicit specification of the at least one second parameter.

[0053] In a further development of the invention, the artifact also has:

[0054] - at least one data area comprising at least one first parameter and / or

[0055] - at least one second data area, comprising the at least one second parameter.

[0056] If at least one data area is signed, not only one parameter from it is signed, but the entire data area, i.e. if necessary the entire section or a subset of the section, provided that this has changeable areas for the subsequent steps, which can be defined via and / or in the previous signatures.

[0057] In other words, the at least one first parameter is exhibited by the first data area of ​​the artifact and / or at least one second parameter is exhibited by the second data area of ​​the artifact.

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

[0059] 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 a maximum possible number of signatures permitted for the artifact.

[0060] The maximum possible number can also be described as a limited number. This results in a fixed upper limit on the number of signatures and how often the artifact can be signed. This is specified in the metadata.

[0061] At the same time, it should also be possible for various data to no longer be changed beyond a certain signature depth by specifying this in the signature metadata and also for the possibility of restricting certain subsequent image URLs by the creator of the signature.

[0062] Alternatively or additionally, it can be defined that only certain subsequent signatures may be subsequently added to an image, in particular by specifying a reference to the permissible subsequent signature metadata or the issuing certification authorities, as well as by further storing a reference to the public keys of the issuing certification authorities. The reference could also contain several possible key references, one of which must be fulfilled in the subsequent steps. In this case, it could also be prescribed in each further step who must sign, if the metadata is specified in such a way that it is always valid for the respective steps. So in step 2 signatures of a, b or c, step 3 signatures of c, d or e, etc.

[0063] If signature depths are defined for the variability of parameters or the order is required, it is necessary for the subsequent signature services that they do not have to re-sign the entire artifact including the data protected by the initial signature, but only have to include the checksum of the previous signature in the calculation of the subsequent signature.

[0064] In a further development of the invention, the artifact also has:

[0065] - at least one third parameter, wherein the at least one third parameter can be signed by at least one third cryptographic signature.

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

[0067] In a further development of the invention, the artifact is as:

[0068] - A container deployment configuration or

[0069] - a container image is created.

[0070] The invention further comprises a container instance based on an artifact according to the invention. The invention further comprises a container runtime environment comprising at least one container instance according to the invention.

[0071] The invention also comprises a method for creating an artifact for instantiating and / or configuring a container instance for a container runtime environment, comprising the steps of:

[0072] - checking at least a first cryptographic signature which signs a first parameter,

[0073] - depending on a result of the checking, creating at least one second cryptographic signature which signs a second parameter, wherein the first parameter and the second parameter are provided by an artifact according to one of the preceding claims.

[0074] The advantages of the method according to the invention are summarized below. The method allows for integrity assurance and authenticity assurance of artifacts such as deployment configurations and container images and simultaneously allows:

[0075] - The modification of individual parameters and metadata that are not secured for integrity and authenticity in subsequent processing steps

[0076] - The restriction to subsequent repostories .

[0077] If an expiration date is specified for the first or a subsequent signature, the process can also be limited to defined repositories. The expiration date can also be used to actively check for new versions in the previous repositories within the downstream repositories.

[0078] Using the procedure described, the provider of an artifact can also more precisely restrict which changes are permitted in subsequent processing steps in the artifacts or metadata.

[0079] BRIEF DESCRIPTION OF THE DRAWINGS

[0080] The special features and advantages of the invention will become apparent from the following explanations of several embodiments based on the schematic drawings.

[0081] It shows

[0082] Fig. 1 is a flow chart showing the stations involved in creating the signature and

[0083] Fig. 2 is a flow diagram of the process required to create a second signature.

[0084] DETAILED DESCRIPTION OF THE INVENTION

[0085] Fig. 1 shows a process in which the creator of a container image 11 signs his artifact 11 in his developer infrastructure 1 in his signature service 12 and in doing so specifies which areas are to be included in the signature for calculating the signature.

[0086] A deployment infrastructure 1 at the developer, this contains 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 the first signature of the at least one first parameter.

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

[0088] The artifact 11 thus enters a central customer-specific infrastructure 3. This contains an extension pipeline, in particular a corporate security team 31 of the customer, and a second signing service 32, which is designed to create the second signature of the at least one second parameter.

[0089] The artifact 11 is then provided in a second registry 4 , in particular a customer-specific containerized industrial IoT runtime environment.

[0090] A runtime environment 51 is provided on a device 5 in a secure customer environment. This environment then validates and executes 52 the artifact 11.

[0091] Fig. 2 shows the process required to create a second cryptographic signature 12. If the parameters of the subsequent signature conflict with the integrity and authenticity assurance specifications 11 of the previous signature 8, 9, the creation of the subsequent signature is aborted 13.

[0092] Specifically, Fig. 2 shows: After the start 6, the artifact 7 to be signed is examined. A check is made to see whether signatures from previous steps are present 8. If yes, the predecessor signature 9 is evaluated, and a check is made to see whether the parameters protected by the predecessor signature have already been modified. If yes, the process is terminated 13. If no, the parameter policy of the artifact is checked 11, then the signature is executed 12 and the process is terminated 12.

[0093] If no (n) signatures from previous steps are present 8 , the parameter policy of the artifact 11 is also checked, then the signature is performed 12 and the process is terminated 12 .

[0094] A concrete example of this would be a Docker Compose file to be signed for an app in a containerized industrial IoT runtime environment. This file is signed by the initial creator and then uploaded to a central registry, which can be provided, in particular, on a central industrial edge hub or a standalone app store. The creator defines, for example, that the Docker Compose file may only be made available in downstream registries of a specific customer and defines this in the integrity- and authenticity-assured metadata of the signature. Various reference options are conceivable here.

[0095] • The DNS name can be specified directly

[0096] • It can be defined that the subsequent signature must be performed by a private key issued by a specific certification authority

[0097] At the same time, as described above, it can also be specified that certain parameters may only be changed or added in the first downstream registry, which can in particular be provided on an Industrial Edge Management system. These parameters can be specified either directly or via the specification of regular expressions within the metadata of the first signature. In the subsequent signature instance, a check is first carried out to determine whether the conditions defined in the previous signature are met and whether the signature is valid. Validating the first signature ensures that no further instance has made unauthorized changes between the first signature and the signature to be made now.

[0098] If multiple signatures are applied, they are validated one after the other. Incompatibilities due to incompatible modifications can arise if a developer makes modifications that include areas that have already been signed, or if other values ​​are modified, e.g. through unauthorized modifications. In order to detect both modifications directly, it is recommended that they be validated in the same order in which they were applied. If a parameter is changed in one processing step (modification + signature process) and this parameter is not to be changed in subsequent processing steps, the newly introduced parameter is included in the signature.

[0099] To prevent the creator of a signature from removing the initial signature and thus deactivating the original validation specifications, it is assumed that an end device (container runtime environment or an industrial edge device) that performs the validation has a defined truststore that defines which possible initial entry signatures a signed artifact (a deployment configuration or an image) must have.

[0100] For this purpose, either the public signature keys of the first registry (e.g. an app store or the Industrial Edge Hub) must be deposited directly or authorized by certification authorities and the key of the certification authority must be deposited so that validation is possible.

[0101] If the validation of the attached signatures on the end device fails, the execution of the deployment

[0102] Configuration or container image is refused and an error message is displayed.

[0103] Since previous signature instances can not only restrict changes to the artifacts themselves (such as the creation of additional process privileges) in the metadata of subsequent signature instances, it is also possible that the described procedure can also ensure that only licensed downstream registry environments are allowed to receive and distribute a dedicated version. Assuming that the runtime environment is trusted, the execution authorization can also be limited in time by assigning appropriate metadata in previous signature processes. For example, by specifying an expiration date in the metadata, which prevents the instance from being restarted with the provided version.

[0104] The assumption for the described procedure is that the validation component on the container runtime environment also validates the metadata specified with the signature.

[0105] By providing an expiration date and ensuring its integrity and authenticity, it can also be defined that a repository looks for a newer version in the overlying repository after a defined expiration date at the latest and restricts the distribution to subsequent repositories or runtime environments.

[0106] Although the invention has been illustrated and described in detail by the embodiments, the invention is not limited by the disclosed examples and other variations can be derived therefrom by a person skilled in the art without departing from the scope of the invention.

Claims

Patent claims 1 . Artifact for instantiating and / or configuring a container instance for a container runtime environment, comprising: - at least one first parameter, wherein the at least one first parameter has a first cryptographic signature, - at least a second parameter, and - an explicit specification of the at least one second parameter with regard to signability by 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. Artifact according to claim 1, wherein the at least one first cryptographic signature protects the at least one first parameter against modification. 3 . Artifact according to one of the preceding claims, wherein there is no overlap between the at least one first parameter and the at least one second parameter. 4 . Artifact according to one of the preceding claims, wherein the at least one first parameter and / or the at least one second parameter are designed as: - a unique identifier and / or - a reference and / or - an initial uniform resource locator and / or - a container image uniform resource locator and / or - an initial container image tag and / or - a Binary Large Object Information and / or - a container image label.

5. Artifact according to one of the preceding claims, wherein the at least one first cryptographic signature specifies the at least one first parameter.

6. Artifact according to one of the preceding claims, wherein the artifact and / or the at least one first cryptographic signature comprises: - metadata, wherein the metadata specifies the at least one first parameter, and wherein the metadata has integrity and authenticity protection. 7 . Artifact according to one of the preceding claims, wherein the first cryptographic signature comprises a reference to the at least one second parameter. 8 . Artifact according to one of the preceding claims, further comprising: - at least one data area comprising at least one first parameter and / or - at least one second data area, comprising the at least one second parameter.

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

10. Artifact according to one of the preceding claims, further comprising: - at least one third parameter, wherein the at least one third parameter can be signed by at least one third cryptographic signature. 11 . Artifact according to one of the preceding claims, the artifact as : - A container deployment configuration or - a container image is created. 12 . Container instance based on an artifact according to one of the preceding claims .

13. Container runtime environment comprising at least one container instance according to claim 12. 14 . Method for creating an artifact for instantiating and / or configuring a container instance for a container runtime environment, comprising the steps of: - checking at least a first cryptographic signature which signs a first parameter, - depending on a result of the checking, creating at least one second cryptographic signature which signs a second parameter, wherein the first parameter and the second parameter are provided by an artifact according to one of claims 1 to 13.

Images