Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Douglas Mendizábal]

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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Hongbin Lu]

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.rel...@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
>  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 encry

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Nathan Reller]

 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.fainb...@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
>> mailto:adrian.o...@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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Douglas Mendizábal]

rsue 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.fainb...@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
> mailto:adrian.o...@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
> mailto:dolph.math...@gmail.com>> wrote:
> 
> 
> 
> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
> 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  <mailto: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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Clint Byrum]

Excerpts from Clayton O'Neill's message of 2016-04-13 07:37:16 -0700:
> On Wed, Apr 13, 2016 at 10:26 AM, rezroo  wrote:
> > 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.
> 
> For us, the main reason we’d want to be able to deploy without
> Barbican is mostly to lower the initial barrier of entry.  We’re not
> running anything else that would require Barbican for a multi-node
> deployment, so for us to do a realistic evaluation of Magnum, we’d
> have to get two “new to us” services up and running in a development
> environment.  Since we’re not running Barbican or Magnum, that’s a big
> time commitment for something we don’t really know if we’d end up
> using.  From that perspective, something that’s less secure might be
> just fine in the short term.  For example, I’d be completely fine with
> storing certificates in the Magnum database as part of an evaluation,
> knowing I had to switch from that before going to production.
> 

I'd say there's a perfectly reasonable option already for evaluation
purposes, and that is the existing file based backend. For multiple
nodes, I wonder how poorly an evaluation will go if one simply rsyncs
that directory every few minutes.

__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Clint Byrum]

Excerpts from Douglas Mendizábal's message of 2016-04-13 10:01:21 -0700:
> Hash: SHA512
> 
> Hi Reza,
> 
> The Barbican team has already abstracted python-barbicanclient into a
> general purpose key-storage library called Castellan [1]
> 
> There are a few OpenStack projects that have planned to integrate or
> are currently integrating with Castellan to avoid a hard dependency on
> Barbican.
> 
> There are some tradeoffs to choosing Castellan over
> python-barbicanclient and Castellan may not be right for everyone.
> Also, the only complete implementation of Castellan is currently the
> Barbican implementation, so even though integrating with Castellan
> does not result in a direct dependency, there is still work to be done
> to have a working non-barbican solution.

From an outsider's perspective with no real stake in this debate,
this sounds like a very reasonable way for Magnum to proceed, which
a pre-dependency that they would move their file based approach into
Castellan.

__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Reza,

The Barbican team has already abstracted python-barbicanclient into a
general purpose key-storage library called Castellan [1]

There are a few OpenStack projects that have planned to integrate or
are currently integrating with Castellan to avoid a hard dependency on
Barbican.

There are some tradeoffs to choosing Castellan over
python-barbicanclient and Castellan may not be right for everyone.
Also, the only complete implementation of Castellan is currently the
Barbican implementation, so even though integrating with Castellan
does not result in a direct dependency, there is still work to be done
to have a working non-barbican solution.

- - Douglas Mendizábal

[1] http://git.openstack.org/cgit/openstack/castellan/

On 4/13/16 9:26 AM, rezroo wrote:
> 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 (no

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Fox, Kevin M]

For evaluation, you should be able to throw it on a single machine with the 
file backend and skip barbican. Why do you need to do a partially hardened 
config? (magnum ha but insecure)

Thanks
Kevin

From: Clayton O'Neill [clay...@oneill.net]
Sent: Wednesday, April 13, 2016 7:37 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 Wed, Apr 13, 2016 at 10:26 AM, rezroo  wrote:
> 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.

For us, the main reason we’d want to be able to deploy without
Barbican is mostly to lower the initial barrier of entry.  We’re not
running anything else that would require Barbican for a multi-node
deployment, so for us to do a realistic evaluation of Magnum, we’d
have to get two “new to us” services up and running in a development
environment.  Since we’re not running Barbican or Magnum, that’s a big
time commitment for something we don’t really know if we’d end up
using.  From that perspective, something that’s less secure might be
just fine in the short term.  For example, I’d be completely fine with
storing certificates in the Magnum database as part of an evaluation,
knowing I had to switch from that before going to production.

__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Adam Young]

On 04/12/2016 03:43 PM, Hongbin Lu 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.



No it does not.

Nothing required "secure storing of certificates."

