403 (Forbidden) Issue when trying to pull secrets from my key value (kv) vault

[rxa313]

Using vault cli I'm able to pull my secrets using:

vault kv get xxx/kv/some/secret/path

If I try to get the same secret and provide the same path using the action in my workflow:

     - name: import secrets
        uses: hashicorp/[email protected]
        with:
          url: https://vault.xxx.com:xxx
          token: ${{ secrets.VAULT_TOKEN }}
          #caCertificate: ${{ secrets.VAULTCA }} <- not required
          secrets:  xxx/kv/some/secret/path somesecret

I then get the 403 Forbidden error in my output.

I thought that this action supported kv get or am I doing something wrong? In my local CLI I get the same 403 Permission Denied error when trying to do vault read xxx/kv/some/secret/path , but if I execute vault kv get ... I can see the keys just fine.

[soakes]

I was experencing this same issue. Doing some research, I found the following issue #144. He doesn't directly mention how he fixed it but he left a big clue about "This was actually caused by the different way of secret scope reference".

Looking again at the docs on vault-actions, you do see in the examples about using data mount. So I thought hum, lets try it and surprise, surprise, it resolves the issue.

For completeness, don't use the following if your using KV2

      - name: "Import secrets"
        uses: hashicorp/[email protected]
        id: secrets
        with:
          url: ${{ secrets.VAULT_ADDR }}
          method: approle
          roleId: ${{ secrets.VAULT_APPROLE_ROLE_ID }}
          secretId: ${{ secrets.VAULT_APPROLE_SECRET_ID }}
          exportToken: true
          secrets: |
            assets/acme email | _EMAIL ;
            github/vault-cert-updater/cloudflare token | _CF_AUTH_TOKEN ;
            github/vault-cert-updater/scw/s3 access_key | _ACCESS_KEY_ID ;
            github/vault-cert-updater/scw/s3 secret_key | _SECRET_ACCESS_KEY ;
            github/vault-cert-updater/scw/s3 bucket | _BUCKET ;
            github/vault-cert-updater/scw/s3 endpoint | _ENDPOINT

The above produces the following error:

The correct way to do this is by using:

      - name: "Import secrets"
        uses: hashicorp/[email protected]
        id: secrets
        with:
          url: ${{ secrets.VAULT_ADDR }}
          method: approle
          roleId: ${{ secrets.VAULT_APPROLE_ROLE_ID }}
          secretId: ${{ secrets.VAULT_APPROLE_SECRET_ID }}
          exportToken: true
          secrets: |
            assets/data/acme email | _EMAIL ;
            github/data/vault-cert-updater/cloudflare token | _CF_AUTH_TOKEN ;
            github/data/vault-cert-updater/scw/s3 access_key | _ACCESS_KEY_ID ;
            github/data/vault-cert-updater/scw/s3 secret_key | _SECRET_ACCESS_KEY ;
            github/data/vault-cert-updater/scw/s3 bucket | _BUCKET ;
            github/data/vault-cert-updater/scw/s3 endpoint | _ENDPOINT

Thie produces the following:

Hope this helps anyone suffering from same issue.

It maybe wise that the docs get updated to make it extreamly clear that it must have this extra path to extract the secrets even though from CLI and using this path, does not work.

It would be good if vault-action plugin worked the way CLI does, so no need to add in the data mount which is pointless, its only needed for the policy and not the retretival of secrets.

Works via CLI

$ vault kv get assets/acme
====== Metadata ======
Key              Value
---              -----
created_time     2021-10-25T23:20:40.732757378Z
deletion_time    n/a
destroyed        false
version          1

==== Data ====
Key      Value
---      -----
email    [email protected]

Doesn't work via CLI however this matches what you need to use in code for vault-action plugin

$ vault kv get assets/data/acme
Error reading assets/data/data/acme: Error making API request.

URL: GET https://vault.example.io:8200/v1/assets/data/data/acme
Code: 403. Errors:

* 1 error occurred:
	* permission denied

[rxa313]

@soakes

Thanks so much for this. Your suggestion fixed my workflow as well and everything's looking good now.

I second that this be added to some documentation.

Thanks again!

[soakes]

@soakes

Thanks so much for this. Your suggestion fixed my workflow as well and everything's looking good now.

I second that this be added to some documentation.

Thanks again!

Anytime @rxa313, spent a few hours but got there.

[daniel-marthaler]

Hi @soakes / @rxa313, you saved me hour's, if not days with your explanation. i even din't know about that "data" secret path thing that vault has :-)