Open Stack

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-sto
> 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@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@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: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@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