From c5da9e9ac817bf3975d6134f8d56838f50f83470 Mon Sep 17 00:00:00 2001 From: Trishank K Kuppusamy Date: Mon, 22 Jul 2019 18:58:12 -0400 Subject: [PATCH] write introduction Signed-off-by: Trishank K Kuppusamy overview and table of contents Signed-off-by: Trishank K Kuppusamy move some text around Signed-off-by: Trishank K Kuppusamy better TOC; abstract; introduction Signed-off-by: Trishank K Kuppusamy fix small grammar issue Signed-off-by: Trishank K Kuppusamy introduce repos Signed-off-by: Trishank K Kuppusamy add some TODOs about image repos Signed-off-by: Trishank K Kuppusamy some clarifications(?) Signed-off-by: Trishank K Kuppusamy break things up a bit Signed-off-by: Trishank K Kuppusamy simplifying assumption: one image registry <=> one image repo Signed-off-by: Trishank K Kuppusamy minor language edits Signed-off-by: Trishank K Kuppusamy WIP on traditional img repos Signed-off-by: Trishank K Kuppusamy WIP Signed-off-by: Trishank K Kuppusamy expand ToC Signed-off-by: Trishank K Kuppusamy defer community image repos Signed-off-by: Trishank K Kuppusamy some minor fixes Signed-off-by: Trishank K Kuppusamy introduce idea of gradual security Signed-off-by: Trishank K Kuppusamy add section on gradual security Signed-off-by: Trishank K Kuppusamy WIP Signed-off-by: Trishank K Kuppusamy end here today Signed-off-by: Trishank K Kuppusamy separate security analysis Signed-off-by: Trishank K Kuppusamy move things around a bit Signed-off-by: Trishank K Kuppusamy wrap up traditional img repos Signed-off-by: Trishank K Kuppusamy add a sentence Signed-off-by: Trishank K Kuppusamy mention PEPs 458 & 480 for community img repos Signed-off-by: Trishank K Kuppusamy add a reference Signed-off-by: Trishank K Kuppusamy draft of signing workflows Signed-off-by: Trishank K Kuppusamy minor language edits Signed-off-by: Trishank K Kuppusamy defer a few things Signed-off-by: Trishank K Kuppusamy one more thing to defer for now Signed-off-by: Trishank K Kuppusamy add some important considerations Signed-off-by: Trishank K Kuppusamy minor edits Signed-off-by: Trishank K Kuppusamy Clarify why bundle.json is mounted in the invocation image (#228) * clarify why bundle.json is mounted in the invocation image Signed-off-by: Trishank K Kuppusamy * remove link Signed-off-by: Trishank K Kuppusamy add a CNAB Registry icon (#232) ![cnab-registry](https://user-images.githubusercontent.com/686194/61753147-2b387a80-ad63-11e9-8a63-f250bcdf06b0.png) Adds a registry icon, which is a variant of the main CNAB logo. Signed-off-by: Trishank K Kuppusamy add a CNAB Security icon (#231) Signed-off-by: Trishank K Kuppusamy Remove the `immutable` attribute from parameters This removes the `immutable` attribute from parameters per Issue #229 Signed-off-by: Trishank K Kuppusamy Remove wording about immutable parameters Signed-off-by: Trishank K Kuppusamy Remove fields from outputs Signed-off-by: Radu M Signed-off-by: Trishank K Kuppusamy fix(claim.schema.json): s/underay/underway Signed-off-by: Trishank K Kuppusamy fix(claim.schema.json): s/descripton/description Signed-off-by: Trishank K Kuppusamy Adds information about the Specification Freeze (#238) Signed-off-by: Trishank K Kuppusamy Update 103-bundle-runtime.md s/Instance/Installation Signed-off-by: Trishank K Kuppusamy massively simplify 300 Signed-off-by: Trishank K Kuppusamy terminology updates Signed-off-by: Trishank K Kuppusamy more fine-grained security levels Signed-off-by: Trishank K Kuppusamy KISS: break up metadata repositories, signing, verification Signed-off-by: Trishank K Kuppusamy fix(400-claims.md): add mention of the custom field in a claim (#255) Signed-off-by: Trishank K Kuppusamy Update README.md (#260) Remove the OCI mailing list info Signed-off-by: Trishank K Kuppusamy Update definitions schema to use a bespoke JSON Schema Version (#257) * Update definitions schema to use integer, remove `number` as a type Fixes #256 * Incorporate suggestion Signed-off-by: Trishank K Kuppusamy fix: corrected a typo Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy clearify wording on writeOnly Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy clarify what to do when multiple invocation images match a pattern Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy fix: clarify the wording on stateless actions Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy Add clarification to `readOnly` definition Signed-off-by: Trishank K Kuppusamy Clarify parameters are encoded as json strings Signed-off-by: Trishank K Kuppusamy Clarify defaults for outputs and parameters (#270) * Clarify how required and default interact * Clarify output defaults Signed-off-by: Trishank K Kuppusamy Removed extra were Signed-off-by: Trishank K Kuppusamy explain how claims treat parameters and credentials differently, and why (#267) Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy Update contentDigest wording to clarify behavior (#261) * Update contentDigest wording to clarify behavior Fixes: #254 * Update markup for contentDigest * Update comments Signed-off-by: Trishank K Kuppusamy Clarify upgrade version handling responsibility Signed-off-by: Christopher Crone Signed-off-by: Trishank K Kuppusamy Improve wording Signed-off-by: Christopher Crone Signed-off-by: Trishank K Kuppusamy Fix OWF Contributor License Agreement link (#276) Signed-off-by: Trishank K Kuppusamy Clarify failed action handling (#274) Signed-off-by: Christopher Crone Signed-off-by: Trishank K Kuppusamy CNAB Core 1.0 GA This commit marks the Working Group Acceptance (GA) of the CNAB Core 1.0 specification. Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy Final Approval for CNAB Core 1.0 Specification This commit indicates that the CNAB specification is now a published final version. Signed-off-by: Trishank K Kuppusamy Update README.md Co-Authored-By: Carolyn Van Slyck Signed-off-by: Trishank K Kuppusamy Update 100-CNAB.md Co-Authored-By: Carolyn Van Slyck Signed-off-by: Trishank K Kuppusamy Add mailing list (#283) Signed-off-by: Trishank K Kuppusamy Bump bundle schemaVersion to 1.0.0 (#278) Signed-off-by: Christopher Crone Signed-off-by: Trishank K Kuppusamy Update 103-bundle-runtime.md fixing the misleading description in the example of setting parameter value in file. Signed-off-by: Trishank K Kuppusamy Define host environment Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy Make status.json a CNAB Output Signed-off-by: Trishank K Kuppusamy fix: remove an unnecessary section Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy add bundleReference to the claim specification Signed-off-by: Matt Butcher Signed-off-by: Trishank K Kuppusamy Update 400-claims.md Co-Authored-By: Glyn Normington Signed-off-by: Trishank K Kuppusamy address @vdice feedback Signed-off-by: Trishank K Kuppusamy remove .gitignore Signed-off-by: Trishank K Kuppusamy fix links per @chris-crone feedback Signed-off-by: Trishank K Kuppusamy --- 300-CNAB-security.md | 195 ++++++++++------------------------ 301-metadata-repositories.md | 2 +- 302-signing-workflows.md | 2 +- 303-verification-workflows.md | 2 +- README.md | 5 +- 5 files changed, 64 insertions(+), 142 deletions(-) diff --git a/300-CNAB-security.md b/300-CNAB-security.md index 5f4c579c..8f32445a 100644 --- a/300-CNAB-security.md +++ b/300-CNAB-security.md @@ -3,170 +3,89 @@ title: Bundle Security weight: 300 --- -# Cloud Native Application Bundles Security (CNAB-Sec) 1.0 WD +# Cloud Native Application Bundles Security (CNAB-Sec) 1.0.0 WD -![cnab-security](https://user-images.githubusercontent.com/686194/61752644-54580b80-ad61-11e9-9518-608534d09bdd.png) - -The CNAB Security specification augments the [CNAB Core specification](100-CNAB.md) by standardizing on security mechanisms for signing, verifying, and attesting CNAB packages. It describes both a client/registry security model and a verification chain (provenance) model. By design, this provides security mechanisms that work in air-gapped networks. - -This specification is distinct from the CNAB Core specification. An implementation may comply with the CNAB Core specification, and yet not comply with this specification. The use of terms such as MUST and SHOULD in this document are statements about how a CNAB implementation may fulfill the CNAB Security specification _only_. - -> An earlier version of the CNAB Core specification used OpenPGP-based mechanism to sign and verify bundles. This specification supersedes that portion of the specification. - -This specification addresses two related problems: - -- Securing the delivery of packages from a source to a client -- Ensuring the provenance of a bundle robustly, even across networks and over long periods of time - -Industry standards such as [NISTIR-8176](https://csrc.nist.gov/News/2017/NIST-Releases-NISTIR-8176) provide recommendations on how container security may be achieved, and a goal of this specification is to meet such recommendations. - -## Key Terms - -In addition to the terminology introduced in the CNAB Core specification, this specification uses additional terms: - -- *Acceptance Criteria:* The conditions that must obtain before a particular CNAB may be considered acceptable for use. This may be, in some cases, as simple as "the CNAB bundle has the expected digest" or as complicated as a tree-structured diagram of attestations. -- *Attestation:* an assertion, cryptographically verifiable, that a particular identity has performed a particular task. For example, an attestation may capture the assertion that "Developer Padma has approved version 1.2.3 of the WebApp bundle." -- *Bundle:* This term refers to a CNAB package, and is used to clarify that the object in question is a particular package, not the CNAB specification. -- *CNAB Client:* Any CNAB-aware program that operates on a package generated elsewhere. -- *CNAB Registry:* Any repository of CNAB bundles. While there is a specification for how such bundles should be stored (the [CNAB Registry specification](200-CNAB-registries.md)), this specification assumes only that a registry is a remote storage system from whence CNAB bundles can be pulled and (optionally) to which they may be pushed. -- *Layout:* A declaration of a series of attestations that must be made in order to consider a particular bundle to have satisfied the acceptance criteria. -- *Link:* An envelope that binds a particular attestation to a particular step in a layout. -- *Signature:* A cryptographic verification that the possessor of a particular private key has approved a particular body of content. For example, a signature may capture the approval: "Developer Padma has approved this archive file". Note that an attestation always contains a signature, but a signature may be used for things other than attestation. -- *Verification:* The process of applying a public key to a signature and associated body of content, with the purpose of verifying that the body of content is identical to the body that was signed by the private key. - -## Securely Moving Bundles To And From Registries - -Per the CNAB Core 1.0 specification, bundles may be stored and transmitted in two forms: thin bundles and thick bundles. Both thin and thick bundles can be transmitted over the network. This section describes how CNAB clients (including CNAB runtimes) may safely establish the identity and integrity of a CNAB bundle being fetched from a CNAB registry. - -(Per the [CNAB Registry specification](200-CNAB-registries.md), CNABs may be stored in any OCI Registry 1.0-compliant implementation) - -Securing a CNAB registry is done by implementing the TUF (The Update Framework) specification on both the client and registry side, and then adhering to the protocol. A registry MUST comply with the [TUF 1.0 specification](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md) to meet this specification. A client also MUST comply with the TUF specification to meet this specification. Furthermore, the client MUST perform additional verification on the content of a bundle. - -This specification does not require that a bundle registry support both thick and thin bundles. It prescribes processes for storage of each. Unless otherwise noted, a registry is considered _compliant_ if it implements storage for at least one of the two. - -This specification does not specifically deal with network-layer (Layer 7) security, but assumes that implementations will apply correct security constraints for all network traffic. TLS/SSL is likely the method by which such traffic should be secured. - -### Overview - -There are three major aspects of securely working with registries: - -1. Pulling bundles _from_ a registry _to_ a client -2. Pushing bundles _from_ a client _to_ a registry -3. Managing keys between a client and a registry - -### Pulling and Verifying Bundles - -When a client pulls a bundle from a registry, the client MUST verify the package, where verification consists of the following: +* [Introduction](#introduction) +* [Roadmap](#roadmap) + * [Gradual security](#gradual-security) +* [References](#references) -- Fetch (from a TUF endpoint) the signature object for the given bundle -- Fetch the bundle descriptor (optionally by fetching a thick bundle and unpacking the descriptor) -- Verify the requisite signatures for a package, as described in [the TUF specification](https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#5-detailed-workflows). -- Verify that each Invocation Image in the bundle descriptor (a) has a content digest, and (b) the content digest matches the referenced image (by recalculating the hash) -- Verify that each Image referenced in the bundle descriptor (a) has a content digest, and (b) the content digest matches the referenced image (by recalculating the hash) - -A client MUST be able to verify SHA-256 and SHA-512 content digests. But this specification accords with the CNAB Core specification in that it does not dictate what are the the contents of the Invocation Images or regular Images. Examples in this document often refer to OCI images as the content of these image fields, but other formats are acceptable. - -If any of these steps fail to obtain, the client MUST NOT perform an action on the bundle. Clients SHOULD produce an error. - -### Signing and Pushing Bundles - -When a client pushes a bundle to a registry, the client MUST prepare the security data on the package, which consists of the following: - -- Generate the content digest (SHA-256 or SHA-512) of each invocation image, and write this information into the bundle descriptor -- Generate the content digest of each image, and write this information into the bundle descriptor -- Optionally, push the images to their appropriate remote location (thin bundles) -- Sign the requisite portion of the bundle - - For thin bundles, this is the bundle descriptor alone - - For thick bundles, this is the full bundle, in its representation that it will be submitted to the bundle registry -- Send the signature data to the TUF server, per the details of that server's implementation. (The TUF specification does not specify the process for uploading signatures. However, Notary provides one API for doing this.) TODO: Do we want to limit this to the Notary-prescribed protocol for ease of developing compatible clients? -- Send the data that has been signed to the CNAB Registry - -In regard to the final two steps, specific implementations may require different ordering of operations. Thus, a CNAB client MAY perform these steps in any order that does not sacrifice the integrity of the cryptographic signatures. - -### Key Management - -A client SHOULD maintain a cache of trusted public keys. This cache MAY be directly managed, and this cache MAY adopt a strategy of Trust On First Use (TOFU), whereby the first time a package is fetched from a trusted source, the client may also request the public keys from that server. Other than the TOFU case, clients SHOULD NOT attempt to fetch release keys and packages from the same source at the same time. Timestamp, distribution, and root keys (all part of the TUF specification) MUST be managed according to the TUF specification. - -## Provenance and Software Supply Chain - -The previous section of the specification deals with managing the integrity of the process of transferring a CNAB bundle to and from a CNAB Registry. - -In addition to verifying integrity, there is a second related set of verifications that may be performed on a CNAB. These are related to _provenance_. - -Provenance captures concern tracing the origin of a package and its components, and ascertaining the integrity of the steps in the process of composing the package from its components. Compare this with the idea of the _software supply chain_, which is a process for composing software in such a way that it preserves provenance in a verifiable way. - -This section specifies a provenance model for CNAB based on the [In-Toto specification](https://github.com/in-toto/docs/blob/v0.9/in-toto-spec.md). This specification pays less attention to the software supply chain (e.g. the specific set of steps), focusing instead on how this information is to be stored and verified in a CNAB bundle. - -In-Toto, upon which this part of the specification is built, describes two major concepts: A _layout_ that describes the steps which must be performed to establish provenance for a bundle, and multiple _links_, which tie a cryptographic attestation (along with some metadata) to a step in the layout. For example, if a layout has three steps, verification of that layout would require three links -- one for each step. Layouts may be linear, but they also may be tree-shaped, where one layout invokes other "sublayouts", which in turn each may invoke further sublayouts. - -For CNAB, bundles may have associated layouts, and such layouts may be satisfied by links. - -### Attaching Layouts and Links to Bundles - -For layouts and links to function properly, they must be stored in proximity to the bundle. - -The "default layout" may be stored inside of the `custom` section of the bundle descriptor. - -EXAMPLE - -#### Links and Thick Bundles +![cnab-security](https://user-images.githubusercontent.com/686194/61752644-54580b80-ad61-11e9-9518-608534d09bdd.png) -Links in a thick bundle may be packaged into the tar archive at the following path: `links/`. The structure of the files and directories inside of that directory are all well-specified in the In-Toto specification. +This specification is distinct from the CNAB Core specification. An implementation may comply with the CNAB Core specification, and yet not comply with this specification. -When a bundle is imported (or extracted), a client SHOULD verify the layout against the contents of `links`. +The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). The use of these keywords in this document are statements about how a CNAB implementation may fulfill the CNAB Security specification _only_. -#### Layouts and Thin Bundles +The reader is assumed to be thoroughly familiar with the [TUF][tuf-spec] and [in-toto][in-toto-spec] specifications, and some deployment models such as [PEP 458][pep-458], [PEP 480][pep-480], [ITE-4][ite-4], [ITE-5][ite-5], and [Datadog Agent integrations][datadog-agent-integrations]. -For thin bundles, links must be stored external to the bundle, since (a) the bundle descriptor is the artifact of record, and (b) a layout will likely make assertions about the bundle descriptor, and therefore cannot be embedded within the descriptor. +The CNAB Security specification augments the [CNAB Core specification](100-CNAB.md) by standardizing on security mechanisms for signing, verifying, and attesting CNAB packages. It describes both a client/registry security model and a verification chain (provenance) model. By design, this provides security mechanisms that work in air-gapped networks. -An implementation of provenance that uses thin bundles MAY store the links inside of a CNAB registry as layers attached to a bundle, using the `mediaType` `x-application/io.cnab.link` TODO: This should be closer to whatever media types we decide to use for CNAB. +This specification is distinct from the CNAB Core specification. An implementation may comply with the CNAB Core specification, and yet not comply with this specification. The use of terms such as MUST and SHOULD in this document are statements about how a CNAB implementation may fulfill the CNAB Security specification _only_. -### Key Management +> An earlier version of the CNAB Core specification used OpenPGP-based mechanism to sign and verify bundles. This specification supersedes that portion of the specification. -A crucial aspect of verifying layouts is the ability of a client to verify an attestation against the public key used to generate a link. And because layouts are themselves signed, it is implicit in the system that public keys must be shared between the bundle creator(s) and the client. +## Introduction -The specification does not prescribe particular key management steps. However, it explicitly allows for certain key management practices. Clients MAY use the keys managed for TUF transactions in order to verify layouts. Clients MAY include TOFU-acquired public keys. Clients SHOULD NOT use TUF's timestamp, distribution, or root keys to sign or verify layouts, as these keys are ascribed special significance in TUF, and that significance does not align with the provenance function described here. +It is important to sign bundles and images so that attackers cannot tamper with them without being detected. To enable faster deployments, they are likely to be built and signed by continuous integration / continuous delivery (CI/CD) instead of developers. While CI/CD provides benefits such as safer handling of signing keys, it also has a severe drawback. Since signing keys must be kept _online_ so that CI/CD can build and sign new bundles or images on demand, attackers who compromise the infrastructure can also abuse these keys to build, sign, and distribute malicious versions. The goal of this document is to discuss how to achieve _compromise-resilience_ in this setting: that is, even if the infrastructure is compromised anywhere between developers and end-users, attackers should not be able to cause end-users to install malicious versions of bundles or images that were not released by developers. -### Composing Layouts +While SSL / TLS protects users from man-in-the-middle (MitM) attacks, it is _not_ compromise-resilient, because attackers who compromise the infrastructure can abuse the online SSL / TLS key to replace files signed in transit but not at rest. Likewise, other solutions, such as GPG or X.509, do not support necessary features such as in-band key revocation or rotation. -Layouts are well-defined in the In-Toto specification. However, a certain subset of In-Toto features are considered OPTIONAL in the present spec: +We propose using [The Update Framework (TUF)](https://theupdateframework.com) and [in-toto](https://in-toto.io) to solve this problem. TUF is a framework that provides security between _registries_, or the servers used to distribute bundles or images, and end-users. Specifically, TUF ensures the authenticity and integrity of bundles and images downloaded from registries. in-toto is a framework that provides security between developers and registries. Specifically, in-toto ensures the end-to-end integrity of the _software supply chain_ used to build and sign bundles or images. By combining both, we get a system that provides compromise-resilience between developers and end-users. -- Inspections: In-Toto provides a method for running arbitrary commands on a machine in order to verify that specific parts of a software supply chain are correct. This specification does not require support for inspections. Moreover, this specification discourages allowing bundles to run external commands even for inspection purposes. + Signing and verifying [claims](400-claims.md) are out of the scope of this document. -### Verifying Layouts +## Roadmap -The In-Toto specification defines the procedure for verifying individual links against the layout. This section adds CNAB-specific context to the more general specification. +The basic idea is to use TUF as a transport protocol that distributes several files in a compromise-resilient manner: -If any part of a layout cannot be satisfied, the client SHOULD generate an error and MUST NOT continue installing the bundle. +* The root of trust for all bundles and images, as well as TUF and in-toto metadata. +* The software supply chains defined using in-toto. +* The public keys used to verify these supply chains. -If a link does not match a step in the layout, the link SHOULD be ignored. But if multiple links apply to the same step of a layout, and at least one can be verified, that layout stem SHOULD be considered verified. +While images and bundles are published on registries, TUF and in-toto metadata about images and bundles are published on [_metadata repositories_](301-CNAB-metadata-repositories.md). Metadata repositories are conceptually, but not necessarily physically, distinct from [CNAB](200-CNAB-registries.md) or [OCI](https://github.com/opencontainers/distribution-spec/blob/master/spec.md) registries. Furthermore, the key management models on metadata repositories are largely prescriptive. For these reasons and more, metadata repositories are out of the scope of this document. -A client MAY choose to apply a non-default (non-package-supplied) layout, provided this is exposed to the user of the client. In this way, a more or less stringent layout may be applied to a package as a method of providing context-specific validations. For example, a bundle may ship with an eight-step layout. However, the destination environment only requires validation of two steps. A client MAY consume a two-step layout and match that against the links provided by the bundle. In this case, the package is considered validated if the newly applied layout passes. External layouts MAY be signed by a key other than the one used on the default layout. +Unless specified otherwise, metadata are TUF and in-toto metadata, which may be produced using the suggested [signing workflows](302-signing-workflows.md). +When a [bundle runtime](103-bundle-runtime.md) installs a bundle, it should first verify images and bundles using the suggested [verification workflows](303-verification-workflows.md). -## Signing and Digests for Thick Bundles +[**TODO** Figure 1 illustrates a high-level overview of how the components described in this document interact with each other.] -When moving thick CNABs between networks, it is often necessary to export a bundle into its thick (single-file) format, transport it, and then import it on the destination host. In this model, the TUF-oriented protocol does very little good, and the In-Toto layouts are stored within the bundle. In such a case, it may be necessary to add a layer of validation around the bundle itself. +### Gradual security -To provide this layer, a signed digest of the bundle contents must be prepended to the bundle, creating a new file. The format for this is as follows: +Implementors / adopters MAY wish to implement security gradually instead of an all-or-nothing approach. -``` -$$ -``` +Level 0: neither images nor bundles are signed. + * Pros: no security to maintain. + * Cons: completely lacking compromise-resilience. -Where `` is to be replaced by one of the following schemes, `` is to be replaced by the signature, and `` is to be replaced by the raw gzipped tar data. The `$` characters are literal. +Level 1a: images are signed using TUF, but bundles are unsigned. + * Pros: easiest level of security to achieve, e.g. using Docker Content Trust (metadata repository) and Notary (client). + * Cons: only partly compromise-resilient. If a [CNAB registry](200-CNAB-registries.md) is compromised, a bundle could be easily replaced with malicious one. -The following signature schemes (as defined in the Section 4.2 of the TUF specification) must be supported: +Level 1b: bundles are signed using TUF, but images are unsigned. + * Pros: easiest level of security to achieve, e.g. using Docker Content Trust (metadata repository) and Notary (client). + * Cons: only partly compromise-resilient. If an [OCI registry](https://github.com/opencontainers/distribution-spec/blob/master/spec.md) is compromised, a bundle runtime may be vulnerable to accidentally bundling malicious images. + +Level 2: both bundles and images are signed using TUF. + * Pros: resilient against compromise of bundle and image registries. + * Cons: not resilient against compromise of CI for bundles or images. -- "rsassa-pss-sha256" : RSA Probabilistic signature scheme with appendix. The underlying hash function is SHA256. - https://tools.ietf.org/html/rfc3447#page-29 +Level 3a: images are signed using TUF and in-toto. Bundles are signed using TUF. + * Pros: resilient against compromise of CI for images. + * Cons: adds work to developers and administrators. Not resilient against compromise of CI for bundles. -- "ed25519" : Elliptic curve digital signature algorithm based on Twisted - Edwards curves. - https://ed25519.cr.yp.to/ +Level 3b: bundles are signed using TUF and in-toto. Images are signed using TUF. + * Pros: resilient against compromise of CI for bundles. + * Cons: adds work to developers and administrators. Not resilient against compromise of CI for images. -- "ecdsa-sha2-nistp256" : Elliptic Curve Digital Signature Algorithm - with NIST P-256 curve signing and SHA-256 hashing. - https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm +Level 4: both bundles and images are signed using TUF and in-toto. + * Pros: resilient against compromise of CI for bundles and images. + * Cons: greatest amount of work in implementation and adoption. -The resulting file should have the extension `.cnab`. For example, if `webapp.tgz` is signed and digested, a new file should be created named `webapp.cnab`, with the signature prefix followed by the unaltered data in the original `webapp.tgz` file. +[tuf-spec]: https://github.com/theupdateframework/specification +[in-toto-spec]: https://github.com/in-toto/docs +[ite-4]: https://github.com/in-toto/ITE/pull/4 +[datadog-agent-integrations]: https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/ +[ite-5]: https://github.com/in-toto/ITE/pull/5 +[pep-458]: https://www.python.org/dev/peps/pep-0458/ +[pep-480]: https://www.python.org/dev/peps/pep-0480/ \ No newline at end of file diff --git a/301-metadata-repositories.md b/301-metadata-repositories.md index be8ca0b1..3774d1ef 100644 --- a/301-metadata-repositories.md +++ b/301-metadata-repositories.md @@ -3,7 +3,7 @@ title: CNAB Security: Metadata repositories weight: 301 --- -# Cloud Native Application Bundles Security (CNAB-Sec): Metadata repositories 1.0 WD +# Cloud Native Application Bundles Security (CNAB-Sec): Metadata repositories 1.0.0 WD * [Metadata repositories](#metadata-repositories) * [Minimum viable product (MVP)](#minimum-viable-product-mvp) diff --git a/302-signing-workflows.md b/302-signing-workflows.md index b606f925..51e9f192 100644 --- a/302-signing-workflows.md +++ b/302-signing-workflows.md @@ -3,7 +3,7 @@ title: CNAB Security: Signing workflows weight: 302 --- -# Cloud Native Application Bundles Security (CNAB-Sec): Signing workflows 1.0 WD +# Cloud Native Application Bundles Security (CNAB-Sec): Signing workflows 1.0.0 WD * [Signing workflow for the minimum viable product (MVP)](#signing-workflow-for-the-minimum-viable-product-mvp) diff --git a/303-verification-workflows.md b/303-verification-workflows.md index 65a353f5..05365851 100644 --- a/303-verification-workflows.md +++ b/303-verification-workflows.md @@ -3,7 +3,7 @@ title: CNAB Security: Verification workflows weight: 303 --- -# Cloud Native Application Bundles Security (CNAB-Sec): Verification workflows 1.0 WD +# Cloud Native Application Bundles Security (CNAB-Sec): Verification workflows 1.0.0 WD - [Verification workflows](#verification-workflows) diff --git a/README.md b/README.md index accf8e64..46e6896a 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,10 @@ For more information on the approval process, see [the process documentation](90 1. [The Bundle Runtime](103-bundle-runtime.md) 1. [Bundle Formats (Thick and Thin)](104-bundle-formats.md) - Chapter 2: [Cloud Native Application Bundle Registry 1.0.0 (CNAB-Reg)](200-CNAB-registries.md) -- Chapter 3: [Cloud Native Application Bundle Security 1.0.0 (CNAB-Sec)](300-CNAB-security.md) +- Chapter 3: [# Cloud Native Application Bundles Security (CNAB-Sec) 1.0.0 WD](300-CNAB-security.md) + 1. [Cloud Native Application Bundles Security (CNAB-Sec): Metadata repositories 1.0.0 WD](301-metadata-repositories.md) + 1. [Cloud Native Application Bundles Security (CNAB-Sec): Signing workflows 1.0.0 WD](302-signing-workflows.md) + 1. [Cloud Native Application Bundles Security (CNAB-Sec): Verification workflows 1.0.0 WD](303-verification-workflows.md) - Chapter 4: [Cloud Native Application Bundle Claims 1.0.0 (CNAB-Claims1)](400-claims.md) - Chapter 5: [Cloud Native Application Bundle Dependencies 1.0.0 (CNAB-Deps)](500-CNAB-dependencies.md) - Chapter 8: Non-normative Content