Configuring default_user and default_pass in rabbitmq.config is insecure

[wenchma]

rabbitmq.config template file contains default_user and default_pass which are plain text, it is going to be a security risk.

{default_user, <<"<%= node['rabbitmq']['default_user'] %>">>},
{default_pass, <<"<%= node['rabbitmq']['default_pass'] %>">>}

In my opinion, we should remove the two configuration items.

[michaelklishin]

@wenchma those two matter for MQTT users. The right thing to do is to use encrypted data bags.

[wenchma]

@michaelklishin yes, those two matter is stored in encrypted data bags in encrypted text, but the values fetched from data bag are decrypted, the values are also configured in rabbitmq.config with plain text(decrypted text).
In fact, we don't need to configure the two matter, and rabbit also works well, the values are stored in rabbit database.

[michaelklishin]

@wenchma the solution should be then to not have these attributes in your data bags. Yes, RabbitMQ can operate without those values but clients that connect w/o credentials often can't use the default user "guest" (because it does not exist on many production systems).

Anyway, the point is that if this does not work for you, the cookbook doesn't need to be modified, you should either

• Not specify the attributes
• Use Encrypted data bags

Encrypted values are not currently supported by RabbitMQ (technically, Erlang's application) and if that isn't OK with you, the solution is to not have such values in the config. For which no cookbook modifications are necessary.

[wenchma]

@michaelklishin my concern is that exposing the password in plain text is not secure, but the two attributes have to be specified for clients' connecting.
Of course we specified the two attributes with the values which make sense for itself in actual deployment.

Does not expose the password in plain text in rabbitmq conf file, it will look like better, isn't it ?

[michaelklishin]

the two attributes have to be specified for clients' connecting

That's not true. Unfortunately, authentication in MQTT is optional. It is a really bad idea if you ask me
but that's just what the committee decided on. Like I said earlier, encrypted config values are not supported by RabbitMQ at the moment. Sorry. Removing these values means one of the features
of MQTT that is not listed as limitation in RabbitMQ documentation won't be available to the users.

RabbitMQ has pluggable authentication mechanisms, e.g. you can authenticate using x509 certificates or LDAP. This can be extended to MQTT to a large degree.

In the meantime, you can specify random values for default_user and default_pass and not use credential-less authentication in your apps.

[kramvan1]

Would another option be to add an IF check to the template such that when the default_user is nil, these two lines are not added to the conf file?

[kramvan1]

Ok, maybe we should step back and re look at what is being asked for here. Based upon this doc: https://www.rabbitmq.com/access-control.html a user named guest will be created. The requirement here is for a "No Guest" configuration. Meaning, this cookbook should be changed as follows:

• allow an option for not having a guest account [rabbit][allow_guest] = false (default is true)
• in the default recipe after server is started:

rabbitmq_user 'remove rabbit guest user' do

user 'guest'

action :delete

not_if { node[rabbit][allow_guest] }

end

• in the rabbit conf template, no need to put guest in there as it's handled by server.

<% if node['rabbitmq']['default_user'] != 'guest' -%>

{default_user, <<"<%= node['rabbitmq']['default_user'] %>">>},

{default_pass, <<"<%= node['rabbitmq']['default_pass'] %>">>}

<% end -%>

No change in current behavior, but cleanup guest from server and conf if asked for.
Reasonable?

[wenchma]

@kramvan1 it looks like a good method to address this problem.

[cmluciano]

@wenchma Do you still need a fix for this?

[wenchma]

@cmluciano yes, I still need a fix, these two attributes should be only stored in rabbitmq db, not exposed in the conf file.

[cmluciano]

@wenchma Does #237 work for you?

[jjasghar]

@cmluciano and @wenchma seriously it's a clever fix. works for me ;)

[cmluciano]

Fix provided by #237 closing now due to inactivity