[Suggestion] Allow loopback users to override disable_basic_auth

[aaron-seo]

RabbitMQ series

4.1.x

Operating system (distribution) used

Linux

How is RabbitMQ deployed?

Other

What would you like to suggest for a future version of RabbitMQ?

If users of a RabbitMQ broker want to use OAuth2 (for instance) and disable basic auth, an operator must also use OAuth2 to auth with the broker. However, there may be a desire to override the disabling of basic auth for loopback users, so operators do not have to depend on an external OAuth2 provider for monitoring purposes; all the meanwhile, their basic auth access to the loopback user is still secure from external connection attempts.

The proposal here is to add a configuration -- maybe something like loopback_basic_auth_override = true | false, such that when:

...
loopback_users.my_monitoring_user = true
loopback_basic_auth_override = true
management.oauth_disable_basic_auth = true
...

then my_monitoring_user is able to auth into the broker's management plugin (namely, interested in the API here), only via localhost. The naming of loopback_basic_auth_override may be unclear and can be improved I think. And this should extend beyond just OAuth2, and can apply for the other auth backends (i.e. LDAP).

Would love to hear the team's thoughts on this.

[michaelklishin]

So the idea is to extend rabbit.loopback_users to the HTTP API when used specifically with Basic Auth?

[michaelklishin]

I guess

management.oauth_falls_back_to_basic_auth_on_loopback = true

can be considered.

Note that management.oauth_disable_basic_auth is also, if not primarily, used in the UI code,
where we have access to the page's hostname.

How to best integrate it is a good question.

I have forwarded to the rest of the team.

[Zerpet]

I like this proposal, I think it's reasonable, and scoped to loopback users, so it should not be a security concern.

I like more the OP proposed setting name, perhaps if we prefix it with management as:

management.loopback_basic_auth_override = true

Because it is explicit in its scope (management + loopback), and it's precise in its intention (basic auth override). I'm not very keen on oauth_falls_back_to_basic_auth_on_loopback because a fallback, generally, means that the primary method (oauth) was attempted, and we are falling back to something else (basic auth). From the OP, the intention is to "ignore" the oauth mechanism and use basic instead, therefore I prefer the word "override" instead of "fallback" for this setting.

What should happen if basic auth is completely disabled in rabbitmq configuration? For example:

auth_backends.1 = oauth

loopback_users.my_monitoring_user = true
management.loopback_basic_auth_override = true
management.oauth_disable_basic_auth = true

Should this be considered an error on boot?

It is a caveat that we should consider and document explicitly IMO.

[michaelklishin]

I am checking for objections one last time and if none come up, this can be graduated to a more specific issue. @aaron-seo I assume you'd be interested in investigating an implementation?

[aaron-seo]

@michaelklishin Yup, I'll be interested in an implementation.

Will need to flesh out the expected behavior for the scenario that @Zerpet mentioned as well, which may be tricky since users that want to use the proposed functionality may want basic auth disabled completely (for external connections)

[michaelklishin]

Conflicting rabbitmq.conf settings should result in a node failing to boot. We can detect some of this right in the schema implementation, or in a function (possibly boot step but we tend to just use regular functions for validation) during node boot.

[aaron-seo]

I think we may need to discuss the expected behavior more. The use case that we were considering with this functionality is that we want to give operators/admins a way to monitor the broker (with the management plugin in this discussion's scope, but also perhaps Prometheus as well in the future) using localhost, always.

Thinking about this now, the proposed functionality as discussed above won't satisfy this need if basic auth isn't configured as a backend at all.

What are the maintainers' thoughts on providing a way to monitor a broker via localhost/loopback basic auth while blocking all other external basic auth connections?

There appears to be at least 2 ways to implement this:

1. In the context of this discussion, it would broaden the scope of the proposed functionality: something like management.loopback_basic_auth_override would still fallback to internal auth_backend, regardless of whether auth_backends.n = internal was configured or not. This approach seems not favorable, because it implicitly overrides auth_backends configuration, and it'll probably add weird paths in the access_control module.

2. Another approach is to make configuration of auth_backends for management plugin completely separate from the existing auth_backends.

In other words, something like this

auth_backends.1 = oauth

loopback_users.my_monitoring_user = true

management.auth_backends.1 = oauth
management.auth_backends.2 = internal
management.oauth_disable_basic_auth = true
management.loopback_basic_auth_override = true

This is a larger change, but I prefer this approach more, and it may offer more flexibility for users as well.

To prevent this from being a breaking change, management.auth_backends.n should default to auth_backends.n

It also avoids the boot failure scenario described in above comments as well.

[Zerpet]

It's still morning here, and coffee is still kicking in, so bear with me if I miss something obvious 🐻 From the options proposed, option 3 sounds very reasonable and simple. IIUC, option 3 means adding a toggle "loopback-only yes/no", and the internal backend would first check if the connection comes from the loopback, then proceed normally if positive, deny the request otherwise.

For authZ in this scenario, it can apply the same logic: you are authorized only from loopback connections. I mention this because option 3 assumes multiple backends, and as such, it could be a theoretical case where oauth authenticates, but denies the authZ, therefore, the second backend will be tested, and there could be potential for authorising the request. This could be surprising. I think this is more an edge-case, and mostly a virtual edge-case, but I think it's important to consider the potential impact of option 3.

I was wondering about adding a new plugin internal_loopback, that would behave exactly as the internal backend, but it will only accept connections from localhost. This option is also very explicit, it can potentially reuse a lot of existing code, and it won't be scoped to just management. I got some inspiration from a comment from @michaelklishin in our internal chat for this idea 🙂

[aaron-seo]

Option 3 is simple to use from a user perspective, and implementation may not be too complicated either; but I agree with the reasons @michaelklishin stated above, it would add additional condition checks and adds additional boot failure scenarios, which does not seem like a good precedence for Rabbit's auth system.

For that reason, I think we should go towards a solution that minimizes adding even more conditions to the existing system, and for me, adding a new auth_backend seems to be the solution that best follows that philosophy. It also would play nicely with option 2's proposal of plugin-independent ____.auth_backends._ configuration, although that can come separately.

Would a new auth backend like rabbit_auth_internal_loopback be merged upstream and supported first-tier, or would it be expected to live as a third-party plugin? From our perspective, it's important that we have a solution in the upstream, ideally, as opposed to a third party plugin.

[michaelklishin]

We will accept a new backend together with the switch of rabbitmq_management (plus rabbitmq_web_dispatch to be more precise) and rabbitmq_prometheus, if such a backend is a necessary piece of the puzzle.

[michaelklishin]

Contributed by @aaron-seo in #13818.