all auth'd commands should optionally take the decryption-passphrase

[anEXPer]

We'd like the env information om uses for all its authorized commands to optionally include the decryption passphrase, so that if the Ops Manager has been restarted, commands can still work.

This is a little bit of a counter-intuitive or maybe too-clever idea, so we want to lay out what we're thinking very clearly.

1. Any time the Ops Manager VM is restarted, it needs to be decrypted before it can be used.
2. Ops Manager VMs may be rebooted at any time, because IaaSs
3. om is intended to be CI-native, that is, make design decisions that maximize it's value in a CI/pipeline/build context.
4. Given 1 and 2, any use of om in an automatic build will need to ensure the Ops Manager is decrypted before attempting to use it.
5. The decryption-passphrase is not necessarily more or less sensitive than the Ops Man login information that would ordinarily be provided as a target. It's differently sensitive; env information combines with a running Ops Manager to give up everything (or potentially not-everything, if there's RBAC or whatever), while the decryption-passphrase pairs up with an exported installation to give up everything (with no RBAC or whatever to mitigate it).

Conclusion: given 4 and 5, it would be useful for operators to have the option to provide the decryption passphrase for all om commands, so that they can make the appropriate trade-off between reliability and security for their particular context.

This also smooths out a problem in our automated upgrade workflow about which flags are in which config files.

This would remove the need for a config file for import installation, as it would be able to get the information it needs as part of the env file. The decryption passphrase could be required for this particular command.

[ljfranklin]

Sounds interesting! To double check, the proposed workflow is:

• the global decryption-passphrase is optional for all commands
• if the OpsMgr is already running/decrypted, the decryption-passphrase is unused
• if a request is made to an OpsMgr which is "locked", om will transparently unlock it if the decryption-passphrase was provided
• if a request is made to an OpsMgr which is "locked" and the decryption-passphrase was not provided, raise an error

If so, sounds reasonable to me 👍

[anEXPer]

Yes, you have accurately described what we want to do, thanks for pulling out a crisp articulation.

[fredwangwang]

We're going to start working on a PR for this.

[anEXPer]

We're discussing how to handle the fact that --decryption-passphrase is currently required as a command argument by import-installation.

We think ideally, we'd keep the interface consistent, and use it as a global flag - but in the case of import-installation, the typically-optional flag would be required. In this scenario, we'd remove any command-specific mention of the flag, which would be a breaking change. We might have to mention it's required for import-installation in the global description?

Alternatively, we could leave the command argument for import installation, and allow it to be "optional" if the argument has been provided as a global argument. This would have the virtue of being non-breaking, but would be kind of confusing and weird to document in the help.

Thoughts?

[ljfranklin]

I'm fine with making a breaking change in this case, we'll just need to make sure to document the change in the release notes. A single global flag that is required for import-installation but optional otherwise sounds good to me.

[fredwangwang]

The PR's merged! Thanks.