Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Vault Response Wrapping Makes Secret Zero Challenge A Piece Of Cake

misug
February 20, 2020

Vault Response Wrapping Makes Secret Zero Challenge A Piece Of Cake

misug

February 20, 2020
Tweet

Other Decks in Technology

Transcript

  1. 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
  2. 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.”
  3. Whoami Sr DevOps Engineer at Yoox-Net-A-Porter Group trying to integrate

    Vault as much as possible in my organization linkedin.com/in/giuseppe-misurelli-5378202
  4. 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
  5. 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
  6. 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" }
  7. 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" }
  8. Jenkins writes a wrapped Secret ID CODE EDITOR vault write

    \ -wrap-ttl=200s -f auth/pipeline/role/pipeline-approle/secret-id
  9. 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
  10. 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.