Open Stack

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.reller at 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.mendizabal at 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.fainberg at 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.otto at rackspace.com <mailto:adrian.otto at 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.mathews at gmail.com
> >> <mailto:dolph.mathews at gmail.com>> wrote:
> >>
> >>
> >>
> >> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <lbragstad at gmail.com
> >> <mailto:lbragstad at 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.lu at huawei.com
> >> <mailto:hongbin.lu at 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-request at lists.openstack.org?subject:unsubscribe
> >> <http://OpenStack-dev-
> request at 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-request at lists.openstack.org?subject:unsubscribe
> >> <http://OpenStack-dev-
> request at 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-request at lists.openstack.org
> >> <mailto:OpenStack-dev-
> request at 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-request at lists.openstack.org?subject:unsubscribe
> >> <http://OpenStack-dev-
> request at 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-request at 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-request at 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-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev