Feature request: support wrapped secrets

[leonboot]

Hi!

I'm looking for a way to securely deliver secrets onto my nodes, and believe the best way to go about that is to use Vault for secrets management. I've been reading up on support for this in Puppet, and came across documentation referincing the use of this Puppet module. After looking at the documentation, I'm rather certain that the recommended way of using Vault's AppRole authentication method (the method I prefer for having nodes authenticating with my Vault instance) is not supported by this module. The main issue seems to be the lack of support for unwrapping wrapped secrets here.

The way to use the AppRole as recommended by Hashicorp is as follows (translated to Puppet terminology):

1. The Puppet Server, authenticated with the Vault Server with, for instance, a token, by policy only has permissions to request secret ID's for AppRoles
2. The Puppet Server requests a secret ID for a specific AppRole from vault, and asks for it to be returned in a wrapped response (this results in a token that may be used by the node to retrieve the unwrapped secret ID)
3. The Puppet Server provides the wrapped response to the node and instructs it (via a Deferred call) to unwrap the secret, resulting in a usable secret ID
4. The Node (in the same deferred call) exchanges the role ID and secret ID for a token which it then may use to retrieve a specific secret, like a KV store value.

As far as I can tell from looking at the source code, step 3 is not implemented; only an unwrapped secret ID can be passed as an argument. It would be really nice if there is a way to pass a wrapped secret token to the lookup command, which would first be exchanged for the actual secret ID in the code. This might be as simple as detecting whether the secret ID is in fact a secret ID (seems like a UUID format) or a token (typically 3 lowercase letters, a period and then followed by random alphanumeric characters), and adding the unwrap logic before exchanging role ID/secret ID for an authentication token if the format is the latter. Or perhaps an unwrap: prefix for the secret ID?

[yakatz]

There are two ways to use the module right now:

1. All secrets are baked into the catalog and sent as a final full catalog to the node. The compilers need access to vault, but not the nodes.
2. Deferred, so the node itself does the lookup and the catalog never has the information. The nodes need access to vault, but not the compilers.

It seems like you are suggesting a hybrid: the compilers have permissions in Vault, but all machines need to be able to access vault to redeem the token. Since a resource can be either deferred or not deferred, but not both, I am not sure how you could actually do this.

[leonboot]

This is where my basic understanding of Puppet might be an issue, I'm not sure what compilers do, but to further explain the whole concept of the feature request: it is so that the Puppet Server has minimal knowledge of sensitive information that it does need to know.

From what I can tell, the vault_lookup method requires a role ID and secret ID if AppRole authentication should be used. This implies that the Puppet Server needs to know both these parameters, even though it does not need them, other than to pass them to the node using a Deferred call. The secret ID is considered sensitive and should only be known to the party that needs to exchange it for an authentication token. The linked document suggests that the server should request a secret ID from Vault in a wrapped form. Wrapped secrets can be wrapped one time only, and only within the timeframe specified by the wrap-ttl passed to Vault when requesting the wrapped secret. This ensures that only the node will have knowledge of the secret ID: it unwraps the secret, and should that fail, the secret is likely compromised (the secret was already unwrapped).

In this regard, how would one go about and get a secret ID and provide it to the agent? From what I can tell from the documentation, the preferred method is by setting VAULT_SECRET_ID? Should that be done on the node? Besides that, the secret ID should be short-lived, by TTL and/or maximum uses. Ideally a new secret ID should be generated (or preferrably provided in wrapped form by a trusted process, like Jenkins or Puppet.