Support Cubbyhole to pass tokens

[mp911de]

Spring Cloud Vault Config allows configuration of a static token spring.cloud.vault.token. Storing the token allows lookup attacks: The static key can be retrieved from the configuration by unauthorized users and can be used to access Vault.

Implementing a cubbyhole authentication for a short-lived (temporary) and long-lived (permanent) token can take advantage from token expiry. A short-lived token that allows a limited number of usages can be used by the application to obtain secrets from cubbyhole. The cubbyhole holds a long-lived token (or other credentials) which is used then to access Vault secrets.

Users could configure the short-lived token in spring.cloud.vault.token to obtain secrets from cubbyhole.

This approach prevents lookup attacks once the short-term token expires and reveals configuration issues/accesses to Vault is the short-lived token was used to access Vault because an application is no longer able to start up using the temporary token.

[jacmorel]

+1 That would be awesome!

[sirlatrom]

I'd like to point to the new response wrapping feature which might simplify solving this issue: https://www.vaultproject.io/docs/concepts/response-wrapping.html

[mp911de]

Response wrapping is using cubbyhole to store responses at v1/cubbyhole/response and generates a token with a TTL. Currently, I think the approach could look like:

1. Operator generates two tokens. A short and a long lived one
2. The long lived is stored in a path below cubbyhole/…
3. The short lived token and the path are configured in the app (spring.cloud.vault.cubbyhole.path)
4. App is started and then you're good to go

Does this make sense?

I will also open a ticket to support wrapped cubbyhole responses but that's different from cubbyhole usage for authentication.

[sirlatrom]

Yes, that makes perfect sense. I'm not sure if it's relevant, but perhaps this method could be useful in determining whether the token has expired or already used:

A solution that works for me:
when creating a response-wrapped token you get:
1.token creation time
2. token's time to live
Adding these two and passing the result to the target-application helps you (in case of getting denial of token) determine which of the 2 occurred.

http://stackoverflow.com/a/38778650/801334