-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optional invocation images #352
Comments
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 16, 2020
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 16, 2020
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 16, 2020
Fixes cnabio#352 Signed-off-by: Glyn Normington <[email protected]>
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 17, 2020
Fixes cnabio#352 Signed-off-by: Glyn Normington <[email protected]>
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 17, 2020
Fixes cnabio#352 Signed-off-by: Glyn Normington <[email protected]>
glyn
added a commit
to glyn/cnab-spec
that referenced
this issue
Mar 17, 2020
Fixes cnabio#352 Signed-off-by: Glyn Normington <[email protected]>
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.The text was updated successfully, but these errors were encountered: