Hello,

I'd like to start by saying thank you for this Puppet function.
It's really useful to integrate easily with Vault without needing to deploy additional tools like Vault agent etc...

We plan on deploying this function and use it on a fairly large scale.
Thus I studied the code quite thoroughly.
I noticed some features that could be added and about which I'd like your opinion.
I'm happy to contribute if you feel these ideas are useful !

Reuse Vault token and handle lifecycle of the identity token.

Currently the secrets are cached for the duration of the catalog compilation or application depending if deferred or not.
It is not the case for the token though, each secret lookup will result in a POST call to the login endpoint to get a new token.
Tokens are not revoked after the lookup either.

What do you think about caching the token as well (opt-in) ?
This would bring some additional complexities if we want to handle the lifecycle of the token (renew, extend TTL...).
But we could say that the token is cached for the duration of the catalog application, not extended nor renewed to avoid too many difficulties.
I do think revoking the token upon catalog completion could be nice no matter the decision about the token caching.

Handle HTTP rate-limit

Vault allows administrators to define some quotas above which clients will receive 429 responses.
Additionally Vault can be configured to send back rate-limit headers Retry-After, X-Ratelimit-Limit, X-Ratelimit-Remaining and X-Ratelimit-Reset as per RFC 9110.
These could be used to do intelligent retries without killing the backing Vault service.
It would of course need a max deadline to avoid hanging puppet for hours.
This max deadline should be configurable as well.

Let me know what you think about these ideas, again happy to contribute.

I'm having a problem with a puppet agent connecting to the vault cluster because of a cert issue. The vault endpoint is a puppet agent as well under the same primary server.
The vault listener is setup with a cert that was created off of our root issuing cert infra, but the puppet CA cert is separate.
The agent is setup to trust any cert signed by the root cert, but it appears the Puppet HTTP client is not trusting the cert.
I have tried adding the vault cert to the agent's CA bundle as described here: https://support.puppet.com/hc/en-us/articles/115000390993-Add-certificates-to-the-Puppet-certificate-bundle-in-Puppet-Enterprise
(I know I'm trying the approle auth that was just released but I suspect I would have this same issue with cert auth.)

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 2019.8.11 / 6.27.0
• Distribution: RHEL 8
• Module version: d00dda5

How to reproduce (e.g Puppet code you use)

  $role_id = 'xxxxxx'
  $secret_id = 'yyyyy'

  $d = Deferred('vault_lookup::lookup', ['aws/creds/build_role', 'https://vault:8200', nil, nil, nil, nil, 'approle', $role_id, $secret_id, nil])

  notify { 'vault':
    message => $d,
  }

Vault tcp listener

      "tcp": {
        "address": "<ipaddr>:8200",
        "tls_cert_file": "/etc/vault/vault.cer",
        "tls_key_file": "/etc/vault/vault.key"
      }

What are you seeing

when puppet is run:

Failed to apply catalog: certificate verify failed [unable to get local issuer certificate for ,CN=vault,OU=....]

What behaviour did you expect instead

successful puppet run

I've set this module up and it seems to work as far as allowing all Puppet agents to use the same policy by setting it at the auth/cert/certs/puppetserver as documented.

Is it possible with this method to give specific agents specific policies? If so, some documentation would be appreciated.

Since the 1.1.0 release of Vault, it has the ability to do auto-auth lookup as a daemonized agent. This includes certs, so the approach in the function stays the same, but the auth token would be cached and automaticaly renewed when needed. Also, it would mean that lookups for certain secrets that have a long lease time.

I did a write-up of the whole process here: https://petersouter.xyz/vault-caching-with-auto-auth-and-puppet/

However, this only works if the token is not given during lookup time, so the logic that does the cert auth and gets the token needs to be disabled for this to work.

I'm not sure how best to do this: a parameter that disables the token lookup (eg. $d = Deferred('vault_lookup::lookup', ["secret/test", 'https://vault.hostname:8200', :cert_auth => disabled])) or a new function that has the same logic but is named differently (eg. $d = Deferred('vault_lookup::lookup_agent', ["secret/test"]) that defaults to localhost:8200 or something like that

This would also resolve the issue of #7 & #16

Hello,

First of all, thanks for the module.

I'm trying to make this module work with a Vault Cluster exposing port 8200 with a Self-signed CA .

For the Deferred mode, It work after modifying the puppet.conf of the agent , by adding localcacert pointing to my CA, in the main section.

But for the "Puppet server mode" (without Deferred), (which I need because the configuration file that I want to deploy is a ERB template and the Deferred seem not work in this mode because its created on the server side.)

It give us Java errors :

Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

I tried adding the CA and even the vault node certificate in the Java Keystore, but it seem ignored. (after server restart)

Any feedback on this ?

I read that we need to use puppet'CA, but in my case, we have a specific CA different from the puppet one, and have to use it.

Until now, an vault server configured with ssl is needed.
But when the vault server runs on the agent system itself, then an normal none ssl session is ok.
And the needed token can be read from an locale file from the client, to which only root has access.
To there are only 2 additional parameters needed.
One boolean for local_mode and the second for the path to the token file.

Hi,

It would be useful (for me at least) if lookup could use a list of node URL's, instead of a single one.
Then, in two situations it could automatically try the next node in the list:

• in case there's no response from the node (maybe it's down or unreachable) (connection exception)
• in case the node is sealed (response exception)

