On Thu, Nov 9, 2017 at 2:54 PM, <miha.plesko.x...@gmail.com> wrote: > > Yes, security can be a problem with such approach, we're wide open for > some time until cpiod is finished. Then the unikernel is secure again. > From solutions that you suggest I'd go with the second suggestion. So > basically I'd assume that instance is created in a private network that > only owners have access to - either via VPN or by spinning small Ubuntu VM > in there and running Capstan from there. Not sure how things are > on AWS, but on OpenStack this is the default behavior: instance is first > connected to internal network. Then later must user manually assign > a "floating IP" to it to make it accessible from the wild. > > Thanks for a reply, I'm glad you noticed the problem. > > > Dne sreda, 08. november 2017 17.06.31 UTC+1 je oseba Nadav Har'El napisala: >> >> >> On Wed, Nov 8, 2017 at 9:59 AM, <miha.ple...@gmail.com> wrote: >> >>> Nice one, this should work (with limitations as you described, but I >>> don't think they really bother us). So the usage would be: >>> >> 1) prepare base unikernel with* '/tools/cpiod.so --prefix /'* line in >>> /run/init >>> >> >> Something to be careful about this technique, is the security aspect: >> You are basically creating here a wide-open image that anyone could >> theoretically connect to before you have a chance to, and replace its image >> by something else. >> >> I can think of three ways to solve this security issue: >> >> 1. Connect to cpiod.so through SSL. I think we already have SSL support >> (and some mechanisms for unique keys, etc.) in other pieces of OSv, but not >> in cpiod.so, as far as I know. >> > > I'm not sure how SSL could help us in this case. Anyone from "the wild" > could start the connection, right? >
I meant SSL with a client-certificate, so the server (in this example, OSv's cpiod.so) could allow only specific clients to connect. I think we have such support in our REST API. But I don't remember the details. > >> >> 2. Tell the cloud provider to protect the "stem" image (the one who >> didn't differentiate yet, see https://en.wikipedia.org/wiki/Stem_cell) >> with a VPN, so only you can connect to it at all - it's not wide open to >> everyone on the Internet. Amazon has, for example, >> https://aws.amazon.com/vpc/. HPC clouds may be inherently secure (?) so >> this issue could be ignored there? >> > > Yes, I like this suggestion. > > >> >> 3. Perhaps the easiest solution is different: Don't allow an outside user >> to contact the image. Instead, give the image, through cloud-init, an >> external URL to fetch. The image will fetch this URL itself and open it >> with cpiod. There is no open port from the outside for anyone to mess with >> this process (assuming the attacker can't subvert cloud-init). >> > > I agree that this solution is more secure, but then again it means that > our (potentially sensitive) application files are sitting somewhere in "the > wild". > The URL itself can be "secret" (and if you connect through https, not http, nobody can figure it out), or more securely you can save an encrypted package and decrypt it (you can also check a signature for another check agains man in the middle). But this approach is indeed more complex. > Need to sleep this approach over, for now I prefer your 2nd suggestion. > Anyhow, this approach would require a lot of effort, right? > > >> >> >> >> >>> 2) set bootcmd to *'runscript /run/init; runscript run/the_config'* >>> 3) run unikernel and upload files. Among those files should be /run/init >>> with some dummy command that returns immediately, e.g. `/bin/sleep.so 1` >>> (link >>> <https://github.com/mikelangelo-project/capstan-packages/blob/master/docker_files/recipes/osv.bootstrap/meta/run.yaml#L12> >>> ) >>> >> >> By the way, I hope that an empty string works ok for a do-nothing >> command. If not, it can be fixed easily. No need to have a do-nothing .so. >> > > Turns out that it's best to "echo" something there, so I'm replacing the > "sleep" with "echo". But the empty command line does not work currently, I > think. > Yes, "echo" sounds fine :-) If the empty command line doesn't work for some reason, we can always fix that, but echo is just as good. > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
