Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Answers inline.

On 4/14/16 10:05 AM, Hongbin Lu wrote:
> 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?

release:independent is the default release model for new libs.  AFAIK
nobody has previously asked about having a different release model, so
we haven't had the need to consider other models.

> * 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)?

If you want to add a new backend that is included as part of Castellan
we would appreciate contributions from your team to help fix bugs,
etc. especially since you would be the main user of a new backend.
That said the barbican-core team is commited to maintaining Castellan
and we are responsible for reviews and releases.  Since Castellan is
released independently the release turnaround is much faster than
waiting for patch reviews from the release management team.

> * I wonder why this library is not managed by Oslo (currently
> managed by barbican-core).

When the Castellan project was concieved we asked the Oslo team to
maintain it.  The oslo team PTL at that time recommended that the
barbican-core team keep ownership of the new repo based on concerns
about domain knowledge. [1]

[1] https://review.openstack.org/#/c/138875/

> 
> 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.
> 

There is no technical requirement that mandates that implementations
of Castellan be included as part of the Castellan library.  You could
develop an implementation of the Castellan interface in your own
source tree or its own separate repo or wherever you'd like as long as
your implementation conforms to the Castellan interface.  The only
drawback is that your implementation would not be usable outside of
your project.

Just to be clear, the reason I would like for you to use Castellan is
so that deployers can easily use the Barbican implementation when our
service is available in the deployer's cloud.  It would also be
helpful for small-cloud deployments where Castellan could interface
directly with a Hardware Security Module, etc.

I don't particularly care for the Shared DEK+DB model I described
earlier.  My argument was that using that model would be no less
secure than pre-encrypting things to be stored in Keystone, but it
does not provide the security assurances that Barbican provides.  I
doesn't provide the level of auditability that Barbican provides
either.  And implementing a Castellan backend that does all those
things securely definitely sounds like you'd be re-writing Barbican.

At the end of the day, it will be up to the deployer to consider their
threat models and decide how much risk they're willing to accept.  So
if implementing a low-security key management backend is what your
early adopters want, then please do so in a manner that lets deployers
with high security requirements easily use Barbican or other Hardware
solutions.

- - Douglas Mendizábal

> [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:
> 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
>>>>> 
>>> 
>>> 
>> _____________________________________________________________________
_
>>>
>> 
____ 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
>
>> 
________________________________________________________________________
__
> 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-----

iQIcBAEBCgAGBQJXD8ItAAoJEB7Z2EQgmLX7zMsP/3++J/VV26G5NqVUV+/fQVkr
ooEh9BRopFSa7IyFYxXO1HQUFWcnYzw/BZuK/Jymn8XGKaMwgHnX8saU5IsYxBoV
MHqGuRBtTHcA79p1nsaeUHxJgReffOu3cyDDCy5fiV7zjlIvNA36MpEF3rPcXW7K
pi1hfhxdfQnuipJDGbBx/1QrAjiNW4i+y4BR5N8aERc7sWodfjtplrKE/AB4wqce
nFjMsFXTKqN4Y7uuIkSyjsTlkNsWiHZZAplGlv/MShavJRQB1kWHpCz3rLwkVvFF
x2BDOHvCYLANlkzBVTUbCq282Axuqkrw2G2hdcQoxB8CvU0WtPkP4KFFMATKGSRE
Fle8LLhCzDCp4H2rTmna2LuzsN6ooORS4rDET9aLkS+iT7Cw6mn6eziuU5hNxZoX
/s4oX4W2cNT1LJaWebjfvKRfBYXG+24WiMfEodr08UeElLlt6SbC8q6nrebznQXo
WpSuhFmmjewx9+H1tUJbkeY4iTWQFgb5b8dWcTfhhikZjnsNXVug1lskpo1oivtq
5WODZxEgZVYXtQgDovxl6+aAniizBdOop3O26hzSORoGVEy5Z+TR0D0MlEVqHO1P
9RMZTinMQXWYuYgr9rQX686ot6HP5bkj/+CV0VQ82qv/4faxG/YJUdWcjA5rH1B/
aFOAkzWI1JRXEYWcer9e
=wWWp
-----END PGP SIGNATURE-----