5 ms·

A Docker Abstraction That Handles Container Security

caleblloyd 9y ago
From watching the videos on their homepage, it looks to me like the nanobox CLI is a bunch of wrappers around Docker. The cloud product sounds like a custom Docker container orchestrator. Worker nodes run on your cloud provider but management is tied to a control panel on their website. They recommend using nanobox over a PaaS in their video, but I fail to see how this is anything other than a PaaS.
gtirloni 9y ago
It might be worth investigating Kubernetes network policies [0] and the CIS benchmark [1] for a similar solution. 0 - https://kubernetes.io/docs/concepts/services-networking/network-policies/ https://kubernetes.io/docs/concepts/services-networking/netw... 1 - https://www.cisecurity.org/benchmark/kubernetes/ https://www.cisecurity.org/benchmark/kubernetes/
- technologyvault 9y ago
  Those solutions work well if you have solid devops skills. Nanobox is built more to empower developers who want to focus on just coding and not deal with infrastructure.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
the_common_man 9y ago
How is this different from heroku?
- demochimp 9y ago
  It's portable. Nanobox is a micro-PaaS: https://nanobox.io/heroku-alternative/ https://nanobox.io/heroku-alternative/ Also, a Docker explanation: https://content.nanobox.io/docker-containers-nanobox-development-platform/ https://content.nanobox.io/docker-containers-nanobox-develop...
- rhizome 9y ago
  Well, to begin with, Heroku has a bare minimum of interactive functionality, and this is a containered VM with a fancy cPanel successor. How are they similar?
- tylerflint 9y ago
  https://nanobox.io/why-nanobox/nanobox-vs-heroku/ https://nanobox.io/why-nanobox/nanobox-vs-heroku/
- technologyvault 9y ago
  The main difference is that the Nanobox PaaS is portable, making it what's been termed a "micro-PaaS". You can host with whatever cloud provider (AWS, DigitalOcean, Linode, Google Cloud) you want or set it up on-premise. Businesses who want to (or have to for compliance reasons) use a different host (e.g. Vultr in Europe or Alibaba Cloud in Asia) can simply create their own adapters and deploy away: https://docs.nanobox.io/providers/create/ https://docs.nanobox.io/providers/create/
lloydde 9y ago
Brings to mind Joyent Triton (OSS) which takes the Docker API abstraction at the availability zone (DC) built on (Solaris) Zones which also benefit by Linux Kernel API (SmartOS LX Brand).
contingencies 9y ago
It feels like the de-facto network policy design methodology, which I am yet to see implemented in open source, is one in which CI/CD test processes observe network utilization in test environments and automatically implement restrictions for deployed instances. For example, and ingress-only static content webserver would not require any outbound internet access. The same approach could and should be used for other observable and manageable layers (filesystem access, syscalls, language interpreter-specific function call whitelisting, etc.). I am waiting for a security-focused CI/CD tool to own this space. Even a light touch implementation would surely improve greatly on the status quo.
- iampims 9y ago
  Your comment reminded me of this talk https://youtu.be/BuFTHOgsgAY https://youtu.be/BuFTHOgsgAY especially the conclusion that something that rely on access patterns can't be trusted because it's almost impossible to validate all code paths.
  - contingencies 9y ago
    Perfection is not required.
- fulafel 9y ago
  Sounds like this kind of setup would autogenerate subtle firewall misconfigurations that result in mysterious failure modes. Like blocking ICMP which breaks TCP path MTU discovery. Or blocking outbound 53/tcp.
  - contingencies 9y ago
    Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers! Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway. It doesn't have to be nazi, just better than nothing.
irishasaurus 9y ago
Has there been a security audit yet?
- technologyvault 9y ago
  There hasn't been a security audit yet. Nanobox is still pretty new. We released publicly in February.
pmontra 9y ago
I decided to try nanobox last Friday, after some troubles with firing up a Vagrant box on my laptop. One instance worked, another one didn't, nothing new... Unfortunately I realized that to download nanobox I have to register and login and I really don't understand why. I expected to be able to download a binary, write a configuration file and build my service which I'll never run on somebody's else cloud. So this is not equivalent to Vagrant or docker, which are unregistered downloads or even apt-gets. It's more like running a part of AWS locally in development, but I don't want any lockin for this project. I went back to Vagrant. It turned out that a halt of the failed box followed by an up fixed the problem. I still don't feel Vagrant to be completely reliable or reproducible but I'll write my docker-compose and Dockerfiles if I want to use something else. I'd love to hear from nanobox about the reasons for the required registration. Not having to support people like me that won't buy their service would be perfectly fine. I wonder if there is some technical reason that applies also to the basic scenario of firing up a service locally.
ptspts 9y ago
Does Nanobox need root privileges on the host? If not, how does it provide networking?

