GitHub puppet-vault_lookup

Pull Request (PR) description

This PR adds support to query just a single element of a secret, and return it as a Sensitive string. This makes it easier to pass a specific secret to another resource, as you don't have to deal with a hash of elements.

<!--
Thank you for contributing to this project!

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

This Pull Request (PR) fixes the following issues

<!--
Fixes #7
-->

Pull Request (PR) description

The primary goal is to check CI status…

This Pull Request (PR) fixes the following issues

<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->

Possible alternative to https://github.com/voxpupuli/puppet-vault_lookup/pull/21

This solution uses a second dispatch instead of having either an almost
entirely duplicated function or introducing a 2nd optional parameter.

UNTESTED!!

If a lookup function raises an exception, the whole catalog compilation will fail. This PR adds the ability to configure the lookup to not raise and instead simply log and return nil if it encounters an error, so that the users can structure their manifests to only conditionally depend on the result of the lookup.

We're not sure if this is useful or not, and are looking for use cases and feedback on the approach.

Fixes #13

Pull Request (PR) description

Adds path information for data lookup errors when needed

As of now when puppet fails to apply catalog vault_lookup returns message with no clue where error happens:

Error: Failed to apply catalog: Received 403 response code from vault at vault.local for secret lookup (api errors: ["1 error occurred:\n\t* permission denied\n\n"])

With proposed change you can see which lookup actually related to the problem:

Error: Failed to apply catalog: Received 403 response code from vault at vault.local for secret/data/puppet/service/graylog/s1/config lookup (api errors: ["1 error occurred:\n\t* permission denied\n\n"])

<!--
Thank you for contributing to this project!

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

Pull Request (PR) description

Adds support for Vault KV2 format secrets and allows addressing a key within a vault secret

With 0.4.0 a kv2 returns a complete hash including creation version and other metadata. this fails to be converted to a string causing an agent compile error

This Pull Request (PR) fixes the following issues

Fixes #21
Fixes #25

This PR adds support to use AppRole Vault's auth method.
It also adds support for configuring vault_lookup function using a configuration file as in https://github.com/voxpupuli/puppet-prometheus_reporter/blob/master/lib/puppet/reports/prometheus.rb#L12

<!--
Thank you for contributing to this project!

• This project has a Contributor Code of Conduct: https://voxpupuli.org/coc/
• Please check that here is no existing issue or PR that addresses your problem.
• Our vulnerabilities reporting process is at https://voxpupuli.org/security/

-->

Pull Request (PR) description

After trying this module out -- I found I could not use it in actual "useful" way yet. I have a path ssl/test which has two keys under it -- cert and key. When I retrieve that, I am unable to get at the either of the subkeys in any way I could figure out. If I am just missing it, please let me know how. =) But I couldn't, for example, do $d['cert'] or any form of that that I could discover. Puppet rejected it as "this is not a hash, it is an object". I saw a few semi weird "double deferred" solutions but they weren't quite working either. I whipped up what is basically a copy of the lookup function but that accepts a key argument. It is working great in my setup so far.

Please note I do not want you to merge/accept this as is -- I would like a chance to clean it up, add some tests, etc before it is potentially merged.

I don't really like doubling up on the functions within the Puppet function definition -- in fact at first I tried to do a quick lookup_key that actually called lookup, unwrapped the return, pulled the key, rewrapped that, and returned it. However I was in a bit of a hurry and did it this way for the moment.

Good? Bad? Meh? Seemed like a quick way to get at what I needed. =) If you like the idea but have some suggestions on how to improve it please send them my way. I've also left it open to maintainer edits so have at it. (I'm using master in production currently)

This Pull Request (PR) fixes the following issues

n/a