[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.

[aaron-seo]

Also, courtesy of @SimonUnge for inspiration here :)

[michaelklishin]

Option 3 sounds a lot more complex than 2 if you consider what it will do to the chain of responsibility that the authN/authZ backends form. It will now have several conditions it currently does not have.

With option 2 you create a new chain and use it from rabbitmq_management and rabbitmq_prometheus only. The original one does not change.

[michaelklishin]

You can combine option 2 with a new "composed backend" specific to a couple of plugins.

In fact, such a composed backend similar to rabbit_auth_backend_cache in and of itself can be a viable option 4 but in particular can work well together with option 2.

[michaelklishin]

I have asked the rest of the team to take a look. It's already well into the evening for most of them, so we will have to wait until tomorrow.

[aaron-seo]

I have asked the rest of the team to take a look. It's already well into the evening for most of them, so we will have to wait until tomorrow.

No worries at all :) and thank you!