Store the policies next to the unikernels on disk #189
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The purpose is, while developing mollymawk - we discovered that the policies are ephemeral - thus if you have some unikernels dumped on disk, and (re)start albatross, they will be created (great!), but a policy_info command will return nothing. The issue is that in mollymawk we don't want to duplicate the storage effort, but rely on having the policy(ies) available - to generate intermediate certificates that are nice. To describe it a bit more technical: albatross is running a bunch of unikernels, deployed via TLS albatross is stopped albatross is started, unikernels are restarted mollymawk is started and retrieves the policies from albatross <- here, we read before this commit the empty set mollymawk tries to do something, and needs to create an intermediate certificate -- and by default pushes a VM=0, mem=0 policy <- here, all goes to hell. this is what we like to avoid Still, mollymawk is a bit special, since it reads the policies only on startup. This means an albatross with command-line policy modifications won't be updated in mollymawk. I guess the path forward is to notice that and make mollymawk the source of truth for policies (i.e. allow people to extract certificates for command line usage, provide the CA facility).
hannesm
added a commit
to hannesm/opam-repository
that referenced
this pull request
Sep 5, 2024
CHANGES: * Store the policies on disk, next to the unikernels (robur-coop/albatross#189 @hannesm) * Adapt to TLS 1.0.0, mirage-crypto 1.0.0, x509 1.0.0 and asn1-combinators 0.3.0 API changes (robur-coop/albatross#187 robur-coop/albatross#188 @hannesm)
hannesm
added a commit
to hannesm/opam-repository
that referenced
this pull request
Sep 5, 2024
CHANGES: * Store the policies on disk, next to the unikernels (robur-coop/albatross#189 @hannesm) * Adapt to TLS 1.0.0, mirage-crypto 1.0.0, x509 1.0.0 and asn1-combinators 0.3.0 API changes (robur-coop/albatross#187 robur-coop/albatross#188 @hannesm)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The purpose is, while developing mollymawk - we discovered that the policies are ephemeral - thus if you have some unikernels dumped on disk, and (re)start albatross, they will be created (great!), but a policy_info command will return nothing. The issue is that in mollymawk we don't want to duplicate the storage effort, but rely on having the policy(ies) available - to generate intermediate certificates that are nice.
To describe it a bit more technical:
albatross is running a bunch of unikernels, deployed via TLS
albatross is stopped
albatross is started, unikernels are restarted
mollymawk is started and retrieves the policies from albatross
<- here, we read before this commit the empty set
mollymawk tries to do something, and needs to create an intermediate
certificate -- and by default pushes a VM=0, mem=0 policy
<- here, all goes to hell. this is what we like to avoid
Still, mollymawk is a bit special, since it reads the policies only on startup. This means an albatross with command-line policy modifications won't be updated in mollymawk. I guess the path forward is to notice that and make mollymawk the source of truth for policies (i.e. allow people to extract certificates for command line usage, provide the CA facility).