Feature: Expose Nebula API as a socket on the local machine or Nebula interface #1398
Description
We have an existing SSH debug server that can be used to inspect and tamper with the running Nebula process (e.g. checking or changing which remote is used for a given node's tunnel or printing internal process information.) This tool can be dangerous which is why we protect it with SSH authentication. However, we often hear and experience that this is a bit painful to setup: you have to generate a server SSH key and add client SSH keys for each user who wants to connect. This also makes it awkward to interact with programmatically.
We could simplify this by exposing the API as a local socket protected by Unix permissions and/or a remote socket protected via the Nebula firewall (i.e. using groups to restrict access.)
We are leaning towards an implementation that uses HTTP as a transport layer and JSON as a serialization format. We believe that this would make consumption trivial, since most machines have cURL or similar tooling installed. cURL can make HTTP requests to Unix sockets since 7.40 (released Feb 2015.) It also would allow users to use off-the-shelf tools like nginx to add their own authentication layer and broker access to the API if they desire.
Some other ideas that have been discussed:
- Additional event-based debugging (i.e. "watching for changes")
- Additional webhooks APIs for event-based reactivity (e.g. fail2ban-like functionality? Or logging if an unexpected host tries to access a privileged port.)
We're seeking input from the community on this feature.