4 ms·

We worked with a handful of companies to help us design the "App ID" authentication backend that does exactly that: https://vaultproject.io/docs/auth/app-id.htm

We worked with a handful of companies to help us design the "App ID" authentication backend that does exactly that: https://vaultproject.io/docs/auth/app-id.html https://vaultproject.io/docs/auth/app-id.html It allows you to have a non-sensitive single factor within things like configuration management, and have the second factor come from a machine-local location (instance ID, MAC address, TSM module, etc.). The idea is that another team out of band sets the 2nd factor that developers and config management never get to see. The result is you have full automation without secret zero issues. As an additional security parameter, you can bind the two factors together to a single CIDR block, so you can have an additional factor restricting access from that machine's IP. The URL itself above goes into a lot more detail, but our beta users are successfully automated in an elastic environment this way.

jvehent 11y ago
That's definitely a trade-off compared to strong authentication, one that I wouldn't want to make in critical environments. But indeed a very nice feature for 99% of low/medium risk applications.
nutate 11y ago
hard problem, but you clearly address it. There is a typo though: "in client" should probably read "if a client" or "if the client"
acveilleux 11y ago
So if I read that correctly, the UserID (I find that naming confusing since users here aren't necessarily humans) creation has a human in the loop to add the UserID to Vault and therefore make the authorization decision?
kgilpin 11y ago
Using an instance id or MAC address as a secret 2nd factor seems surprising to me. This is what banks are asking for? It's nice that there are two factors to the authentication, but neither one seems to be securely random.
- mitchellh 11y ago
  No, it is usually one of those values salted with a value that is only available offline.

jvehent 11y ago

That's definitely a trade-off compared to strong authentication, one that I wouldn't want to make in critical environments. But indeed a very nice feature for 99% of low/medium risk applications.

nutate 11y ago

hard problem, but you clearly address it. There is a typo though: "in client" should probably read "if a client" or "if the client"

acveilleux 11y ago

So if I read that correctly, the UserID (I find that naming confusing since users here aren't necessarily humans) creation has a human in the loop to add the UserID to Vault and therefore make the authorization decision?

kgilpin 11y ago

Using an instance id or MAC address as a secret 2nd factor seems surprising to me. This is what banks are asking for? It's nice that there are two factors to the authentication, but neither one seems to be securely random.

mitchellh 11y ago
No, it is usually one of those values salted with a value that is only available offline.