Artefact integrity

[AlexSzlavik]

Motivation:
The FTL controller is responsible for archiving and dispatching of deployable artefacts to FTL runners. Today, artefacts captured by the controller have no integrity guarantees, meaning that what we deploy to our runners cannot be verified. It would be quite nice to introduce the concept of verifiable deployments to FTL.

Proposal:
Conceptually this is quite simple, as part of the build step (ftl build or the build step of ftl deploy), we generate a signature over a digest of the deployable. Such a digest actually already exists in FTL as part of checking for deploy diffs of the deploy step. Ideally, the FTL CLI would accept a signing key as an option, and sign the digest using this key.

Artefact integrity checking would occur both when the artefact (and its signature) are uploaded to the ftl controller as well as when an artefact is deployed to a runner. Ideally, runners could also verify the integrity and authenticity of artefacts being deployed to them, via the same mechanism.

Integrity checking as part of the upload step, ensures that only artefacts from authorized sources (sources with access to the appropriate signing key) are able to install new artefacts into the artefact store. This provides early feedback to developers and intrusion detection systems that the attempted action is unauthorized. This also provides a means of establishing trust that deployable artefacts were generated via trusted means (for example a CI pipeline).

Performing an integrity check at deployment time to a runner further ensures that no unauthorized payloads get deployed into ftl runners. Here, if integrity checking fails, the runner and controller would provide meaningful error messages and quarantine the affected artefacts.