Approle - how to get secret-id only using API Calls

Vault
1

Hi everyone!

With admin user I created an approle with the command:
vault write auth/approle/role/app bind_secret_id=true token_policies=policy-app token_ttl=30m token_max_ttl=30m token_num_uses=50 secret_id_num_uses=50 secret_id_ttl=30m

And got the role-id with:
vault read auth/approle/role/app/role-id

Now I want my application be able to get the new secret-id and login…

I can do it with CLI:
vault write -f auth/approle/role/app/secret-id

But with API Call I receive a Permission Denied error, because the API expects a token (as described in the documentation AppRole - Auth Methods - HTTP API | Vault | HashiCorp Developer)… and my application don’t have a token yet to pass in the header X-Vault-Token:

curl --header “X-Vault-Token: …” --request POST https://vault:8200/v1/auth/approle/role/app/secret-id

I apreciate any help to solve this.
Thank You!

2

Using CLI also there is an alternative, wrapping the secret-id… but in the documentation there ins’t any mention how to do this only with API calls.

vault write -wrap-ttl=60s -force auth/approle/role/jenkins/secret-id
(this command returns a token that can be used in the next command)

VAULT_TOKEN=“” vault unwrap
(and now you have the secret-id)

3

I’m sorry, but your post doesn’t really make sense to me:

An AppRole RoleID and SecretID are basically a fancy username and password.

Therefore naturally, an application needs to be provided with both the RoleID (username) and SecretID (password) if it is to use them to prove its identity to Vault, and log in.

All the talk about CLI vs API is just a distraction - the CLI is just one way to make API calls. What matters is who or what is making which API calls, at what point in the process.

Wrapping is an advanced technique that most users should ignore entirely. Wrapping is akin to putting a secret document in an envelope and applying a tamper-evident seal before putting it in the post … i.e. totally and completely pointless unless there are also strict procedures in place for tracking how many copies of the document were sealed and sent, and for carefully scrutinizing the tamper-evident seal on arrival at the other end, to prove it hasn’t been broken and replaced.

In my experience it is common for users of wrapping to do so without those procedures, meaning they are practicing security theater, not actual security.

Let’s leave wrapping aside for now.

I see you have implied a desire to use short-lived SecretIDs:

I think you have two ways forward:

EITHER: Stop doing that, reconfigure SecretIDs to live forever, provision one manually, and give it to your app.

OR: Provide this forum with more detail about the architecture of your environment, so we can talk about how your app might be able to securely obtain a new SecretID on demand when it needs one.