Expose a method for encrypting using a remote v2_key

[carbonin]

These keys are saved as a part of configuring central admin.
When encrypted data must be send to a remote region, that data has to be encrypted using the remote region's encryption key.

This allows callers to encrypt the data so that the remote region can use it properly.

https://bugzilla.redhat.com/show_bug.cgi?id=1400995

/cc @bdunne @gmcculloug @gtanzillo

[carbonin]

I'm still looking into what it would take to add a #decrypt

Right now only MiqPassword#encrypt takes a key file as a parameter, so I would have to explicitly set MiqPassowrd's @@key_root to get decrypt to work with an alternate key.

Alternatively, I could use the v2_key= method, but that says "used by tests only". How strict should be about following that. @kbrock what do you think?

[gtanzillo]

LGTM 👍

[miq-bot]

Checked commits carbonin/manageiq@511e666~...c81afae with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1
2 files checked, 0 offenses detected
Everything looks good. 🍪

[carbonin]

Okay, so after a talk with @kbrock it looks like the current approach with setting the v2_key directly with MiqPassword.v2_key= causes a thread safety issue. Other things using MiqPassword.encrypt will end up using the v2_key we set rather than the one they expect.

I think the best route would be to punt on decrypt until we can make the required changes to MiqPassword so that we don't have to worry about the thread safety issues.

[carbonin]

Okay, @bdunne waiting on your review, then we can merge this and I'll pass the BZ to you.

[carbonin]

ping @bdunne

I think we still need this, not sure where this is on your priorities though...

[simaishi]

@carbonin @bdunne I see the BZ is closed as not a bug. Does this still need to be backported to Euwe?

[carbonin]

@simaishi Nope, I'll change the flag. This will actually likely be removed/refactored soon.