Thanks.

Hello everyone,

I'm trying to use this module and get deprecation error.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.2.1
• Ruby:
• Distribution: Centos 7
• Module version: 0.1.1

How to reproduce (e.g Puppet code you use)

To check if module works, i'm trying to use code exact same with example in Readme.

What are you seeing

on line $d = Deferred('vault_lookup::lookup', ["secret/test", 'https://vault.hostname:8200'])
agent falls and I see an error:

Error: Failed to apply catalog: undefined method `http_ssl_instance' for Puppet::Network::HttpPool:Module Did you mean? http_instance

Looks like, module's code uses a deprecated ruby's module. I'm not really familiar with ruby, so I can't inspect this issue closer. Is there any solution?

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 6.28.0
• Ruby:
• Distribution: Windows Server 2019
• Module version: 0.6.0

How to reproduce (e.g Puppet code you use)

$v = vault_lookup::lookup('ad/creds/puppet',
  "https://vault.${trusted['domain']}:8200",
  'v1/auth/cert',
  'wsus',
  nil,
  'current_password'
)

What are you seeing

Error: Failed to apply catalog: Error parsing json secret data from vault response

What behaviour did you expect instead

Compiled catalog and value of current_password field retrieved.

Output log

Any additional information you'd like to impart

What are you seeing

The Vault address has to be provided within the Puppet code to use the lookup. It would be nicer if this was an optional parameter, and the Puppet agent could use the VAULT_ADDR environment variable to find the Vault address instead.

What behaviour did you expect instead

cat /etc/sysconfig/puppet
VAULT_ADDR=http://vault.example.com:8200

THen we dont have to specify

$d = Deferred('vault_lookup::lookup', ["secret/test"])

node default {
  notify { example :
    message => $d
  }
}

Output log

Any additional information you'd like to impart

While what's in place does work. it's restricted

You should be able to:
Allow retrieving a secret value from a kv1 vault secret engine
Allow retrieving a hash from a kv2 secret engine

The following api should be used to determine the kv version
https://support.hashicorp.com/hc/en-us/articles/4404288741139-Which-Version-is-my-Vault-KV-Mount-

It would be nice to have some sort of a password generation option to the vault_lookup function.

some usecases:

• lookup key has the hostname of the server "root/password/${hostname}" if the key and the secrect does not exists. vault_lookup will generate a new password and save it to Vault. So every server has a different root password
• bootstrap a new MySQL/MariaDB Server with a new mysql root password

The idea of this feature request to have Vault with the features of trocla (https://github.com/duritong/trocla). Trocla allows autogenerating a password if it does not exist.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.16.0 (PE 2021.6.0)
• Ruby: bunlded PE
• Distribution: RHEL6 and RHEL8
• Module version: 0.5

How to reproduce (e.g Puppet code you use)

Vault listener using Lets Encrypt cert
Vault listener config:
"tcp": {
"address": "0.0.0.0:8201",
"tls_disable": false,
"tls_cert_file": "/etc/letsencrypt/live/vault/fullchain.pem",
"tls_key_file": "/etc/letsencrypt/live/vault/privkey.pem",
"tls_client_ca_file": "/etc/puppetlabs/puppet/ssl/certs/ca.pem",
}
Run puppet agent -t with the code in readme

What are you seeing

Puppet shows Error: Failed to apply catalog: Received 400 response code from vault at https://:8201/v1/auth/cert/login for authentication (api errors: ["client certificate must be supplied"])

However connecting via curl works as expected. I am able to get a auth token
curl --request POST --cert /etc/puppetlabs/puppet/ssl/certs/<agent_cert>.pem --key /etc/puppetlabs/puppet/ssl/private_keys/<agent_key>.pem --data '' -vvv https://<vault_server>:8201/v1/auth/cert/login

What behaviour did you expect instead

For at least the authentication step to be completed

Any additional information you'd like to impart

Vault audit log confirms the puppet isn't proceeding past the auth stage

The Puppet CA is the default config for PE, there is no external CA.

Hi there,

your function works well with Vault port secured with Puppet certificates, however we needed to use Vault with multiple Puppet masters. For that I've made a fork of your repository, and updated it to use newer "HTTP::Client" library so that it will work with Vault secured with Letsencrypt certificates. I've tested it and can provide documentation as well. Can you please add me as a contributor, so that I can submit my changes as Pull Request ? I've created separate branch as "nikola".

Thanks

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.10.0
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

What are you seeing

What behaviour did you expect instead

Output log

Any additional information you'd like to impart

Is it possible to disable the check with a new key?

Scenario: Function is using cached results because cache_hash didn't change, which is correct, but in vault the password was changed. Since the field name hasn't changed, lookup is still using the cached key.

Hi there,

I've been using your code to pull not-so-secret bits of data out of the vault to use as facts. When I run facter, I get the following deprecation warning out of Puppet:

Warning: Puppet::SSL::Host is deprecated and will be removed in a future release of Puppet. (location: /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/ssl/host.rb:235:in initialize')
`
I'm getting this warning on puppet agent version 6.11.1. I expect your code will also be affected once V7 of puppet is released.

