CODEWITHSUNDEEP
hashicorp-vaultvault
Ludwig Van Beethoven
Ludwig Van Beethoven

Reputation: 1934

HashiCorp Vault: What are the security benefits of wrapping the secret_id in appRole authentication?

Our usecase is a jenkins runner that is scheduled to run 1/year, and make a specific vault write command (pki sign of CSR). It needs a "long-running" secret with a ttl=0 to do this, and cannot use a token but must use a secret_ID with approle or userpass auth method.

The idea is it have a secretid+role id availible (like username+pass) on the runner for this operation:

enter image description here

But!

The best practices recommends wrapping the secret_id and having an initial token. What makes this more secure and what specific attacks makes the extra config worth it. Wouldnt a permanent token/secret with ttl=0 still be neede to be kept somewhere?

enter image description here

Resources: https://www.hashicorp.com/blog/how-and-why-to-use-approle-correctly-in-hashicorp-vault https://www.hashicorp.com/resources/vault-response-wrapping-makes-the-secret-zero-challenge-a-piece-of-cake

Upvotes: 0

Views: 246

Answers (1)

Matthew Schuchard
Matthew Schuchard

Reputation: 28854

What you are describing is the difference between push and pull AppRole authentication, and the documentation explains some of the high-level differences between the two. That document also links to the response wrapping documentation which explains the advantages further. What you and the documentation refers to as "wrapping" is the pull method for AppRole.

The important difference between the two in terms of security (which is your primary question here) is that in push mode the Jenkins Vault plugin configuration would contain both the role and secret id for authentication. In pull mode Jenkins would only have knowledge of the role id, and would receive a dynamically generated secret id for token unwrapping from an intermediary between itself and Vault. Note that it would also be possible for Jenkins to act as both the consumer and intermediary in this process, but that would greatly diminish the security benefit as it merely requires a superficial extra step for intrusion.

A simple scenario for one of the situations where pull is preferable to push would be in a situation where an attacker obtains access to Jenkins, and therefore obtains access to both the role id and the static secret id. The attacker would then easily be capable of impersonating a Jenkins agent with an associated Vault policy, generate unwrapped tokens, and begin retrieving authorized secrets with impunity. If instead the AppRole is configured with pull, then the attacker only obtains access to the role id, and would be rejected by the intermediate entity when attempting to request a dynamic secret id and unwrap a temporary token for authentication. This would then be the difference between a successful and unsuccessful breach during an attack.

Upvotes: 0

Related Questions