Add Hashicorp Vault RAW / Absolute Secret path support

Add Hashicorp Vault RAW / Absolute Secret path support

0 vote

avatar

When using the Hashicorp Vault Credential entry, the given Secret path will be updated transparently to include the /data/ path for the api.
Ideally a tickbox should be added to try that secret request as given (raw/ absolute path).
This would be useful for the identity engine to generate JWT tokens

i.e.
Pre-req: Configure Vault to issue JWT tokens as per https://developer.hashicorp.com/consul/tutorials/security-operations/docker-compose-auto-config#configure-vault-to-generate-jwts

Using a secret path of identity/oidc/token/oidc-role-1 in the Vault Credential entry ends up coming through in the audit logs as:
"request": {
    "id": "...",
    "client_id": "...",
    "operation": "read",
    "mount_type": "identity",
    "client_token": "hmac-sha256:...",
    "client_token_accessor": "hmac-sha256:...",
    "namespace": {
        "id": "root"
    },
    "path": "identity/data/oidc/token",
    "remote_address": "192.168.........",
    "remote_port": ....
}

which doesn't exist.
when queried via the vault cli we can see a working query uses the raw path.

"request": {
    "id": "...",
    "client_id": "...",
    "operation": "read",
    "mount_type": "identity",
    "mount_accessor": "identity_...", # I am unsure if this section is needed when queried via the API's but if so, i assume this would take more work than just adding a tickbox to treat the secret path as an absolute path.
    "client_token": "hmac-sha256:....",
    "client_token_accessor": "hmac-sha256:....",
    "namespace": {
        "id": "root"
    },
    "path": "identity/oidc/token/oidc-role-1",
    "remote_address": "127.0.0.1",
    "remote_port": .....
}

All Comments (2)

avatar

Hello,

Could you please give us a bit more information regarding the behaviour you're experiencing in RDM? I'm not sure I understand where exactly the issue happens.

Are you able to login and see the secret hierarchy, but it breaks when you're trying to navigate to the path you mention?

Since a big part of our implementation is done via an external library (including the part where you say "data" is added), having more context could help us greatly.

Regards

Jonathan Del Signore

avatar

Effectively the built-in jwt / oidc engine isn't like a normal secrets engine with key-value data.
However the access method is effectively the same for API requests.
So I was originally hoping it would be an easy quick addition for this use-case to just send it using the provided path instead of updating, but as you're using an external library it likely wouldn't be.
So all good, can close this. :)