Save 37% off PRO during our Black Friday Sale! »

Vault Response Wrapping Makes Secret Zero Challenge A Piece Of Cake

70fb0bea76581819c485bb800df7be60?s=47 misug
February 20, 2020

Vault Response Wrapping Makes Secret Zero Challenge A Piece Of Cake



February 20, 2020


  1. Copyright © 2019 HashiCorp Vault Response Wrapping Makes Secret Zero

    Challenge a Piece of Cake
  2. How can we consume Vault secrets from our Jenkins pipelines?

  3. Scenario Integrating Jenkins with Vault when 1. Pipelines run both

    on prem and on cloud 2. You cannot always use Vault Auth Methods like AWS or Kubernetes
  4. Rely on Vault AppRole auth method "The AppRole auth method

    allows machines or apps to authenticate with Vault-defined roles by providing a sort of username/password credentials data to login into Vault, retrieve a token and use it to interact with Vault.”
  5. How can we securely deliver our AppRole Secret ID from

    Vault to our pipelines?
  6. Secret Zero Challenge!

  7. Whoami Sr DevOps Engineer at Yoox-Net-A-Porter Group trying to integrate

    Vault as much as possible in my organization
  8. Leverage Vault response wrapping Deliver a wrapped Secret ID token

    One time action Vault response wrapping ensures that only the interested pipeline unwraps the token and see the Secret ID. Hardening Secret ID The value being transmitted across the wire is not the actual Secret ID but a reference to it. Limit secret exposure The lifetime of the wrapping token is different (and usually much shorter) than the Secret ID one
  9. The new workflow Vault AppRole auth method with response wrapping

    1. Vault provides to Jenkins a token with permissions to only write a wrapped Secret ID 2. Jenkins writes a wrapped Secret ID exposing it to the pipeline 3. The pipeline unwraps the Secret ID and uses it with the Role ID to login into Vault
  10. Vault admin steps Policy for Jenkins CODE EDITOR path "auth/pipeline/role/pipeline-approle/secret-id"

    { capabilities = ["create", “read”, “update”] min_wrapping_ttl = "100s" max_wrapping_ttl = "300s" }
  11. Vault admin steps Role and policy for pipeline CODE EDITOR

    vault write auth/pipeline/role/pipeline-approle \ secret_id_num_uses=1 \ secret_id_ttl=300s \ token_ttl=1800s path "kv/pipeline-secrets" { capabilities = "read" }
  12. Jenkins writes a wrapped Secret ID CODE EDITOR vault write

    \ -wrap-ttl=200s -f auth/pipeline/role/pipeline-approle/secret-id
  13. Pipeline unwraps the Secret ID CODE EDITOR vault unwrap $WRAPPED_SECRET_ID

    Key Value --- ----- secret_id a744e3344-d44312-882f-f5f4-4ae598e65f48 secret_id_accessor 42r0685c-y24e-8522-9bc6-3d6f43bc9d36
  14. Key points to consider Moving further a more secure implementation...

    Alerts on misuse Since a wrapped token can only be unwrapped once, an alert can rise each time the proper application cannot unwrap the token meaning that something else unwrapped its token. Secret IDs delivery A Jenkins node can run different pipelines for different applications accessing different secrets. It is crucial that Jenkins wraps the proper secret path to pass to the pipeline. Trusted entity Your Jenkins should be considered as a trusted entity for Vault. Trusted entity that must be secured and treated as a critical system.
  15. DEMO 15

  16. Thank You! 16