Cheers,
Nick

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: puppetserver version: 7.13.0
• Distribution: Centos9

How to reproduce (e.g Puppet code you use)

I've happened the following lines in /etc/sysconfig/puppet on the puppet server
VAULT_ADDR=https://xxxx:8200/
VAULT_NAMESPACE=admin/puppet
VAULT_AUTH_METHOD=approle
VAULT_ROLE_ID=xxxxxx..xxxx
VAULT_SECRET_ID=xxxx..xxx

What are you seeing

The module does not load the environment variable.

What behaviour did you expect instead

For the module to load these environment variables

The login endpoint is currently hardcoded as /v1/auth/cert/login. I think this differs between Vault setups, so this doesn't work for everyone. I'll be honest, I don't manage the Vault instance I'm hitting so I'm not sure what the difference is (something to do with AppRole? seems this also requires a name field in the request body).

• Does it seem reasonable to allow the login endpoint to be passed in?
• Can this be done without adding an argument/making a breaking change?

• https://github.com/pcarlisle added to the modules/admin team
• Repository transferred
• Github issues enabled
• Verify that all webhooks except travis are disabled
• Release a copy of your module to the ‘puppet’ forge account - to be done by @pcarlisle
• Add the module to our modulesync setup
• Add the module to our plumbing repository(handles travis secrets)
• Ask an admin to add the collaborators team to the module’s Collaborators & Teams ‘Teams’ list with Write permissions
• Execute modulesync for this module
• Sync labels

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: v7.2.4
• Ruby:
• Distribution:
• Module version:

How to reproduce (e.g Puppet code you use)

use approle with HashiCorp Vault

What are you seeing

Unable to authenticate (403 error)

What behaviour did you expect instead

Authenticate.

Output log

Any additional information you'd like to impart

Fix is in lib/puppet_x/vault_lookup/lookup.rb

Depending on the version depends on the line, but in current code, line 48

      approle_path_segment = 'v1/auth/approle'

should be
approle_path_segment = 'v1/auth/approle/'

(Missing / after approle)

If the lookup function throws an exception when used within an agent-side function (Deferred type), the whole catalog application will fail. This may not always be desirable, so we should allow the user to pass a flag disabling exceptions. When exceptions are disabled, the lookup function should log the error and return nil, instead of throwing.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7.17.0
• Ruby: 3.1.2p20
• Distribution: Fedora/Ubuntu
• Module version: latest

How to reproduce (e.g Puppet code you use)

I am trying to use this fuction with puppet bolt and no puppet-ca setup. So I am trying to use the approle auth for vault. If I curl with role_id and secret_id I can get a token so vault side is perfectly working.
I can also access my vault both via http and https (self signed cert).

Bolt plan:

plan project::class (
  TargetSpec $targets
 ) {
  $system_facts = run_plan('facts', 'targets' => $targets)
  $apply_result = apply($targets, '_description' => 'apply class') {
    $d = vault_lookup::lookup(
      'path/to/secret',
      'http(s)://vault.example.com',
      'approle',
    )

    notify { example :
      message => $d,
    }
  }

  $apply_result.each |$result| {
    $result.report['logs'].each |$log| {
      out::message("${log['level']}: ${log['message']}")
      out::message("--${log['source']}")
    }
  }

  return $apply_result
}

What are you seeing

When trying to read a secret from vault via https I get:
certificate verify failed unable to get local issuer certificate.
But the root ca is definatley trusted by linux.

When trying to read a secret from vault via http I get:
Received 404 response code from vault at http://vault.example.com/approle/login for authentication.
I exported environment variables as described in the documentation.

What behaviour did you expect instead

It is expected to read a secret from vault.

Any additional information you'd like to impart

I feel like environment variables are not beeing used, cause I have to set auth_method to approle as a function parameter otherwise I get redirected to http://vault.example.com/cert/login.

Would be nice if anyone could help me!

Please release 1.1.1 with approle trailing / url fix.

Affected Puppet, Ruby, OS and module versions/distributions

• Puppet: 7
• Distribution: Debian 11
• Module version: master branch

How to reproduce (e.g Puppet code you use)

When i use the master branch code i have this exception - "undefined local variable or method 'vault_role_id'"
I think it's a omission during modification names vault_role_id to role_id and vault_secret_id to secret_id