Skip to content
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

Add ephemeral clients as a core scenario #25

Open
SteveLasker opened this issue Jun 29, 2020 · 1 comment
Open

Add ephemeral clients as a core scenario #25

SteveLasker opened this issue Jun 29, 2020 · 1 comment

Comments

@SteveLasker
Copy link
Contributor

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
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

2 participants