From watching the videos on their homepage, it looks to me like the nanobox CLI is a bunch of wrappers around Docker. The cloud product sounds like a custom Docker container orchestrator. Worker nodes run on your cloud provider but management is tied to a control panel on their website. They recommend using nanobox over a PaaS in their video, but I fail to see how this is anything other than a PaaS.

gtirloni 9y ago

It might be worth investigating Kubernetes network policies [0] and the CIS benchmark [1] for a similar solution. 0 - https://kubernetes.io/docs/concepts/services-networking/network-policies/ https://kubernetes.io/docs/concepts/services-networking/netw... 1 - https://www.cisecurity.org/benchmark/kubernetes/ https://www.cisecurity.org/benchmark/kubernetes/

technologyvault 9y ago
Those solutions work well if you have solid devops skills. Nanobox is built more to empower developers who want to focus on just coding and not deal with infrastructure.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

the_common_man 9y ago

How is this different from heroku?

demochimp 9y ago
It's portable. Nanobox is a micro-PaaS: https://nanobox.io/heroku-alternative/ https://nanobox.io/heroku-alternative/ Also, a Docker explanation: https://content.nanobox.io/docker-containers-nanobox-development-platform/ https://content.nanobox.io/docker-containers-nanobox-develop...
rhizome 9y ago
Well, to begin with, Heroku has a bare minimum of interactive functionality, and this is a containered VM with a fancy cPanel successor. How are they similar?
tylerflint 9y ago
https://nanobox.io/why-nanobox/nanobox-vs-heroku/ https://nanobox.io/why-nanobox/nanobox-vs-heroku/
technologyvault 9y ago
The main difference is that the Nanobox PaaS is portable, making it what's been termed a "micro-PaaS". You can host with whatever cloud provider (AWS, DigitalOcean, Linode, Google Cloud) you want or set it up on-premise. Businesses who want to (or have to for compliance reasons) use a different host (e.g. Vultr in Europe or Alibaba Cloud in Asia) can simply create their own adapters and deploy away: https://docs.nanobox.io/providers/create/ https://docs.nanobox.io/providers/create/

lloydde 9y ago

Brings to mind Joyent Triton (OSS) which takes the Docker API abstraction at the availability zone (DC) built on (Solaris) Zones which also benefit by Linux Kernel API (SmartOS LX Brand).

contingencies 9y ago

It feels like the de-facto network policy design methodology, which I am yet to see implemented in open source, is one in which CI/CD test processes observe network utilization in test environments and automatically implement restrictions for deployed instances. For example, and ingress-only static content webserver would not require any outbound internet access. The same approach could and should be used for other observable and manageable layers (filesystem access, syscalls, language interpreter-specific function call whitelisting, etc.). I am waiting for a security-focused CI/CD tool to own this space. Even a light touch implementation would surely improve greatly on the status quo.

iampims 9y ago
Your comment reminded me of this talk https://youtu.be/BuFTHOgsgAY https://youtu.be/BuFTHOgsgAY especially the conclusion that something that rely on access patterns can't be trusted because it's almost impossible to validate all code paths.
- contingencies 9y ago
  Perfection is not required.
fulafel 9y ago
Sounds like this kind of setup would autogenerate subtle firewall misconfigurations that result in mysterious failure modes. Like blocking ICMP which breaks TCP path MTU discovery. Or blocking outbound 53/tcp.
- contingencies 9y ago
  Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers! Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway. It doesn't have to be nazi, just better than nothing.

irishasaurus 9y ago

Has there been a security audit yet?

technologyvault 9y ago
There hasn't been a security audit yet. Nanobox is still pretty new. We released publicly in February.

pmontra 9y ago

I decided to try nanobox last Friday, after some troubles with firing up a Vagrant box on my laptop. One instance worked, another one didn't, nothing new... Unfortunately I realized that to download nanobox I have to register and login and I really don't understand why. I expected to be able to download a binary, write a configuration file and build my service which I'll never run on somebody's else cloud. So this is not equivalent to Vagrant or docker, which are unregistered downloads or even apt-gets. It's more like running a part of AWS locally in development, but I don't want any lockin for this project. I went back to Vagrant. It turned out that a halt of the failed box followed by an up fixed the problem. I still don't feel Vagrant to be completely reliable or reproducible but I'll write my docker-compose and Dockerfiles if I want to use something else. I'd love to hear from nanobox about the reasons for the required registration. Not having to support people like me that won't buy their service would be perfectly fine. I wonder if there is some technical reason that applies also to the basic scenario of firing up a service locally.

ptspts 9y ago

Does Nanobox need root privileges on the host? If not, how does it provide networking?