Abstract Registry proposal presentation


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

 

All,

  Attached is the Abstract Registry proposal I presented in last week’s Core WG meeting.  

 

A few of us met on Monday to discuss Vault and how retrieving secrets could be included in this abstraction. Here are my notes from that meeting. We will continue this discuss in this week Core WG meeting.

 

Thanks!

   Lenny Goodell - Intel

 

-----------------------

Notes:

 

  • 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 EdgeX-TSC-Security@lists.edgexfoundry.org to automatically receive all group messages.