Castellan is another alternative under consideration [1]. Would I ask some clarifying questions: * I saw Castellan is using release:independent model. What are the rationales of choosing this release model over release:cycle-with-intermediary? * If Magnum depends on this library and contributes a Castellan backend, who will maintain the backend? Who can review and approve bug fixes? Who will release a new package? How fast the whole process will be (patch critical fixes -> review -> approve -> release)? * I wonder why this library is not managed by Oslo (currently managed by barbican-core).
In general, I saw the advantages of leveraging Castellan. My major concern is the development speed: contributing on external repo might slow down the development process. Personally, I lean to start everything in our own repo, and push them to a common library later. [1] https://etherpad.openstack.org/p/magnum-barbican-alternative Best regards, Hongbin > -----Original Message----- > From: Nathan Reller [mailto:nathan.s.rel...@gmail.com] > Sent: April-14-16 9:22 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum][keystone][all] Using Keystone > /v3/credentials to store TLS certificates > > I agree with Doug's comments. Castellan is a generic key manager > library that allows symmetric keys, private keys, public keys, > certificates, passphrases, and opaque secret data to be stored in a key > manager. There is a Barbican implementation that is complete, and a > KMIP (Key Management Interoperability Protocol (an OASIS standard)) > implementation is under development. > > The precursor to castellan was the KeyManager interface integrated into > Nova and Cinder. We are in the process of making the easy switch from > that to Castellan. Glance and Sahara have both already integrated with > Castellan. Swift is currently integrating with Castellan and will swap > between Barbican and KMIP. > > -Nate > > > > On Wed, Apr 13, 2016 at 3:04 PM, Douglas Mendizábal > <douglas.mendiza...@rackspace.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > Hi Hongbin, > > > > I have to admit that it's a bit disappointing that the Magnum team > > chose to decouple from Barbican, although I do understand that our > > team needs to do a better job of documenting detailed how-tos for > > deploying Barbican. > > > > I'm not sure that I understand the Threat Model you're trying to > > protect against, and I have not spent a whole lot of time researching > > Magnum architecture so please forgive me if my assumptions are wrong. > > > > So that we're all on the same page, I'm going to summarize the TLS > > use-case as I understand it: > > > > The magnum-conductor is a single process that may be scalable at some > > point in the future. [1] > > > > When the magnum-conductor is asked to provision a new bay the > > following things happen: > > 1. A new self-signed root CA is created. This results in a Root CA > > Certificate and its associated key 2. N number of nodes are created > to > > be part of the new bay. For each node, a new x509 certificate is > > provisioned and signed by the Root CA created in 1. This results in > a > > certificate and key pair for each node. > > 3. The conductor then needs to store all generated keys in a secure > > location. > > 4. The conductor would also like to store all generated Certificates > > in a secure location, although this is not strictly necessary since > > Certificates contain no secret information as pointed out by Adam > > Young elsewhere in this thread. > > > > Currently the conductor is using python-barbicanclient to store the > > Root CA and Key in Barbican and associates those secrets via a > > Certificate Container and then stores the container URI in the > > conductor database. > > > > Since most users of Magnum are unwilling or unable to deploy Barbican > > the Magnum team would like an alternative mechanism for storing all > > keys as well as the Certificates. > > > > Additionally, since magnum-conductor may be more than one process in > > the future, the alternative storage must be available to many > > magnum-conductors. > > > > Now, in the proposed Keystone alternative the magnum-conductor will > > have a (symmetric?) encryption key. Let's call this key the DEK > > (short for data-encryption-key). How the DEK is stored and > replicated > > to other magnum-conductors is outside of the scope of the proposed > > alternative solution. > > The magnum-conductor will use the DEK to encrypt all Certificates and > > Keys and then store the resulting ciphertexts using the Keystone > > credentials endpoint. > > > > This begs the question: If you're pre-encrypting all this data with > > the DEK, why do you need to store it in an external system? I see no > > security benefit of using Keystone credentials over just storing > these > > ciphertexts in a table in the database that all magnum-conductors > will > > already have access to. > > > > I think a better alternative would be to integrate with Castellan and > > develop a new Castellan implementation where the DEK is specified in > a > > config file, and the ciphertexts are stored in a database. Let's > call > > this new implementation LocalDEKAndDBKeyManager. > > > > With this approach the deployer could specify the > > LocalDEKAndDBKeyManager class as the implementation of Castellan to > be > > used for their deployment, and then the DEK and db connection string > > could be specified in the config as well. > > > > By introducing the Castellan abstraction you would lose the ability > to > > group secrets into containers, so you'd have to store separate > > references for each cert and key instead of just one barbican > > reference for both. Also, you would probably have to write the > > Castellan integration in a way that always uses a context that is > > generated from the config file which will result in all keys being > > owned by the Magnum service tenant instead of the user's tenant when > > using Barbican as a backend. > > > > The upshot is that a deployer could choose the existing Barbican > > implementation instead, and other projects may be able to make use of > > the LocalDEKAndDBKeyManager. > > > > - - Douglas Mendizábal > > > > [1] http://docs.openstack.org/developer/magnum/#architecture > > > > On 4/13/16 10:14 AM, Hongbin Lu wrote: > >> I think there are two questions here: > >> > >> 1. Should Magnum decouple from Barbican? > >> > >> 2. Which options Magnum should use to achieve #1 (leverage > >> Keystone credential store, or other alternatives [1])? > >> > >> For question #1, Magnum team has thoughtfully discussed it. I think > >> we all agreed that Magnum should decouple from Barbican for now (I > >> didn’t hear any disagreement from any of our team members). What we > >> are currently debating is question #2. That is which approach we > >> should use to achieve the goal. The first option is to store TLS > >> credentials in Keystone. The second option is to store the > >> credentials in Magnum DB. The third option is to eliminate the need > >> to store TLS credentials (e.g. switch to another non-TLS > >> authentication mechanism). What we want to know is if Keystone team > >> allows us to pursue the first option. If it is disallowed, I will > >> suggest Magnum team to pursue other options. > >> > >> So, for the original question, does Keystone team allow us to store > >> encrypted data in Keystone? A point of view is that if the data to > be > >> stored is already encrypted, there will be no disagreement from > >> Keystone side (so far, all the concerns is about the security > >> implications of storing un-encrypted data). Would I confirm if > >> Keystone team agrees (or doesn’t disagree) with this point of view? > >> > >> > >> > >> [1] https://etherpad.openstack.org/p/magnum-barbican-alternative > >> > >> > >> > >> Best regards, > >> > >> Hongbin > >> > >> > >> > >> *From:*Morgan Fainberg [mailto:morgan.fainb...@gmail.com] *Sent:* > >> April-13-16 12:08 AM *To:* OpenStack Development Mailing List (not > >> for usage questions) *Subject:* Re: [openstack-dev] > >> [magnum][keystone][all] Using Keystone /v3/credentials to store TLS > >> certificates > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto > >> <adrian.o...@rackspace.com <mailto:adrian.o...@rackspace.com>> > >> wrote: > >> > >> Please don't miss the point here. We are seeking a solution that > >> allows a location to place a client side encrypted blob of data (A > >> TLS cert) that multiple magnum-conductor processes on different > hosts > >> can reach over the network. > >> > >> > >> > >> We *already* support using Barbican for this purpose, as well as > >> storage in flat files (not as secure as Barbican, and only works > with > >> a single conductor) and are seeking a second alternative for clouds > >> that have not yet adopted Barbican, and want to use multiple > >> conductors. Once Barbican is common in OpenStack clouds, both > >> alternatives are redundant and can be deprecated. If Keystone > depends > >> on Barbican, then we have no reason to keep using it. That will mean > >> that Barbican is core to OpenStack. > >> > >> > >> > >> Our alternative to using Keystone is storing the encrypted blobs in > >> the Magnum database which would cause us to add an API feature in > >> magnum that is the exact functional equivalent of the credential > >> store in Keystone. That is something we are trying to avoid by > >> leveraging existing OpenStack APIs. > >> > >> > >> > >> Is it really unreasonable to make Magnum depend on Barbican? I know > I > >> discussed this with you previously, but I would like to know how > much > >> pushback you're really seeing on saying "Barbican is important for > >> these security reasons in a scaled-up environment and here is why we > >> made this choice to depend on it". Secure by default is far better > >> than an option that is significantly sub-optimal. > >> > >> > >> > >> So, is Barbican support really hampering Magnum in significant ways? > >> If so, what can we do to improve the story to make Barbican > >> compelling instead of needing this alternative? > >> > >> > >> > >> +1 to Dolph's comment on Barbican being more mature *and* another > >> +1 for the comment that credentials being un-encrypted in keystone > >> makes storing secure credentials in keystone significantly less > >> desirable. > >> > >> > >> > >> These questions are intended to just fill in some blanks I am seeing > >> so we have a complete story and can look at prioritizing > >> work/specs/etc. > >> > >> > >> > >> -- > >> > >> Adrian > >> > >> > >> On Apr 12, 2016, at 3:44 PM, Dolph Mathews <dolph.math...@gmail.com > >> <mailto:dolph.math...@gmail.com>> wrote: > >> > >> > >> > >> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <lbrags...@gmail.com > >> <mailto:lbrags...@gmail.com>> wrote: > >> > >> Keystone's credential API pre-dates barbican. We started talking > >> about having the credential API back to barbican after it was a > >> thing. I'm not sure if any work has been done to move the credential > >> API in this direction. From a security perspective, I think it would > >> make sense for keystone to back to barbican. > >> > >> > >> > >> +1 > >> > >> > >> > >> And regarding the "inappropriate use of keystone," I'd agree... > >> without this spec, keystone is entirely useless as any sort of > >> alternative to Barbican: > >> > >> > >> > >> https://review.openstack.org/#/c/284950/ > >> > >> > >> > >> I suspect Barbican will forever be a much more mature choice for > >> Magnum. > >> > >> > >> > >> > >> > >> On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu <hongbin...@huawei.com > >> <mailto:hongbin...@huawei.com>> wrote: > >> > >> Hi all, > >> > >> > >> > >> In short, some Magnum team members proposed to store TLS > certificates > >> in Keystone credential store. As Magnum PTL, I want to get > agreements > >> (or non-disagreement) from OpenStack community in general, Keystone > >> community in particular, before approving the direction. > >> > >> > >> > >> In details, Magnum leverages TLS to secure the API endpoint of > >> kubernetes/docker swarm. The usage of TLS requires a secure store > for > >> storing TLS certificates. Currently, we leverage Barbican for this > >> purpose, but we constantly received requests to decouple Magnum from > >> Barbican (because users normally don’t have Barbican installed in > >> their clouds). Some Magnum team members proposed to leverage > Keystone > >> credential store as a Barbican alternative [1]. > >> Therefore, I want to confirm what is Keystone team position for this > >> proposal (I remembered someone from Keystone mentioned this is an > >> inappropriate use of Keystone. Would I ask for further > >> clarification?). Thanks in advance. > >> > >> > >> > >> [1] > >> https://blueprints.launchpad.net/magnum/+spec/barbican-alternative- > st > >> o > > re > >> > >> > >> > >> > >> > >> Best regards, > >> > >> Hongbin > >> > >> > >> > >> > _____________________________________________________________________ > >> _ > > ____ > >> > >> > > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > >> > > >> > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> > _____________________________________________________________________ > >> _ > > ____ > >> > >> > > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > >> > > >> > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > _____________________________________________________________________ > >> _ > > ____ > >> > >> > > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: openstack-dev-requ...@lists.openstack.org > >> <mailto:OpenStack-dev- > requ...@lists.openstack.org>?subject:unsubscrib > >> e > >> > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > _____________________________________________________________________ > >> _ > > ____ > >> > >> > > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> <http://OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > >> > > >> > >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> > >> > _____________________________________________________________________ > >> _ > > ____ > >> > >> > > OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > -----BEGIN PGP SIGNATURE----- > > > > iQIcBAEBCgAGBQJXDpg1AAoJEB7Z2EQgmLX7lLAQAICgefenxdc8Yg/+IdJRT2kb > > i7U65RuM+bVv/iRWZsR3E+TataYLX8lI3LCbPZuLQEbFx3ekMojjASulsFZds3zO > > /DlmM3po80tcIaAcI0FpxzhhANnfSG+4Z+XWfj9oGMKHI3BnC8g3z5gcJQlyUEfG > > r4u674fvyg2mxNFsXFM5nQNBbwY9f2fovq4mWx8ci1oTfnNrcuy5haLgKwJq4VlU > > 9RLtsLUqHXpIfE+7PYqLhDpKsEDnpSYz5wg4irRZZ0V+zKxaaeLQIajpTHh6c/Cv > > DZTKk2quZJ67vwg+C1trhi4Bms0okXe3EKHcD65ZwePx2T+JRiloAbllNHyeKCUU > > jt40MzCqQpaLFlykBhmYXq/18tgk1VRFbsSa2ZaWHYIxMDpU1OBlExKxp67Htao3 > > buG8e8KRbpjnFOOKDRsm6n7cU9ixDvR2oxynED6orPcQbcmIEw/1PDK1yXNvdfG/ > > AVcUh1yNC2srU2vN7Zhte+VhR8wm/xuzdp6JP/bGX1lrre6BogIit0GXJTpKXPJN > > 3TYQxuY3UJIqCFszdgb4oUFqyK9sb/mSNohJcifnkZfcgDDiuQVbpRgPC9V65Un1 > > bpexkLzD7iuxF3qY2z2Pi2xKKu7TkTqfpfFF99D4/JJjGbVT+yuEwm9k4q7xZJ3Y > > ZKTKW7nWbzQrLfO5p/yM > > =EpgG > > -----END PGP SIGNATURE----- > > > > > ______________________________________________________________________ > > ____ OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________________________________ > ___ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
