Lookup plugin

[SimonBarendse]

Feature request

An Ansible lookup plugin to lookup secrets from SecretHub.

The plugin should accept the same optional parameters as the modules:

Parameter	Description
cli_path	The path to the CLI binary to use. To set this globally the environment variable SECRETHUB_CLI_PATH can be set. When omitted, a default of /usr/local/secrethub/secrethub or C:/Program Files/SecretHub/secrethub.exe (on Windows) is used.
config_dir	The configuration directory to use. To set this globally the environment variable SECRETHUB_CONFIG_DIR can be set. This is where we look for a credential when it is not supplied trough the module. Defaults to a .secrethub directory in the home directory.
credential	The credential used to decrypt your accounts encryption key. To set this globally the environment variable SECRETHUB_CREDENTIAL can be set. When omitted, the credential must be stored in the configuration directory.
credential_passphrase	The passphrase to decrypt the credential with. To set this globally the environment variable SECRETHUB_CREDENTIAL_PASSPHRASE can be set.

Example

- start_app:
db_user: "{{ lookup('secrethub', 'company/infra/app/db_user') }}"
db_pass: "{{ lookup('secrethub', 'company/infra/app/db_pass') }}"
slack_token: "{{ lookup('secrethub', 'company/infra/app/slack_token') }}"

Motivation

Because a lookup plugin can be used inline, where the secret is used, the secret does not have to be registered in a variable. By limiting
the scope of the secret, it is clearer where it is used and it is harder to leak the secret to another module.

Another advantage of the inline use of a lookup plugin is that less boilerplate is needed to do a simple read:

- secrethub_read:
path: company/infra/app/secret
register: my_secret
- another_module:
secret: "{{ my_secret.secret }}"

versus:

- another_module:
secret: "{{ lookup('secrethub', 'company/infra/app/secret') }}"

Considerations

Generate

We could add parameters to the lookup plugin to generate or set the secret when it is not yet present. However, I do not think that is desirable.
The lookup plugin can then change the state of the secret without that popping up in the playbook's log.
When generating the secret in the secrethub_generate module and then looking it up where used, the secrethub_generate module will report
whether running the playbook has changed the state of the secret. We can (and must) implement --check support for the generate module such
that running the playbook with --check reports whether the play will generate a new secret. This is not possible when generating the secret
with the lookup plugin.

I therefore suggest not to implement this right now. We can still add it later when arguments are raised that support this functionality.

Evaluation

Contrary to modules, lookup plugins are evaluated on the control machine. Therefore, the configuration directory used should be
on the controller machine. When no credential is supplied, the credential of the controller is used. This differs from the
secrethub_read module, where the credential on the target machine is used when no credential is suppplied.

I don't think this difference is problematic, as long as we document it clearly.