Notes from Today's Registry Abstraction and Vault discussion

Goodell, Leonard <leonard.goodell@...>

  Below are my notes from today’s discussion. Please add anything I may have missed. I added another option (highlighted below) that I thought of after our discussion.
Trevor, please add me to next Core WG meeting agenda to review this and talk about having a combined Core/Security WG meeting early January to try to close on this.
  • Vault
  • 3rd party app also from HashiCorp
  • Tightly coupled to Consul
  • Uses Consul features
  • Fail over
  • Clustering
  • We can’t insert an abstraction layer between 3rd party apps (Vault) and Consul.
  • What about abstracting use of Vault for getting values that are stored as secrets so micro services don’t have to be aware/care where the values come from.
  • How do we know which values are in Vault vs which values are in the Registry?
  • One approach is to have the value in the Registry indicate that it is actually a secret in Vault. Then go to Vault for the value.
  • Add a “secrets” path to the configuration like how we are looking at separating out “writeable”
  • Use of Vault vs Registry is determined by the configuration path.
  • If Vault is not enable, defaults to getting “secrets” in plain text from Registry’s …/secrets path
  • FYI, thought of this as I was typing up these notes… 😉
  • What about storing all values in Vault, if enabled?
  • Abstraction must know if Vault is enable.
  • No watcher capability in Vault
  • There might be a way to implement watcher capability via plug-in for Vault’s secrets engine
  • Could keep “writable” section in Registry so still have watcher capability. Assume these never need to be true secrets
  • Use of Vault vs Registry is determined by the configuration path.
  • Recap of Options:
  • Mixed data between Vault & Registry. Some unique value indicates stored as secret in Vault
  • Separate out secrets into “secrets” section/path so they come from Vault when it is enabled.
  • All values store as secrets Vault. No watch capability, implement plug-in for secret engine?
  • All non-writeable stored as secrets in Vault. Writable stored in Registry so they can be watched.
  • Other opens to discuss further
  • How are secrets “put” into Vault?
  • Pre-populated in some other manner?
  • Part of Seed service?
  • Add this capability to Abstraction?
  • Are we expecting a Registry UI to be exposed in production that allows config value changes?
  • Security concerns??
  • What is the approach for implementing this Registry Abstraction and Vault for Edinburgh?
  • Abstraction first so it can be used in the one service targeted for Vault
  • Abstraction must then have support for Vault
  • Separate efforts, Crawl Phase?
  • Abstraction doesn’t initially have support for Vault
  • Vault usage in target micro service is implemented directly against Vault for values that are known to be secrets.
  • Walk phase could a support for Vault to the Abstraction, but not required for Edinburgh.

Join to automatically receive all group messages.