Search code examples
puppetvault

Vault access from Puppetserver always denied

Context

On my personal WSL I created a new token for our Vault instance with the appropriate policy and was able to retrieve secrets from there.

However, for some reason any attempt to use vault to retrieve secrets from the Puppet server results in a permission denied when using this new token.

Here's an example of the curl command:

 curl --insecure -H "X-Vault-Request: true" -H "X-Vault-Token: my.token" https://vault.server.com:8200/v1/path/to/secret/data/secret

Question

Anyone would have any idea why the token created works fine on any server except on the Puppet server ?

Is it possible that there's some kind of cache on the Vault server that keeps blocking any attempt at retrieving secrets coming from the Puppet server ?

P.S: Retrieving secrets from the Puppet server before changing the token worked fine.

Solution

  • In this particular case, the issue was that I used my own LDAP account to generate a token with the required policy :

    vault login -method=ldap username=myuser
vault token create -policy=mypolicy

    At the same time the LDAP access to Vault was restricted to certain IPs using the ldap_allowed_ips parameter in our Terraform project :

    ldap_allowed_ips = ["xxx.yy.zzz.0/24",
                    "aaa.bb.ccc.0/24",
                    ...]

    So the resulting token actually inherited these IP restrictions as we can see in the bound_cidrs parameter (in curl's output) :

     curl --insecure -H "X-Vault-Request: true" -H "X-Vault-Token: s.qwertasdfgyxcvbzuihjk" https://vault.server.com:8200/v1/auth/token/lookup-self

{"request_id":"989r4r3r-7d44-a570-6a13-6ba724d9aba6","lease_id":"","renewable":false,"lease_duration":0,"data":{"accessor":"osccmdcmwemcpoemocp","bound_cidrs":["xxx.yy.zzz.0/24","aaa.bb.ccc.0/24",...]

    Root Cause

    I couldn't access Vault secrets from the Puppet server because the corresponding IP wasn't listed in the ldap_allowed_ips parameter.

    Conclusion

    The previous token was most probably not created through an LDAP account so it did not suffer the IP restrictions setup for LDAP.

    However, using an LDAP account to create a token in this fashion is not the correct way and we will switch to another method in the future.