[BUG] kv v2 is not working proper with the github action. given API path does not work.

[snooops]

Vault server version

v1.15.6

vault-action version

v3.0.0

Describe the bug

Action can't find the secrets using the kvv2 engine using the approle authentication.

To Reproduce

1. Create an approle authentication token.
2. Create a secret using the kvv2 engine:

====== Secret Path ======
kv/data/testing/some-app

======= Metadata =======
Key                Value
---                -----
created_time       2024-04-09T06:07:18.089370564Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

$ vault kv get -mount=kv testing/some-app
====== Secret Path ======
kv/data/testing/some-app

======= Metadata =======
Key                Value
---                -----
created_time       2024-04-09T06:07:18.089370564Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

=== Data ===
Key    Value
---    -----
foo    bar

3. Use github action to retrieve the token

      - name: Import Secrets
        uses: hashicorp/vault-action@v3.0.0
        with:
          url: https://my-vault-server.somewhere.com:8200/
          caCertificate: ${{ secrets.TRUSTED_CA}}
          method: approle
          roleId: ${{ secrets.VAULT_ROLE_ID }}
          secretId: ${{ secrets.VAULT_SECRET_ID }}
          namespace: ${{ secrets.VAULT_NAMESPACE }}
          exportToken: true
          secrets: |
            kv/data/testing/some-app * | KV_TEST_

This Github Action returns a Response code 403 (Forbidden)

Expected behavior

The secret with a 200 OK

Log Output

##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Import Secrets
##[debug]Loading inputs
##[debug]Evaluating: secrets.TRUSTED_CA
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'TRUSTED_CA'
##[debug]=> '***
##[debug]'
##[debug]Result: '***
##[debug]'
##[debug]Evaluating: secrets.VAULT_ROLE_ID
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'VAULT_ROLE_ID'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Evaluating: secrets.VAULT_SECRET_ID
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'VAULT_SECRET_ID'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Evaluating: secrets.VAULT_NAMESPACE
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'VAULT_NAMESPACE'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Loading env
Run hashicorp/vault-action@v3.0.0
::group::Get Vault Secrets
Get Vault Secrets
Token Info
::add-mask::***
::endgroup::

Error: Response code 403 (Forbidden)
##[debug]Node Action run completed with exit code 1
##[debug]VAULT_TOKEN='***'
##[debug]Set output errorMessage = Response code 403 (Forbidden)
##[debug]Finishing: Import Secrets

Additional context

I guess this is related to #271

[fairclothjm]

@snooops I am sorry you are having trouble! Could it be that your namespace is incorrect in the Vault Action config? I don't see usage of the Vault Namespace in your CLI example. Is the namespace set in the CLI environment?

[snooops]

@fairclothjm yes the namespace is set. I have double checked it.

[snooops]

Is there any advanced debug for the action to see the API calls or to see whats going on?

[fairclothjm]

https://docs.github.com/en/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging

To enable step debug logging, set the following secret or variable in the repository that contains the workflow: ACTIONS_STEP_DEBUG to true

[snooops]

Ok i got it now. Damn it. Honestly i don't understand why vault is so hyped, for me many calls and procedures are not straight forward. Anyways, my issue was in the policy.

This is what i had and was not working:

path "kv/data/testing/some-app/*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}

This worked:

path "kv/*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}

So it seems something is not well documented or the path is a different one, either way is bad. Hope it helps. The action, the namespace and the approle was correct.

[ps-jay]

I'm not sure your only issue is with policy, you might also have an issue with politeness

[snooops]

I didn't wanted to offend anyone, i was just frustrated regarding the issue i had + english is not my native language.

[fairclothjm]

@snooops No offense taken from me. I am glad you got it figured out!

Hopefully I can help clarify the issue here. From your original example of the CLI kv get the path is returned as

====== Secret Path ======
kv/data/testing/some-app
...

So kv/data/testing/some-app is the path to the secret. But your policy was setup for kv/data/testing/some-app/* which allows access to everything under kv/data/testing/some-app but not kv/data/testing/some-app itself.

So you could use the following less permissive policy instead of the solution that you found:

path "kv/data/testing/some-app" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}

You can read more about policies here but the relevant detail is under the Policy Syntax section:

Policies use path-based matching to test the set of capabilities against a request. A policy path may specify an exact path to match, or it could specify a glob pattern which instructs Vault to use a prefix match

[fairclothjm]

Just to add a little more clarification. The /* in your policy path kv/data/testing/some-app/* could be changed to the following which would also work:

path "kv/data/testing/some-app*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}

Since everything in vault is "path-based", including policies, your trailing /* was indicating that only paths under kv/data/testing/some-app/ were permitted. Hope that helps!

[snooops]

Ah ok, things are getting more clear now. Thank you very much!