Overview
Introduction
Argos provides a framework to protect the integrity of a software supply chain. It provides a REST API and client libraries in order to protect the integrity of artifacts produced by a software supply chain.
It does so by verifying that each step in the chain is carried out as planned, by authorized systems or personnel, and that the product is not tampered with in transit.
It allows a project owner to create a layout. A layout lists the sequence of steps of the software supply chain, and the functionaries authorized to perform these steps.
When a functionary performs a step it gathers information about the related files and sends it to the Argos Notary Service in a link metadata file. As a consequence link files provide the required evidence to establish a continuous chain that can be verified against the steps defined in the layout
The layout, signed by the project owners together with the links, signed by the designated functionaries for a particular supply chain run, can be verified by the service.
This Overview is a short description of the system. A complete definition can be found in other parts of the documentation.
System overview
Involved actors
In the context of Argos Notary, a actor has duties and has to perform a set of actions.
In the description of the actors that follows, it is important to remember that the framework has been designed to allow a large amount of flexibility for many different use cases. Given that every project uses a very specific set of tools and practices, this is a necessary requirement for Argos Notary.
There are three different kind of actors in the framework:
- Project Owner: defines the layout of a software supply chain.
- Functionary: performs a step in the supply chain and provides a signed link as a record that such a step was carried out.
- Client: Performs verification on a set of end products by requesting a validation of the set on the Argos Notary Service.
Layouts and links are signed with the private RSA key of the actor.
Components
Argos Notary has three types of components
- Argos Notary Service: An integrated service to store and manage all Argos Notary objects
- Artifact Collectors: Services to collect Artifacts in the same as domain as the Artifact store, e.g. Git, Maven...
- Deployment Verifiers: Extensions on Deployment Mechanisms to validate end products to deploy.
Workflow example
To exemplify the working of the system, we will describe a simple scenario.
Consider a project owner, Alice
, and her five functionaries, Diana
, Bob
, Carl
, Build
and Client
.
Alice
wants Diana
to write a Python script (foo.py). Then, Alice
wants Build
to package the script into a tarball (foo.tar.gz).
This tarball will be sent to the client, Client
, as part of the end product. Client
wants to deploy this target file, foo.tar.gz.
Alice
will create a layout object that will be used by the Argos Notary Service during the release request to make sure of the following:
- That
Bob
andCarl
approved the script which was written byDiana
- That the script written by
Diana
was input for the packaging of the tarball done by Build. - That the tarball end product is approved by
Alice
.
In order for the Argos Notary Servive to do this, it will need four link objects and the layout: first, Alice’s
layout, describing the requirements listed above.
Then, 2 link objects signed by Bob
and Carl
which correspond to the approval of Diana’s
action of writing a script,
and a link object signed by Build
for the step of packaging the script. Finally, there should be a link object,
including the target file (foo.tar.gz) artifact, signed by Alice
to approve the all end products.
When the Argos Notary Service releases this end product on behalf of Alice
, it will perform the following checks:
- The layout exists and is signed with a trusted key (in this case,
Alice's
). - All end product artifacts match with the expected end products in the layout.
- Every step in the layout has at least as much as needed corresponding link objects signed by the intended functionaries, as described in the layout.
- All the materials and products listed in the link object match, as specified by the layout. This will be used to prevent packages from being altered without a record (missing artifacts in the link object), or tampered with while in transit. In this case, the products reported by Bob should match the materials reported by Build and so on.
If all of these verifications pass, the Argos Notary Service creates and stores a Release Dossier and returns the valid response on the request.
If Client
wants to verify the validity of the target file it requests a verification of the hash in combination with optionally the domain of
the Supply Chain. For this request the Argos Notary Service checks the availabillity of the Release Dossier with the hash of the target file with optionally the domain.
1. the workflow for this example
Acknowledgement
Argos Notary is an implementation of or at least inspired by the in-toto specification. This is the reason some parts of this documentation are the same as that specification. We couldn't completely refer to that specification because there also large differences. We are absolutely gratefull for the inspiration we got from their work.