Hi Kevin,
I understand that this is how it is now. My question is how bad would it
be to wrap the Barbican client library calls in another class and claim,
for all practical purposes, that Magnum has no direct dependency on
Barbican? What is the negative of doing that?
Anyone who wants to use another mechanism should be able to do that with
a simple change to the Magnum conf file. Nothing more complicated.
That's the essence of my question.
Appreciate your thoughts and insight.
Reza
On 4/13/2016 6:46 AM, Fox, Kevin M wrote:
Barbican is the abstraction layer. Its plugable like nova, neutron,
cinder, etc.
Thanks,
Kevin *
*
------------------------------------------------------------------------
*From:* rezroo
*Sent:* Tuesday, April 12, 2016 11:00:30 PM
*To:* openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [magnum][keystone][all] Using Keystone
/v3/credentials to store TLS certificates
Interesting conversation, and I think I have more of a question than a
comment. With my understanding of OpenStack architecture, I don't
understand the point about making "Magnum dependent on Barbican".
Wouldn't this issue be completely resolved using a driver model, such
as delegating the task to a separate class specified in magnum.conf,
with a reference implementation using Barbian API (like the vif driver
of nova, or nova chance vs. filter scheduler)? If people want choice,
we know how to give them choice - decouple, and have a base
implementation. The rest is up to them. That's the framework's
architecture. What am I missing?
Thanks,
Reza
On 4/12/2016 9:16 PM, Fox, Kevin M wrote:
Ops are asking for you to make it easy for them to make their
security weak. And as a user of other folks clouds, i'd have no way
to know the cloud is in that mode. That seems really bad for app
developers/users.
Barbican, like some of the other servises, wont become common if
folks keep trying to reimplement it so they dont have to depend on
it. Folks said the same things about Keystone. Ultimately it was
worth making it a dependency.
Keystone doesnt support encryption, so you are asking for new
functionality duplicating Barbican either way.
And we do understand the point of what you are trying to do. We just
dont see eye to eye on it being a good thing to do. If you are
invested enough in setting up an ha setup where you would need a
clusterd solution, barbicans not that much of an extra lift compared
to the other services you've already had to deploy. Ive deployed both
ha setups and barbican before. Ha is way worse.
Thanks,
Kevin
*
*
------------------------------------------------------------------------
*From:* Adrian Otto
*Sent:* Tuesday, April 12, 2016 8:06:03 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [magnum][keystone][all] Using Keystone
/v3/credentials to store TLS certificates
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.
--
Adrian
On Apr 12, 2016, at 3:44 PM, Dolph Mathews <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> 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-store>https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store
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: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
__________________________________________________________________________
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
