{"id":23727742,"url":"https://github.com/voxpupuli/puppet-vault_lookup","last_synced_at":"2025-04-09T07:09:30.030Z","repository":{"id":37742813,"uuid":"152132065","full_name":"voxpupuli/puppet-vault_lookup","owner":"voxpupuli","description":null,"archived":false,"fork":false,"pushed_at":"2025-03-19T19:11:35.000Z","size":233,"stargazers_count":26,"open_issues_count":21,"forks_count":45,"subscribers_count":46,"default_branch":"master","last_synced_at":"2025-03-19T21:50:16.215Z","etag":null,"topics":["centos-puppet-module","debian-puppet-module","fedora-puppet-module","hacktoberfest","linux-puppet-module","oraclelinux-puppet-module","puppet","redhat-puppet-module","scientific-puppet-module","sles-puppet-module","ubuntu-puppet-module","windows-puppet-module"],"latest_commit_sha":null,"homepage":null,"language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/voxpupuli.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":".github/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"open_collective":"vox-pupuli","github":"voxpupuli"}},"created_at":"2018-10-08T19:07:35.000Z","updated_at":"2025-03-19T14:31:18.000Z","dependencies_parsed_at":"2023-12-15T03:49:14.740Z","dependency_job_id":"945a3483-eb57-4150-8106-ab05e3ef84df","html_url":"https://github.com/voxpupuli/puppet-vault_lookup","commit_stats":{"total_commits":126,"total_committers":21,"mean_commits":6.0,"dds":0.8015873015873016,"last_synced_commit":"d90383bed5470a65a7b600d858842aaef72c072d"},"previous_names":[],"tags_count":10,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-vault_lookup","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-vault_lookup/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-vault_lookup/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/voxpupuli%2Fpuppet-vault_lookup/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/voxpupuli","download_url":"https://codeload.github.com/voxpupuli/puppet-vault_lookup/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247994122,"owners_count":21030050,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["centos-puppet-module","debian-puppet-module","fedora-puppet-module","hacktoberfest","linux-puppet-module","oraclelinux-puppet-module","puppet","redhat-puppet-module","scientific-puppet-module","sles-puppet-module","ubuntu-puppet-module","windows-puppet-module"],"created_at":"2024-12-31T01:29:51.851Z","updated_at":"2025-04-09T07:09:30.012Z","avatar_url":"https://github.com/voxpupuli.png","language":"Ruby","funding_links":["https://opencollective.com/vox-pupuli","https://github.com/sponsors/voxpupuli"],"categories":[],"sub_categories":[],"readme":"# vault_lookup\n\n[![Build Status](https://github.com/voxpupuli/puppet-vault_lookup/workflows/CI/badge.svg)](https://github.com/voxpupuli/puppet-vault_lookup/actions?query=workflow%3ACI)\n[![Release](https://github.com/voxpupuli/puppet-vault_lookup/actions/workflows/release.yml/badge.svg)](https://github.com/voxpupuli/puppet-vault_lookup/actions/workflows/release.yml)\n[![Puppet Forge](https://img.shields.io/puppetforge/v/puppet/vault_lookup.svg)](https://forge.puppetlabs.com/puppet/vault_lookup)\n[![Puppet Forge - downloads](https://img.shields.io/puppetforge/dt/puppet/vault_lookup.svg)](https://forge.puppetlabs.com/puppet/vault_lookup)\n[![Puppet Forge - endorsement](https://img.shields.io/puppetforge/e/puppet/vault_lookup.svg)](https://forge.puppetlabs.com/puppet/vault_lookup)\n[![Puppet Forge - scores](https://img.shields.io/puppetforge/f/puppet/vault_lookup.svg)](https://forge.puppetlabs.com/puppet/vault_lookup)\n[![puppetmodule.info docs](https://www.puppetmodule.info/images/badge.svg)](https://www.puppetmodule.info/m/puppet-vault_lookup)\n[![Apache-2 License](https://img.shields.io/github/license/voxpupuli/puppet-vault_lookup.svg)](LICENSE)\n\nModule to integrate Puppet agents with Hashicorp Vault.\n\n#### Table of Contents\n\n1. [Description](#description)\n2. [Requirements](#setup)\n3. [Usage, Configuration, and Examples](#usage)\n4. [Authentication Methods](#authentication-methods)\n\n## Description\n\nFor Puppet 6+ or Puppet Enterprise 2019+ users wanting to use secrets from\n[Hashicorp Vault](https://www.vaultproject.io/) on their Puppet agents, this\nPuppet module provides the `vault_lookup::lookup()` function.\n\nWhen used with Puppet 6's [`Deferred`\ntype](https://puppet.com/docs/puppet/7/deferring_functions.html), the function\nallows agents to retrieve secrets from Vault when a catalog is applied rather\nthan compiled. In this way, the secret data is not embedded in the catalog and\nthe Puppetserver does not need permissions to read all your Vault secrets.\n\n\n## Requirements\n\nThis modules assumes the following:\n1. Puppet (for supported versions, check metadata.json)\n2. An existing [Vault](https://www.vaultproject.io/) infrastructure\n\nThe `vault_lookup::lookup()` function is expected to be run with the `Deferred`\ntype; as such, Puppet 6 or later is required.\n\nAnd as this function is meant to read secrets from Vault, an existing Vault\ninfrastructure is assumed to be up and reachable by your Puppet agents.\n\n\n## Usage\n\nInstall this module as you would in any other; the necessary code will\nbe distributed to Puppet agents via pluginsync.\n\nIn your manifests, call the `vault_lookup::lookup()` function using the\nDeferred type. For example:\n\n```puppet\n$d = Deferred('vault_lookup::lookup', [\"secret/test\", 'https://vault.hostname:8200'])\n\nnode default {\n  notify { example :\n    message =\u003e $d\n  }\n}\n```\n\nThe lookup function will be run on the agent and the value of `$d` will be\nresolved when the catalog is applied. This will make a call to\n`https://vault.hostname:8200/v1/secret/test` and wrap the result in Puppet's\n`Sensitive` type, which prevents the value from being logged.\n\nYou can also choose not to specify the Vault URL, and then Puppet will use the\n`VAULT_ADDR` environment variable. This will be either set on the command line, or\nset in the service config file for Puppet, on Debian `/etc/default/puppet`, on RedHat\n`/etc/sysconfig/puppet`:\n\n```\n$d = Deferred('vault_lookup::lookup', [\"secret/test\"])\n\nnode default {\n  notify { example :\n    message =\u003e $d\n  }\n}\n```\n\n### Configuring the Vault lookup\n\nThe lookup done by `vault_lookup::lookup()` can be configured in three ways:\npositional arguments, a hash of options,  and/or environment variables.\n\nIn all cases, the path to the secret is the first positional argument and is\nrequired. All other arguments are optional. Arguments in `[square brackets]`\nbelow are optional.\n\n#### Positional Arguments\n\n```\nvault_lookup::lookup( \u003cpath\u003e, [\u003cvault_addr\u003e], [\u003ccert_path_segment\u003e], [\u003ccert_role\u003e], [\u003cnamespace\u003e], [\u003cfield\u003e], [\u003cauth_method\u003e], [\u003crole_id\u003e], [\u003csecret_id\u003e], [\u003capprole_path_segment\u003e], [\u003cagent_sink_file\u003e] )\n```\n\n#### Options Hash\n\n```\nvault_lookup::lookup( \u003cpath\u003e, [\u003coptions_hash\u003e] )\n```\n\n#### Environment Variables\n\nNot all options can be set with environment variables. Use the table below to find the matching env var, if available. Also note that environment variables are only used if the option is not supplied to the function.\n\n  | Option Name | Environment Variable |\n  | ----------- | -------------------- |\n  | `vault_addr`           | `VAULT_ADDR`            |\n  | `cert_path_segment`    | ----                    |\n  | `cert_role`            | ----                    |\n  | `namespace`            | `VAULT_NAMESPACE`       |\n  | `field`                | ----                    |\n  | `auth_method`          | `VAULT_AUTH_METHOD`     |\n  | `role_id`              | `VAULT_ROLE_ID`         |\n  | `secret_id`            | `VAULT_SECRET_ID`       |\n  | `approle_path_segment` | ----                    |\n  | `agent_sink_file`      | `VAULT_AGENT_SINK_FILE` |\n\n#### Environment variables on Puppet server\n\nWhen not using deferred function, the compiler will execute the function and needs either the specific settings or can make use of environment variables. Please note that environment variables must be set in `/etc/puppetlabs/puppetserver/conf.d/puppet-server.conf` within the `jruby-puppet` section.\n\nPlease find a simple example on how to add environment variables to the conf file using hocon:\n\n```shell\n/opt/puppetlabs/puppet/lib/ruby/vendor_gems/bin/hocon \\\n  -f /etc/puppetlabs/puppetserver/conf.d/pe-puppet-server.conf \\\n  set jruby-puppet.environment-vars \"{\\\n    VAULT_ADDR: \\\"https://FQDN\\\",\\\n    VAULT_ROLE_ID: 12345678-1234-1234-1234-1234567890ab,\\\n     VAULT_SECRET_ID: 12345678-1234-1234-1234-1234567890ab\\\n  }\"\n```\n### Usage Examples\n\nHere are some examples of each method:\n```puppet\n# Positional arguments\n\n## Using the default 'cert' auth method.\n$data_1a = vault_lookup::lookup('secret/db/password', 'https://vault.corp.net:8200')\n\n## Using the 'approle' auth method.\n$data_2a = vault_lookup::lookup('secret/db/blah', 'https://vault.corp.net:8200', undef, undef, undef, undef, 'approle', 'team_a', 'abcd1234!@#')\n\n## Pulling out a specific field.\n$password = vault_lookup::lookup('secret/test', 'http://vault.corp.net:8200', undef, undef, undef, 'password')\n```\n\n```puppet\n# Options hash\n\n## Using the default 'cert' auth method.\n$data_1b = vault_lookup::lookup('secret/db/password', { 'vault_addr' =\u003e 'https://vault.corp.net:8200' })\n\n## Using the 'approle' auth method.\n$data_2b = vault_lookup::lookup('secret/db/blah', {\n  'vault_addr'  =\u003e 'https://vault.corp.net:8200',\n  'auth_method' =\u003e 'approle',\n  'role_id'     =\u003e 'team_a',\n  'secret_id'   =\u003e 'abcd1234!@#',\n})\n\n# Using 'field' to pull out a specific field from the data.\n$password = vault_lookup::lookup('secret/test', {'vault_addr' =\u003e 'http://127.0.0.1:8200', 'field' =\u003e 'password'})\n\n# Using Deferred is simpler with the options hash.\n$password_deferred = Deferred('vault_lookup::lookup', [\"secret/test\", {\n  vault_addr =\u003e 'http://127.0.0.1:8200',\n  field      =\u003e 'password',\n}])\n```\n\n### A note about caching\n\nThe `vault_lookup::lookup()` function caches the result of a lookup and will\nuse that cached result for the life of the catalog application (when using\n`Deferred`) or catalog compilation (when not using `Deferred`).\n\nLooked up values are cached based on a combination of their:\n* Path in the Vault URI\n* Vault Address\n* Namespace\n* Field\n\nThis means that you can call `vault_lookup::lookup()` multiple times for the\nsame piece of data or refer to the same `Deferred` value multiple times and\nthere will only be a single fetch from Vault. This helps to reduce the amount\nof back-and-forth network traffic to your Vault cluster.\n\nFor example, in the code below, due to caching, the `secret/db/password` value\nis only looked up once even though the function is called twice:\n\n```puppet\n# Wrap the function in Deferred, and save it to a variable.\n#\n# Since the path, vault_addr, and namespace don't change, only one Vault lookup\n# will be made regardless of how many times the $db_password variable is used.\n#\n$db_password = Deferred('vault_lookup::lookup', [\n  'secret/db/password',\n  {'vault_addr' =\u003e 'https://vault.corp.net:8200'},\n])\n\n# Call the deferred function once.\nfile { '/etc/db.conf':\n  ensure  =\u003e file,\n  content =\u003e $db_password,\n}\n\n# Call the deferred function twice.\nnotify { 'show the DB password':\n  message =\u003e $db_password,\n}\n```\n\nBut if the path, the Vault address, or the namespace change, a new lookup to\nVault will happen. For example, in the code below, even though the path is the\nsame in both of these lookups (`secret/db/password`), the namespace is\ndifferent, so a separate lookup will be made rather than the cached value from\nthe first lookup of `secret/db/password` being used.\n\n```puppet\n# Fetch a value from Vault without using a namespace.\n$db_password = Deferred('vault_lookup::lookup', [\n  'secret/db/password',\n  {'vault_addr' =\u003e 'https://vault.corp.net:8200'},\n])\n\n# Fetch a value from Vault in the 'dev' namespace.\n$db_password_namespaced = Deferred('vault_lookup::lookup', [\n  'secret/db/password',\n  {'vault_addr' =\u003e 'https://vault.corp.net:8200', 'namespace' =\u003e 'dev'},\n])\n\nfile { '/etc/db.conf':\n  ensure  =\u003e file,\n  content =\u003e $db_password,\n}\n\nnotify { 'show the dev namespace DB password':\n  message =\u003e $db_password_namespaced,\n}\n```\n\n### A note about spec testing Puppet code that uses this function\n\nWhen spec testing Puppet code that uses the `vault_lookup::lookup()` function,\nyou'll probably want to stub the function so that it doesn't hit your real\nVault servers. Below is an example of how to do that. This is particularly\nuseful when spec testing a class or define that defers the function call.\n\nTwo things that will need to be configured are 1) a `require_relative` of the\ninternal puppet_x module. Note that this assumes you're pulling the module down\ninto a `spec/fixtures/` directory.\n```ruby\nrequire_relative '../fixtures/modules/vault_lookup/lib/puppet_x/vault_lookup/lookup'\n```\n\nand 2) a stub on the `PuppetX::VaultLookup::Lookup` class's `:lookup` method:\n```ruby\nbefore(:each) do\n  allow(PuppetX::VaultLookup::Lookup).to receive(:lookup)\n    .and_return(Puppet::Pops::Types::PSensitiveType::Sensitive.new('hello world'))\nend\n```\n\nHere's a complete example:\n```ruby\nrequire 'spec_helper'\nrequire_relative '../fixtures/modules/vault_lookup/lib/puppet_x/vault_lookup/lookup'\n\ndescribe 'some::class' do\n  on_supported_os.each do |os, os_facts|\n    context \"on #{os}\" do\n      let(:facts) { os_facts }\n\n      before(:each) do\n        allow(PuppetX::VaultLookup::Lookup).to receive(:lookup)\n          .and_return(sensitive('hello world'))\n      end\n\n      context 'with all defaults' do\n        it { is_expected.to compile }\n        it { is_expected.to contain_file('/etc/credentials.txt').with_content(sensitive('hello world')) }\n      end\n    end\n  end\nend\n```\n\n## Authentication Methods\n\nThe `vault_lookup::lookup()` function can authenticate to Vault in a number of ways. This table shows the currently supported `auth_method` types:\n\n| `auth_method` | Description |\n| --- | --- |\n|  `cert`       | (this is the default) Uses the Puppet agent's certificate via the [TLS Certificates](https://developer.hashicorp.com/vault/docs/auth/cert) auth method. |\n|  `approle`    | Uses the [AppRole](https://developer.hashicorp.com/vault/docs/auth/approle) auth method. |\n|  `agent`      | Uses a local Vault Agent's [auto-auth token](https://developer.hashicorp.com/vault/docs/agent/caching#using-auto-auth-token) and caching proxy. |\n|  `agent_sink` | Uses a local Vault Agent's [auto-auth file sink](https://developer.hashicorp.com/vault/docs/agent/autoauth/sinks/file). |\n\n\n### Puppetserver CA and agent certificates\n\nThe `vault_lookup::lookup()` function by default will use the Puppet agent's\ncertificates to authenticate to the Vault server. This means that before any\nagents contact a Vault server, you must configure the Vault server with the\nPuppet Server's CA certificate, and Vault must be part of the same certificate\ninfrastructure.\n\n1. Set up Vault using Puppet certs (if not already set up this way). If the\n   Vault host has a Puppet agent on it then you can just its existing host\n   certificates. Otherwise generate a new certificate with `puppetserver ca`\n   and copy the files.\n\n   ```\n   $ puppetserver ca generate --certname my-vault.my-domain.me\n   ```\n\n   In the Vault listener configuration, set `tls_client_ca_file` as the Puppet\n   CA cert, `tls_cert_file` as the agent's or generated certificate, and\n   `tls_key_file` as the agent's or generated private key.\n\n2. Enable the `cert` auth backend in Vault.\n\n   ```\n   $ vault auth enable cert\n   ```\n\n3. Upload the Puppet Server CA certificate to Vault. After `cert` auth has been\n   enabled for Vault, upload the CA certificate from your Puppet Server to\n   Vault, and add it as a trusted certificate.\n\n   ```\n   $ vault write auth/cert/certs/puppetserver \\\n       display_name=puppet \\\n       policies=prod,test \\\n       certificate=@/path/to/puppetserver/ca.pem \\\n       ttl=3600\n   ```\n\n\nOnce the certificate has been uploaded, any Puppet agent with a signed\ncertificate will be able to authenticate with Vault.\n\n### AppRole\n\n`vault:vault_lookup()` can also use AppRole authentication to authenticate\nagainst Vault with a valid `role_id` and `secret_id`. See [The Approle Vault\nDocumentation](https://www.vaultproject.io/docs/auth/approle) for detailed\nexplanations of creating and obtaining the security credentials. You will need\nthe Role ID (non sensitive) and the Secret ID (sensitive!). The Secret ID can\nbe provided as an argument to the `vault:vault_lookup()` function but it is\nrecommended to pass this as an environment variable and not bake this into\ncode.\n\nExample:\n```\n$ vault read auth/approle/role/puppet/role-id\nKey        Value\n---        -----\nrole_id    XXXXX-XXXX-XXX-XX-XXXXXXXXXX\n```\n\n```\n# vault write -f auth/approle/role/puppet/secret-id\nKey                   Value\n---                   -----\nsecret_id             YYYYY-YYYY-YYY-YY-YYYYYYYYYYY\nsecret_id_accessor    ZZZZZ-ZZZZZZ-ZZZZZZ-ZZZZZZZZ-ZZZZ\nsecret_id_ttl         0s\n```\n\nIn order to use the AppRole auth method, either set the `VAULT_AUTH_METHOD`\nenvironment variable on the Puppet process to `approle` or set the\n`auth_method` option to `approle` when calling the function:\n\n```shell\nexport VAULT_AUTH_METHOD=approle\nexport VAULT_ROLE_ID=XXXXX-XXXX-XXX-XX-XXXXXXXXXX\nexport VAULT_SECRET_ID=YYYYY-YYYY-YYY-YY-YYYYYYYYYYY\n```\n\n### Vault Agent: auto-auth token\n\nThis method of authentication relies on a local Vault Agent running on the\nPuppet agent host. The Vault Agent handles authenticating to your Vault server,\nand the `vault_lookup::lookup()` function just needs to make requests through\nthe local Vault Agent's caching proxy. The Vault Agent in this scenario must be\nusing Auto Auth, have Caching enabled, and have `use_auto_auth_token` set to\n`true`.\n\n\u003chttps://developer.hashicorp.com/vault/docs/agent/caching#using-auto-auth-token\u003e\n\nAn example Vault Agent config for this scenario is shown below:\n```hcl\nvault {\n  address = \"https://vault.corp.net:8200\"\n}\n\nlistener \"tcp\" {\n  address = \"127.0.0.1:8100\"\n  tls_disable = true\n}\n\nauto_auth {\n  # Some type of auto_auth configuration from:\n  # https://developer.hashicorp.com/vault/docs/agent/autoauth\n}\n\ncache {\n  use_auto_auth_token = true\n}\n```\n\nAnd here's how the `vault_lookup::lookup()` function can be used to talk to the\nlocal Vault agent and use its token for authentication:\n```puppet\n# Talk to the local Vault Agent that has \"use_auto_auth_token = true\"\n$data = Deferred('vault_lookup::lookup', [\"secret/test\", {\n  vault_addr  =\u003e 'http://127.0.0.1:8200',\n  auth_method =\u003e 'agent',\n  field       =\u003e 'password',\n}])\n\nfile { '/tmp/secret_data.txt':\n  ensure  =\u003e file,\n  owner   =\u003e 'app',\n  group   =\u003e 'app',\n  mode    =\u003e '0440',\n  content =\u003e $data,\n}\n```\n\nA benefit of this method is that is uses the Vault Agent's cached token rather\nthan generating a new token for each call of the function. This reduces the\nload on your Vault servers as token generation can be an expensive operation.\n\n### Vault Agent: auto-auth file sink\n\nThis method of authentication relies on a local Vault Agent running on the\nPuppet agent host. The Vault Agent handles authenticating to your Vault server,\nand the `vault_lookup::lookup()` function reads the cached token from a sink\nfile managed by the Vault Agent. Optionally, the lookup could also talk through\nyour Vault Agent's caching proxy if enabled.\n\nThe Vault Agent in this scenario must be using Auto Auth and an **unencrypted, non-response-wrapped** File Sink for the token.\n\n\u003chttps://developer.hashicorp.com/vault/docs/agent/autoauth/sinks/file\u003e\n\nAn example Vault Agent config for this scenario is shown below:\n```hcl\nvault {\n  address = \"https://vault.corp.net:8200\"\n}\n\n# The listener is optional here, but could be used for the 'vault_addr' in\n# the vault_lookup::lookup() Puppet function.\nlistener \"tcp\" {\n  address     = \"127.0.0.1:8100\"\n  tls_disable = true\n}\n\nauto_auth {\n  # Some type of auto_auth method from:\n  # https://developer.hashicorp.com/vault/docs/agent/autoauth/methods\n  method { }\n\n  sink {\n    type = \"file\"\n    config = {\n      path = \"/path/to/vault-token\n    }\n  }\n}\n```\n\nAnd here's how the `vault_lookup::lookup()` function can be configured to use\nthe token from the auto-auth file sink for authentication:\n```puppet\n# Use the token from the local Vault Agent's auto-auth file sink.\n$data = Deferred('vault_lookup::lookup', [\"secret/test\", {\n  # This doesn't have to be the local Vault agent's proxy, but using it can\n  # provide additional caching.\n  vault_addr      =\u003e 'http://127.0.0.1:8200',\n  auth_method     =\u003e 'agent_sink',\n  agent_sink_file =\u003e '/path/to/vault-token',\n  field           =\u003e 'password',\n}])\n\nfile { '/tmp/secret_data.txt':\n  ensure  =\u003e file,\n  owner   =\u003e 'app',\n  group   =\u003e 'app',\n  mode    =\u003e '0440',\n  content =\u003e $data,\n}\n```\n\nA benefit of this method is that is uses the Vault Agent's cached token rather\nthan generating a new token for each call of the function. This reduces the\nload on your Vault servers as token generation can be an expensive operation.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvoxpupuli%2Fpuppet-vault_lookup","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvoxpupuli%2Fpuppet-vault_lookup","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvoxpupuli%2Fpuppet-vault_lookup/lists"}