search

robur-coop / albatross

Albatross: orchestrate and manage MirageOS unikernels with Solo5
ISC License
142 stars 17 forks source link

WIP: ability to start a process #138

Closed samoht closed 1 year ago

samoht commented 1 year ago

Initial support to orchestrate processes instead of solo5 unikernels. It's enough to start a binary - there is no support for block/network yet.

samoht commented 1 year ago

Disclaimer: It's of course not a good idea to use this in production, but still, it's very useful to test things locally.

hannesm commented 1 year ago

It's of course not a good idea to use this in production

This also means to me that it is no good idea to have this in any albatross release, or maintain that code in the git repository. Or is there something I'm missing?

samoht commented 1 year ago

How do you debug new features in albatross and/or test your apps locally? Right now, it isn't easy to do so for me as if you are on macOS as you cannot run solo5 :-(

samoht commented 1 year ago

Ok let me rephrase this - my goal is to use albatross on my dev machine while I am developing apps on macOS. Right now I can't do this as albatross requires solo5. I am happy to do something different (like abstracting the execution engine and the memory quotas) and build another binary for this, but that might complexify the code a bit. What do you recommend there?

hannesm commented 1 year ago

Dear Thomas,

thanks for your remark what you'd like to achieve - develop and use albatross on macOS.

With the approach proposed here, my main issue is that it undermines the security story of albatross-daemon. If this PR is merged and deployed (although there is a disclaimer in this PR - not checked by any code), any client can execute arbitrary code as superuser (since this PR allows to upload any executable that is executed with albatross-daemon privileges). Certainly, more code could be added to configure the behaviour of albatross depending on some flag etc. - but this will only increase the complexity, and the likelihood that in the future there will be issues.

The path forward, depending on your mileage and goals can be:

  1. Develop a solo5 backend for macOS hypervisor.framework, and then use solo5-hvt with albatross.
  2. (Please excuse my not-too-deep knowledge since I do not have access to a macOS computer) Use "Docker for Mac" to run and develop albatross in a Linux container on your laptop (using solo5-spt this should work).
  3. Run albatross on a remote machine, and connect via the TLS endpoint (this certainly depends on where you want to extend what -- is it in albatross itself, or in projects on top of albatross?).
  4. On a macOS machine, pretend that solo5 exists: provide a solo5-hvt shell script (which consumes the command line arguments, but executes a unix process). Your albatross-client could upload macOS executables, and the shell-script executes them. As far as I can tell, you will only need a custom solo5-elftool (the OCaml library) which always returns Ok (and doesn't perform any checks) - which you can pin on your machine. This would only need marginal changes to albatross (to know which commands to execute for a macOS host), which should be fine to be merged.
  5. "Abstract the execution engine" may be worth a look as well, it may be useful for testing to be able to mock that. I've planned to do this for the ability to test all of albatross, but so far have been too worried about the increase of the complexity of the code (by i.e. using functors) -- I'd at the moment instead prefer to mock the environment by providing shell scripts for solo5-hvt, ip, taskset and mess around with PATH for such tests.
  6. Keep and maintain your changes in a fork.

Does any path resonate with you? If not, would you mind to describe a bit more in detail what you'd like to achieve (i.e. develop albatross or projects on top of it, use albatross for executing actual unikernels on a macOS, ...)?

samoht commented 1 year ago

Thanks Hannes!

Running random executables on the production host is certainly not a good idea. Hence my disclaimer :-) I'm happy to ditch my patch; it was a quick exploration to understand the albatross code better.

Indeed 2. and 3. are already possible but not great in terms of UX. 1. would be an ideal solution in the long-term, @MagnusS had investigated this a bit, so might be possible in the near future (but not today). I'm happy to work on 4. in the short term. I'm also happy to help explore the design space of 5. to see if the complexity is worthwhile if you think that's helpful.

hannesm commented 1 year ago

I think 4 is pretty straightforward and the path to go.

samoht commented 1 year ago

Closing as I don't have time to work on this right now.