You need to do the equivalent of a vault write -f auth/approle/role/my-role/secret-id
to get a new secret id. Where you do this is where it gets interesting...
I assume you already have a Vault policy that allows you to generate a new secret_id. Make sure that the role_name
parameter is fixed to your application current role. Chances are you will want to limit the metadata, too.
I would suggest this pattern:
- Something (a pipeline or scheduled job of some kind) creates the new secret-id. Bonus points if it is wrapped and single use, but let's save that for another question.
- That something will store the secret-id in a secure place. Could be in the Vault KV version 2 store where the application can read.
- After creating the new secret-id, that something lists the secrets and keeps the N most recent secret ids. Say the last 5. This makes the process asynchronous and allows running applications to keep going.
Now in your application, you must have a periodic task that looks up the latest secret id and reauthenticates to Vault with it.
If possible, I would suggest that you avoid the problem altogether and use the authentication method provided the platform your are on, it Vault supports it, like GCP, AWS or Kubernetes.