21

I have a server application (on dynamic infrastructure) which needs to retrieve a secret from Hashicorp Vault during startup.

Lets assume we need make this as secure as possible. From the docs and examples about AppRole authentication i understand that, after a Vault admin has created the approle and the secret, the application needs to be configured with

  • The app role name
  • A token which allows to retrieve the app role id and create a new secret identifier under that role
  • The hostname/port and of the Vault server + SSL certificates

Then the application fetch the role id and create a new secret id (pull mode). With these both id's the application can now perform a login on the Vault server to retrieve the final token which is used to retrieve the secret. During this flow we could also wrap and unwrap every response (cubbyhole response wrapping) by setting X-Vault-Wrap-TTL and use sys/wrapping/unwrap endpoint to unwrap.

First question: Does pull mode and/or response wrapping does really make sense here? I can not see the value of creating a secret id just to use it later for login. I can also not see why i want to wrap my responses just to unwrap them.

If the above is correct then it looks to me that every person/machine which knows the role name and does have a token to fetch the role id and create a secret is able to retrieve the secret.

Second question: Having the app role name and the initial token in my configuration file does not make them really more secure because everyone which has access to the Vault server just can read the secret with that. It seems that it would make sense to split configuration: Have the app role name in the config file and the token somewhere else (in an env variable, etc).

Third question: The deprecated (push based) App ID seems to make more sense to me (for my case) because i can put the app id in the configfile and the use a machine specific user id (like the mac address, ip address, hostname, etc) as the second secret. So why does pull mode AppRole authentication is preferred over push mode or App ID?

Mitchell Stevenson
  • 211
  • 2
  • 3

1 Answers1

1

If you don't have another authenticated service already running (like a scheduler), I don't think there's much difference in security between push and pull mode. If I understand the workflow correctly, an attacker would need the token in the config file and the AppRole name and meet the restrictions set against the role (ip address, etc.) to gain access to all the secrets that the application would have access to (presuming the SSL certs are just to verify the vault server and not for authenticating to it).

  1. Response wrapping is nice for ensuring the secret id is taken by the correct app and not picked up by an attacker. If a scheduler starts up an app and response wraps the secret id for it, then the app can send some sort of an alert if it can't read it, because it means something else already read it (and might use it to authenticate). If the app itself is pulling the secret id directly, I don't think wrapping it would make sense.

  2. Splitting up where the components required for authenticating are located is probably a good idea.

  3. I don't think push or pull mode are fundamentally more secure than the other with the authentication workflow you're describing.

Vivek Chavda
  • 111
  • 4