search

notaryproject / specifications

Cross tooling and interoperability specifications
https://notaryproject.dev/
Apache License 2.0
159 stars 44 forks source link

Add ephemeral clients as a core scenario #25

Open SteveLasker opened 4 years ago

SteveLasker commented 4 years ago

In a serverless world, where clouds are moving to on-demand instancing of workloads, we need to account for nodes that are delivered to users on-demand. This means the client has no historical, trusted reference point. If we don't trust a single endpoint ( the registry) then we must account for how a client is configured quickly as clouds are striving for sub second instancing of a container on ephemeral nodes.

sudo-bmitch commented 3 years ago

I'd say this applies not only to clients verifying signatures, but also to ephemeral CI build nodes that are signing images. At least some users will perform the signing as part of their CI pipeline and inject a delegated signing key for the task. This would mean that no stateful data can be required on the signing node, e.g. we can't rely on the build node to know the state of all the other signatures in the repository (this could impact the options a potential TUF implementation has to managing the targets metadata).