What is required is "secure storing of private keys."  Period. Nothing 
else needs to be securely stored.


Next step is the "signing" of X509 certificates, and this requires a 
CA.  Barbican is the OpenStack abstraction for a CA, but still requires 
a "real" implementation to back to.  Dogtag is available for this role.



Now, what Keystone can and should do is provide a way to map an X509 
Certificate to a user.  This is actually much better done using the 
Federation approach than the Credentials store.


Credentials kinda suck.  They should die in a fire.  They can't, but 
they should. Different rant though.


So, to nail it down specifically:  Keystone's  sole role here is to map  
the Subject from an X509 certificate to a user_id.  If you try to do 
anything more than that with Keystone, you are in a state of sin.


So, if what you want to do is to store an X509 Certificate in the 
Keystone Credentials API, go for it, but I don;'t know what it would buy 
you, as only the "owner" of that cert would then be able to retrieve it.



If, on the other hand, what you want to do is to decouple the 
request/approval of X509 dfrom Barbican, I would suggest you use 
Certmonger.  It is an Operating system level tool for exactly this 
purpose.  And then we should make sure that Barbican can act as a CA for 
Certmonger (I know that Dogtag can already).



There is nothing Magnum specific about this.  We need to solve the Cert 
story for OpenStack in general.  We need TLS for The Message Broker and 
the Database connections as well as any HTTPS servers we have.





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


Best regards,

Hongbin



__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Ian Cordasco]

 

-Original Message-
From: Lance Bragstad 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: April 13, 2016 at 10:24:18
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 think we need to ask who we are lowering the barrier of entry for. Are we
> going down this path because we want developers to have less things to do
> to stand up a development environment? Or do we want to make it easy for
> people to realistically test? If you're going to realistically vet magnum,
> why not make that PoC as realistic as possible, as in deploying with
> barbican. As an operator, I think it would be better to have an honest
> assessment of the work required to deploy magnum, even if it costs a little
> extra time. I'd rather hit roadblocks with the realistic approach early
> than reassure my team everything will work correctly when we didn't test
> what we planned to offer to our customers. In my experience, having
> roadblocks pop up later after commitment has been made is expensive and
> stressful.

I agree wtih you, but there is a feeling among some that they want to /try/ 
Magnum without Barbican. With Magnum supporting a filesystem storage driver, 
like Glance's filesystem storage driver, I think this can be accomodated for 
proofs of concept (e.g., that Magnum "works" and serves the user's needs). From 
an operational perspective, it will be very misleading, especially to 
management, when the idea of Magnum goes from PoC to supported and requires 
Barbican and some (Soft or not) HSM which needs to be deployed.

Keep in mind, that Magnum's templates to deploy its COEs also have dependencies 
on other services that a small cloud may not deploy (e.g., Neutron) or features 
there of that may not be enabled (e.g., LBaaS). So there may be yet more 
requests to make Magnum adoption easier and thos requests will impact usage of 
the deployed COE more than anything else.

(And yes, let's not forget that this thread started regarding adoption, not 
simplifying PoC deployments which, while certainly related, are not the same 
thing.)

--  
Ian Cordasco


__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Lance Bragstad]

I think we need to ask who we are lowering the barrier of entry for. Are we
going down this path because we want developers to have less things to do
to stand up a development environment? Or do we want to make it easy for
people to realistically test? If you're going to realistically vet magnum,
why not make that PoC as realistic as possible, as in deploying with
barbican. As an operator, I think it would be better to have an honest
assessment of the work required to deploy magnum, even if it costs a little
extra time. I'd rather hit roadblocks with the realistic approach early
than reassure my team everything will work correctly when we didn't test
what we planned to offer to our customers. In my experience, having
roadblocks pop up later after commitment has been made is expensive and
stressful.

On Wed, Apr 13, 2016 at 9:37 AM, Clayton O'Neill  wrote:

