Why remove LOGIN_REQUIRED?

[tcaiazza]

Netbox 5 is slated to Remove support for unauthenticated access (LOGIN_REQUIRED)

We have dozens of tools if not hundreds of tools that rely on unauthenticated reads.

I'm curious as to why this is being done. Is there a technical reason behind it? I'm happy to accept the security risk with enabling it but to completely taking away the option and control from users seems like a bad direction for the project.

[jcollie]

Personally, I think that it would be irresponsible of NetBox Labs to leave LOGIN_REQUIRED=False a possibility. Having any sort of unauthenticated access to such an important service is a disservice. You'll be glad some day that you went to the effort of fixing up your tools to support authenticated access.

If you really need unauthenticated access, put a proxy in front of NetBox that inserts the proper authentication header.

And if you really really need it, NetBox (the community edition at least) is open source. You have all the control that you need.

[jeremystretch]

The justification for the change is cited in #21936, which deprecated the parameter in NetBox v4.6.0:

The LOGIN_REQUIRED parameter was originally introduced with the intention of allowing easy access to demonstrative deployments of NetBox. It has been disabled by default since NetBox v4.0.2 (see #16107) and no longer serves a practical purpose.

The change represents a small portion of our ongoing initiative to improve NetBox's overall security posture. Given the highly sensitive nature of the data typically maintained in NetBox, we have always discouraged users from permitting unauthenticated access. Beginning with NetBox v5.0, this configuration will no longer be supported in the core product.

Of course, NetBox is open source software: Should you wish to continue providing unauthenticated access to your users, you retain the option of modifying the software to do so.

[tcaiazza]

My argument here is that LOGIN_REQUIRED=FALSE does in fact serve a practical purpose, even outside its originally demo purposes. For example, A newly unboxed server CURLing netbox as part of its provisioning process is a whole lot harder when that fresh machine needs credentials. Healthchecks being another one.

[svalouch]

We provide facts to hosts with a small plugin that exposes just the required information as JSON and the host can then learn about itself. It's far easier to argue about security if you poke small holes like that.

The same should work for health checks and get rid of the ton of django error mails if the cache or db has a problem.

[svalouch]

Cooked up a gist with a minimal example: https://gist.github.com/svalouch/0ad35e9a23d37397c4440dd18e5780ca