I have a question about when we configure the approle auth method of the vault, After the configuration of the approle, we need the role-id and secret-id to obtain the token and to do the further vault operations.

1. vault write auth/approle/role/test-role token_ttl=15m token_max_ttl=30m

2. vault read auth/approle/role/test-role/role-id

3. vault write -f auth/approle/role/test-role/secret-id

4. vault write auth/approle/login role_id=<role-id> secret_id=<secret-id>

Why there is not a read operation on secret-id ??

can't we just do this: vault read auth/approle/role/test-role/secret-id

Any Reason behind doing this?, and why there is a write operation on secret-id??

CodePudding user response：

secret_id is somehow similar to a token: it is dynamic, TTLed and can (and should) be recreated with write multiple times. role_id, on the other hand, is a more static entity, something like a username.

CodePudding user response：

You cannot vault read auth/approle/role/test-role/secret-id because the secret-id does not exist until you create it. This is why you are vault write -f auth/approle/role/test-role/secret-id: because you are creating the secret-id with some TTL, and therefore it is a Write operation. After you create a secret-id, you would then create another one if you needed it. You would not vault read the previous secret-id.

Note also that is why the procedure above is the Push method for AppAuth. In the Pull method, the secret-id is created by a third party, and the resultant token is transmitted to the authenticated entity. In that model, only the role-id is ever known, because the secret-id is generated by the third party.

Essentially you cannot vault read because there is nothing to read (no secret-id is being stored in Vault at that point), and you must vault write to create the secret-id.