> On Wed, Apr 13, 2016 at 10:26 AM, rezroo  wrote:
> > 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.
>
> For us, the main reason we’d want to be able to deploy without
> Barbican is mostly to lower the initial barrier of entry.  We’re not
> running anything else that would require Barbican for a multi-node
> deployment, so for us to do a realistic evaluation of Magnum, we’d
> have to get two “new to us” services up and running in a development
> environment.  Since we’re not running Barbican or Magnum, that’s a big
> time commitment for something we don’t really know if we’d end up
> using.  From that perspective, something that’s less secure might be
> just fine in the short term.  For example, I’d be completely fine with
> storing certificates in the Magnum database as part of an evaluation,
> knowing I had to switch from that before going to production.
>
> __
> 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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Ian Cordasco]

 

-Original Message-
From: Clayton O'Neill 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: April 13, 2016 at 09:39:38
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 Wed, Apr 13, 2016 at 10:26 AM, rezroo wrote:
> > 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.
>  
> For us, the main reason we’d want to be able to deploy without
> Barbican is mostly to lower the initial barrier of entry. We’re not
> running anything else that would require Barbican for a multi-node
> deployment, so for us to do a realistic evaluation of Magnum, we’d
> have to get two “new to us” services up and running in a development
> environment. Since we’re not running Barbican or Magnum, that’s a big
> time commitment for something we don’t really know if we’d end up
> using. From that perspective, something that’s less secure might be
> just fine in the short term. For example, I’d be completely fine with
> storing certificates in the Magnum database as part of an evaluation,
> knowing I had to switch from that before going to production.

In that case, why not instead, use an NFS mount to store the certificates in 
that all magnum conductors have (the same way someone evaluating Glance without 
wanting Swift, Ceph, or something else that would be more robust) might use NFS 
+ the default filesystem store? That doesn't require adding yet more code to 
store something in the database or in Keystone.

Further, the other contention here is that people want to run Magnum on old 
deployments of OpenStack which most likely wouldn't even have Keystone v3 
deployed. So I'm still failing to see how this solution solves anything at all.

--  
Ian Cordasco


__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Hongbin Lu]

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.fainb...@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 
mailto:adrian.o...@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 
mailto:dolph.math...@gmail.com>> wrote:

On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
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 
mailto: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 endp

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Clayton O'Neill]

On Wed, Apr 13, 2016 at 10:26 AM, rezroo  wrote:
> 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.

For us, the main reason we’d want to be able to deploy without
Barbican is mostly to lower the initial barrier of entry.  We’re not
running anything else that would require Barbican for a multi-node
deployment, so for us to do a realistic evaluation of Magnum, we’d
have to get two “new to us” services up and running in a development
environment.  Since we’re not running Barbican or Magnum, that’s a big
time commitment for something we don’t really know if we’d end up
using.  From that perspective, something that’s less secure might be
just fine in the short term.  For example, I’d be completely fine with
storing certificates in the Magnum database as part of an evaluation,
knowing I had to switch from that before going to production.

__
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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[rezroo]

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




On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <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
 wrote:

Hi all,

In short, some Magnum team members proposed to store TLS
certificates i

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Fox, Kevin M]

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 
<<mailto:dolph.math...@gmail.com>dolph.math...@gmail.com<mailto:dolph.math...@gmail.com>>
 wrote:


On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
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 
<<mailto:hongbin...@huawei.com>hongbin...@huawei.com<mailto: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 Ba

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[rezroo]

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 <mailto:dolph.math...@gmail.com>> wrote:




On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad <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
mailto: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 Keysto

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Fox, Kevin M]

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 
mailto:dolph.math...@gmail.com>> wrote:


On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
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 
mailto: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

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


__

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Morgan Fainberg]

On Tue, Apr 12, 2016 at 8:06 PM, Adrian Otto 
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 
> wrote:
>
>
> On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
> 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 
>> 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
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>> __
>>> 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
>
>
> _

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Adrian Otto]

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 
mailto:dolph.math...@gmail.com>> wrote:


On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad 
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 
mailto: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

Best regards,
Hongbin

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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Dolph Mathews]

On Tue, Apr 12, 2016 at 3:27 PM, Lance Bragstad  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  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
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>> __
>> 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

Re: [openstack-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Lance Bragstad]

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.

On Tue, Apr 12, 2016 at 2:43 PM, Hongbin Lu  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
>
>
>
> Best regards,
>
> Hongbin
>
> __
> 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-dev] [magnum][keystone][all] Using Keystone /v3/credentials to store TLS certificates

[Hongbin Lu]

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

Best regards,
Hongbin
__
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