Open Stack

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