Dropping Packets from Unikernels

submited by
Style Pass
2023-03-17 17:00:03

Everytime you see an ops example such as 'ops instance create -p 8080' you are affectively punching a hole to allow the outside world to talk to your unikernel over that port.

This works well when you want to expose a unikernel to the wild wild west of the internet - not that the unikernel in question is listening on more than one port typically regardless. What about when it's just talking to other hosts on the same class c in an internal vpc? Or what if you don't want to or *can't* adjust the firewall rules for that host from the provider side? Some engineering teams have separate deploy, networking and security teams and they can sometimes all impose their own rules and will.

There is also the situation where you may have setup appropriate fw rules already but you'd like to defend against certain types of SSRF attacks that you might be otherwise vulnerable to.

This is where the new 'firewall' klib comes into play. Rather than relying on the cloud provider to enforce network security tags you can insist upon it at the Nanos instance level as well. This is unique since because in unikernel land the app and the instance are the same thing. This is very different as compared to a container or a normal linux instance. In linux one might use iptables, and docker will use that as well (some might say misuse). We don't use overlay networks or any other complex routing as our application is our instance. There is one and only one application per virtual machine. This also answers the question of "where is the kubernetes/orchestration for unikernels?" - in general you don't need one as again, we don't need to create additional layers and instead get to rely on the standard cloud primitives that are everywhere and which result in not just much better latency/throughput than containers but even standard debian/arch vms.

Leave a Comment