search

rabbitmq / credentials-obfuscation

Tiny library/OTP app for credential obfuscation
Other
14 stars 8 forks source link

Version 2.0.0 #5

Closed lukebakken closed 4 years ago

lukebakken commented 4 years ago

Use of the library has changed so that end-users are required to set the secret at some point after the application is started. This allows RabbitMQ to set the secret to the cookie after distribution is started.

Removes the use of an ETS table in favor of gen_server state.

michaelklishin commented 4 years ago

One downside of using a gen_server is that sensitive information can potentially be logged in a crash report of this new process, which is one of the things we tried to avoid in the original design by using an ETS table.

Another is that we now have a single process bottleneck. This is not an issue for obfuscation use cases in RabbitMQ, though.

lukebakken commented 4 years ago

I can revert to using an ets table!

michaelklishin commented 4 years ago

I'd prefer an ETS table. It would be less code we have to maintain and lower probability of secrets accidentally being logged anywhere by the runtime.

lukebakken commented 4 years ago

If we want the ETS table to be protected, we'll still have to use a known process to update the secret value (as in when RabbitMQ starts and the cookie is known, for instance). The previous version set the secret when the "fake supervisor" process started, but you couldn't update the value later on.

michaelklishin commented 4 years ago

This is a good point. Let's keep a single process then. Observability so far has been a bigger problem than sensitive value leaking from this library.

lukebakken commented 4 years ago

Ok, got it. Making some more changes to allow refreshing configuration after app start. Since credentials_obfuscation is a dependency of rabbit_common, it starts at the very beginning of RabbitMQ startup ... well before other configuration and the cookie is available :partying_face: