Backend should support proper authorization

[dbnicholson]

Currently the way the backend manages access to privileged methods is through IP address matching. This requires either:

• The frontend and backend to run on the same host so the frontend requests arrive from loopback addresses.
• The frontend to operate from fixed IP addresses.
• The frontend to operate on it own subnet.

All of those options are too simplistic to support dynamically allocated frontend instances. This can already be seen in the worker ACL:

'.*' => 'worker',   # build results can be delivered from any client in the network

This acknowledges the fact that workers are likely on different hosts that can't be matched simply and lets any request that can reach the repo server submit completed packages. You can drop these rules and mimic the IP ACLs externally to OBS a bit, but you lose the ability to segment the HTTP requests by path.

It would be better if the backend supported request level authorization. Then the network architecture wouldn't matter as any privileged request would require proof that the sender was allowed to do what they were trying to do.

With a regular HTTP server this would be pretty straightforward. However, even with the backend's homegrown HTTP server it seems possible as HTTP basic authorization is just a base64 encoding of username and password. Ideally you'd also use encryption and certificates like normal HTTP usage, but I think just sending credentials in the open and hardcoding the frontend and worker credentials into the configuration would be a good start.

For example in BSConfig.pm:

my $frontend_user = "frontend";
my $frontend_password = "somepassword";
my $worker_user = "worker";
my $worker_password = "otherpassword";

Then change the frontend and worker to send Authorization headers in their HTTP requests.

[hennevogel]

There is something like that based on client certs #14183

[dbnicholson]

There is something like that based on client certs #14183

Sure, client certificates could work rather than basic auth, but it's more for authentication and difficult to use for authorization. That PR seems a lot more concerned about TLS (very useful in its own right!) and not authorization. It also doesn't seem to have any of the backend implementation.