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

Caching and atomicity of attestation storage #19

Open
laurentsimon opened this issue Feb 28, 2024 · 0 comments
Open

Caching and atomicity of attestation storage #19

laurentsimon opened this issue Feb 28, 2024 · 0 comments

Comments

@laurentsimon
Copy link
Collaborator

attestation may be stored in an attestation store or an existing registry. However, it's possible users make mistake and delete or alter the attestation. An existing deployment would then start failing, eg when scaling out during high traffic. What we need is atomicity of the deployment, ie the image is either _always passing verification or always failing verification.

Ideally the attestation should be part of the k8 config file, eg as an annotation for the pods. This annotation could be created by a gitops tool like ArgoCD. we could also do that ourselves:

  1. We verify using an annotation (cache 1). If not present, we look at the config map (cache 2). if not present, we retrieve from the attestation store.
  2. We will the cache

Cache 1 has the lifetime of a pod. Cache 2 has lifetime of a cluster. namespace. So if a pod is killed and restarted as-is, we'd still get the cache 2 hit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant