GitHub puppet-vault_lookup

Repo Checks ( 10 of 19 successfull )
Metadata Valid
No translation
passed
Correct Puppet Version Range
Supported Puppet version range is %{PUPPET_SUPPORT_RANGE}
passed
With Puppet Version Range
Puppet version range is present in requirements in metadata.json
passed
With Operatingsystem Support
No translation
passed
Supports Only Current Centos
No translation
failed
Supports Latest Centos
No translation
failed
Supports Only Current Debian
No translation
failed
Supports Latest Debian
No translation
failed
Supports Only Current Ubuntu
No translation
failed
Supports Latest Ubuntu
No translation
failed
Supports Only Current Fedora
No translation
failed
Supports Latest Fedora
No translation
failed
In Modulesync Repo
Is listed as a module managed using modulesync_config
passed
Synced
Has a .msync.yml file
passed
Latest Modulesync
Has been synchronized with the latest tagged version of modulesync_config
passed
Has Modulesync
Is present in voxpupuli/modulesync_config/managed_modules.yml
passed
Released
Is in modulesync_config and in forge releases.
passed
Valid Sync File
If a (optional) sync file is present, it must not contain a `.travis.yml` entry.
passed
Reference Dot Md
The repository has a REFERENCE.md. It needs to be generated / puppet-strings documentation is missing.
failed

Open Pull Requests

WIP: RFC: Support looking up with a key
tests-fail

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!!

Open PR in GitHub
Allow the user to prevent the lookup from raising an exception

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

Open PR in GitHub
Restrict field
tests-fail

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.

Open PR in GitHub
Add support for Vault Namespaces
tests-fail

Pull Request (PR) description

This PR add support for Vault Namespaces.
It supersede #28

This Pull Request (PR) fixes the following issues

n/a

Open PR in GitHub
removing use of deprecated call
tests-fail

this call created more issues then it is obvoius, maybe this is why it was made deprecated.
it reuses default ssl validator from Puppet.
this validator magically not working with anything but puppet master or server which uses puppet CA cert.
I simply created required SSLContext because in puppet docs I could not find how to create it easier.
Idealy it should be cached between invocation of functions, however I could not find a way how to do it.

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

-->

Pull Request (PR) description

<!--
Replace this comment with a description of your pull request.
-->

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
-->

Open PR in GitHub
Add path information for related lookup errors
tests-fail

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"])

Open PR in GitHub
function updated to include option to specify optional parameters for …
tests-fail

function updated to include option to specify optional parameters for namespace, custom cert path, custom cert role name and key field

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

-->

Pull Request (PR) description

<!--
function updated to include option to specify optional parameters for namespace, custom cert path, custom cert role name and key field
-->

This Pull Request (PR) fixes the following issues

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

Open PR in GitHub
Add support for AppRole auth method. Add support for configuration file.
tests-fail

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

Open PR in GitHub
Add lookup_key function to get at a specific key value
needs-docs
needs-tests

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

-->

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

Open PR in GitHub
Remove use of deprecated http_instance method, SSL verification parameterized
tests-fail

Pull Request (PR) description

This PR removes the use of the deprecated http_instance method and replaces it with the suggested connection method instead.

Using the new connection interface, it's possible to specify an SSL context, and therefore whether or not to verify SSL connections. I've implemented this as an optional parameter that defaults to true (ie: the default behaviour should remain unchanged).

By parameterizing SSL verification, it's possible to connect to established Vault instances over HTTPS, that are outside of the PKI chain established by the Puppet server. Given that the plugin currently allows the option of HTTP connections, it doesn't seem less secure to also optionally disable SSL verification.

I'm not very familiar with Ruby development, so I've not modified any of the existing tests, but if there aren't any objections to this new approach, I'm happy to try and write tests covering the new functionality, and reflecting the change in Puppet API interface use. Anecdotally, I have tested this with my own Vault (1.1.0) server and Puppet setup (6.4.0) and it works under normal use.

This Pull Request (PR) fixes the following issues

n/a

Open PR in GitHub
Add local mode and remove deprecated http_instance call
tests-fail

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

-->

This Pull Request (PR) fixes the following issues

<!--
Fixes #7
-->

Open PR in GitHub
Update to work with HTTP::Client to work with Vault secured with other CA like Letsencrypt

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

-->

Pull Request (PR) description

<!--
This PR contains changes for module to use up-to-date Pupper::HTTP::Client, which will allow puppet agents to access Vault secured with other Certificate Authority certificates, including Letsencrypt. That will also allow Vault to work with multiple Puppet Servers (or Masters), of course each Puppet Server CA will need to be imported into Vault auth/cert/certs/ with a different name.
Changes to the module are compatible with old module, and will not change its function.

To use Vault secured with other CAs, 2 other changes are needed on every Puppet agent configuration that need to access this module:
- Disable certificate revocation, in /etc/puppet/puppet.conf add line
certificate_revocation = false
- It is also required add bundle of CAs at the end of "/etc/puppet/ssl/certs/ca.pem"
for example for Letsencrypt CAs we added
- Let's Encrypt Authority X3
- ISRG Root X1
- ISRG Root X2
These can be found and copied from CA bundle files, on Debian they are in "/etc/ssl/certs/ca-certificates.crt" or on RedHat in "/etc/pki/tls/certs/ca-bundle.crt"
-->

This Pull Request (PR) fixes the following issues

<!--
Replace this comment with the list of issues or n/a.
n/a
-->

Open PR in GitHub