In environments, notably Kubernetes, where applications define their installations declaratively, the presence of an invocation image in a bundle is seen by some as a potential security exposure (similar to ActiveX). This is likely to limit the adoption of CNAB in those environments.
The invocation image should be made optional. A bundle without an invocation image can be installed only by runtimes that support the bundle's metadata and/or extension(s).
This will make CNAB more broadly applicable, notably within the Kubernetes community. Features of the CNAB spec other than invocation images, including image relocation, air gap support, registry representation, and supply chain security, can then be exploited without the necessity of using invocation images.
A Spectrum of Experiences
This spec change enables CNAB to support the following experiences:
A purely declarative install mechanism. All necessary artifacts (with metadata about those artifacts) would be included in the bundle. External tools would be required to interpret and use those artifacts to do... something. It could be installing something, but it could also be other things over time.
Move the install tool chain into a container (or set of containers) that are left as a suggestion (e.g. because the invocation image is omitted) in the metadata on how to use the artifacts. It would be up to the user to use (or not use) those containers.
Have everything bundled into the install image much as it is today. That image would be opaque and must be used to install the application as some of the required artifacts may be baked into that image.
Compatibility
This is a backward compatible spec change since all existing bundles are valid in the updated spec. However, bundles without invocation images are invalid in the previous version of the spec. This change is therefore proposed for CNAB v1.1.
Since there is no standard way to perform actions on a bundle without an invocation image, the reference implementation needs updating to fail when asked to perform an action on such a bundle, but to allow such bundles when not performing an action.
After discussion in the CNAB Community Call on 18 March 202, it appears that making invocation images optional bifurcates the spec and makes interoperability more difficult. Closing.
Optional Invocation Images
In environments, notably Kubernetes, where applications define their installations declaratively, the presence of an invocation image in a bundle is seen by some as a potential security exposure (similar to ActiveX). This is likely to limit the adoption of CNAB in those environments.
The invocation image should be made optional. A bundle without an invocation image can be installed only by runtimes that support the bundle's metadata and/or extension(s).
This will make CNAB more broadly applicable, notably within the Kubernetes community. Features of the CNAB spec other than invocation images, including image relocation, air gap support, registry representation, and supply chain security, can then be exploited without the necessity of using invocation images.
A Spectrum of Experiences
This spec change enables CNAB to support the following experiences:
A purely declarative install mechanism. All necessary artifacts (with metadata about those artifacts) would be included in the bundle. External tools would be required to interpret and use those artifacts to do... something. It could be installing something, but it could also be other things over time.
Move the install tool chain into a container (or set of containers) that are left as a suggestion (e.g. because the invocation image is omitted) in the metadata on how to use the artifacts. It would be up to the user to use (or not use) those containers.
Have everything bundled into the install image much as it is today. That image would be opaque and must be used to install the application as some of the required artifacts may be baked into that image.
Compatibility
This is a backward compatible spec change since all existing bundles are valid in the updated spec. However, bundles without invocation images are invalid in the previous version of the spec. This change is therefore proposed for CNAB v1.1.
Since there is no standard way to perform actions on a bundle without an invocation image, the reference implementation needs updating to fail when asked to perform an action on such a bundle, but to allow such bundles when not performing an action.
Context
sheaf
prototype.