Support for Border0 Connector / Docker Exec

[adrianosela]

Support for Border0 Connector / Docker Exec

This PR introduces the ability to deploy the Border0 Connector as a node in a containerlab environment (lab)... connecting all nodes without the need to expose nodes' SSH ports or manage/provision any nodes with secrets.

This makes for a seamless experience for containerlab users who wish to expose their labs over the internet (behind their authentication method of choice: Google/GitHub/Microsoft/Email-Link).

The nicest thing about it is users can talk to their nodes from any web browser using our web client.

Video Demo

clab-x-border0-LOW-RES.mp4

---

I alluded to this feature being in the works in #1768:

@hellt Let's talk next year. We maaaaay (no promises) have something in the works to simplify the integration and make the experience much nicer for clab users.

We are excited to hear your thoughts and collaborate on making the containerlab x border0 experience as best as it can be!

cc:// @steiler @hellt @atoonk

[hellt]

thanks @adrianosela
this is cool. Will have to try it out somewhen in the next few weeks

[adrianosela]

Hey @hellt - just FYI I pushed another commit that uses the Border0 authentication flow from our SDK, which maintains backwards compatibility with the legacy (email + password) flow.

I mostly did this hoping that removing code from here would make codecov's diff happy :D But that did not happen.

What are your contributing guidelines? Do we need to satisfy test coverage here since we are just calling out to our SDK? (which has plenty of tests there).

[hellt]

No worries @adrianosela, it is fine to have gaps in test coverage for the parts related to b0 integration.

So for my understanding, is email/pass-based auth is completely legacy and everything can be done with the new flow? If yes, then I am in favor of removing the email/pass code parts completely

[codecov]

Codecov Report

Attention: Patch coverage is 5.88235% with 64 lines in your changes are missing coverage. Please review.

Project coverage is 53.58%. Comparing base (be59f0f) to head (32e4f39).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1990      +/-   ##
==========================================
- Coverage   53.58%   53.58%   -0.01%     
==========================================
  Files         160      160              
  Lines       11536    11518      -18     
==========================================
- Hits         6182     6172      -10     
+ Misses       4489     4482       -7     
+ Partials      865      864       -1     

Files	Coverage Δ
border0_api/border0.go	44.94% <33.33%> (+9.14%)	⬆️
cmd/border0.go	13.51% <4.61%> (-48.03%)	⬇️

[adrianosela]

@hellt

With respect to the email + password flow: the email + password (programmatic) authentication IS formally deprecated. However, at the time of deprecating such logins, we opted to allowlist a handful of users who were using the feature to continue to use it in order to prioritize speed of rolling out the new (more secure) authentication flow. Some of these users (at least one of which is definitely a containerlab user) are still active today. We should figure out together if we want to:

• remove support for the legacy auth flow from this repo (and reach out to them to let them know since its only a few users)
• simply keep it in here since its hidden from the command tree and docs + new users cannot use it anyways.

---

I'd be happy to strip out a lot of code from here, but I think we should have a live conversation after you've given the new Border0 Connector based flow a try and we'd figured out together exactly how you'd/we'd like containerlab users to manage their policies and sockets with the new flow.

Take your time, we are in no rush :)

---

It seems historically in containerlab you would define Border0 policies and sockets in the config yaml directly. We should figure out if you want to keep supporting that and if so we'd have to make some adjustments to the code here. With the connector model (as in the docs linked above) everything is remotely managed, instead of static-config managed. However we could add a border0 command here to create and link the resources in static config to a connector anyways.

Let's follow on our ongoing email thread until we have clarity. cc:// @atoonk

[hellt]

@adrianosela after playing with this a little bit I wonder why do we want to tie this in to containerlab via the tools command?
This seems to be a generic connector of type "docker host" that makes a lot of sense, but it got me wondering if this should be coupled to containerlab at all?

What I mean is I think it would make a lot of sense if clab tools border0 setup emit a docker run command instead of a yaml blob. Maybe even start a container using the docker client that is part of the clab already.

I might be missing something here, but I think a single b0 container providing a connector is really all we need. It is easier to setup and requires fewer steps.

[adrianosela]

Hey @hellt - that sure sounds more reasonable! Since the B0 container isn't really part of the lab's topology (and if a customer wants to do that they can still do it themselves).

Our internal priorities have shifted quite a bit. I don't anticipate any work here in the next ~2 weeks. But we'll get back to it soon enough.