Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Joshua Harlow]

Embrace the larger world instead of trying to recreate parts of it,
create alliances with the CNCF and/or other companies


The CNCF isn't a company...


Yes, fair, good point, thanks for the correction.




that are getting actively involved there and make bets that solutions
there are things that people want to use directly (instead of turning
openstack into some kind of 'integration aka, middleware engine').


The complaint about Barbican that I heard from most folks on this thread
was that it added yet another service to deploy to an OpenStack deployment.

If we use technology from the CNCF or elsewhere, we're still going to
end up deploying yet another service. Just like if we want to use
ZooKeeper for group membership instead of the Nova DB.

So, while I applaud the general idea of looking at the CNCF projects as
solutions to some problems, you wouldn't be solving the actual issue
brought to attention by operators and OpenStack project contributors (to
Magnum/Craton): of needing to install yet another dependency.



How many folks have been watching
https://github.com/cncf/toc/tree/master/proposals or
https://github.com/cncf/toc/pulls?


I don't look at that feed, but I do monitor the pull requests for k8s
and some other projects like rkt and ACI/OCI specs.


Great!

Thanks, we have to avoid becoming siloed off into 
'openstack-world/universe'; I'm pretty sure it's the only way we survive.





Start accepting that what we call OpenStack may be better off as
extracting the *current* good parts of OpenStack and cutting off some of
the parts that aren't really worth it/nobody really uses/deploys anyway


I'm curious what you think would be left in OpenStack?


A good question, and one I've been pondering on for a while.

Honestly I'm not sure I could say what would be 'left', especially as 
there is overlap in functionality, but let's say we are proactive in say 
shifting things (in places where we are actually more advanced or 
provide unique value that the CNCF and its projects lack) then what did 
not shift over is what is left in openstack (as it is defined today). 
But what is wrong with that, if openstack becomes openstack-CNCF, so 
what, it feels somewhat evolutionary and I get the gut feeling it's 
happening whether we want it to or not (though of course I only have a 
small view on the wider world).




BTW, the CNCF is already creating projects that duplicate functionality
that's been available for years in other open source projects -- see
prometheus and fluentd [1] -- in the guise of "unifying" things for a
cloud-native world. I suspect that trend will continue as vendors jump
from OpenStack to CNCF projects because they perceive it as the new
shiny thing and capable of accepting their vendor-specific code quicker
than OpenStack.


Perhaps that's an opportunity, not a drawback? If we play the cards 
right and approach this correctly we can help evolve (our community and 
theres) into something that transfers what we have learned from our 
current community to whatever it becomes next.




In fact, if you look at the CNCF projects, you see the exact same
disagreement about the exact same two areas that we see so much
duplication in the OpenStack community: deployment/installation and
logging/monitoring/metrics. I mean, how many ways are there to deploy
k8s at this point?


Ya, I'm not really happy either with this, but I've seen it before.



The things that the OpenStack ecosystem has proliferated as services or
plugins are the exact same things that the CNCF projects are building
into their architecture. How many service discovery mechanisms can
Prometheus use? How many source and destination backends can fluentd
support? And now with certain vendors trying to get more
hardware-specific functionality added to k8s [2], the k8s community is
going through the exact same inflection point with regards to project
scope that Nova did 4 years ago.

What's old is new and what's new is old again.

 > (and say starting to modernize the parts that are left by say moving
 > them under the CNCF umbrella and adopting some of the technology there
 > instead).

I find it curious that you equate "modernizing" an OpenStack project to
"moving it to the CNCF umbrella". Is the technology you would want to
adopt just simply Golang vs. Python or are you referring to something
else? Perhaps k8s' choice not to use a relational database for any state
storage?

Look, I'm not saying the CNCF projects are bad in any way. I have
*daily* feelings of jealousy when looking at some of the k8s and fluentd
architecture/code and wonder what would Nova look like if we'd started
coding it now from scratch. Almost weekly I wish that Nova would have
the freedom that k8s currently has to change direction mid-stream. But
k8s is also in a different maturity/lifecycle place than Nova is and has
a very different and smaller mission.



I guess I call what you are feeling above as modernizing.


My point is this: I don't want people 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Morgan Fainberg]

On Wed, Jan 18, 2017 at 5:18 PM, Clint Byrum  wrote:

> Excerpts from Morgan Fainberg's message of 2017-01-18 15:33:00 -0800:
> > On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson  wrote:
> >
> > >
> > >
> > > On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) <
> > > dmcco...@cisco.com> wrote:
> > >
> > >>
> > >> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco  >
> > >> wrote:
> > >>
> > >>> Hi everyone,
> > >>>
> > >>> I've seen a few nascent projects wanting to implement their own
> secret
> > >>> storage to either replace Barbican or avoid adding a dependency on
> it.
> > >>> When I've pressed the developers on this point, the only answer I've
> > >>> received is to make the operator's lives simpler.
> > >>>
> > >>>
> > >> This is my opinion, but I'd like to see Keystone use Barbican for
> storing
> > >> credentials. It hasn't happened yet because nobody's had the time or
> > >> inclination (what we have works). If this happened, we could
> deprecate the
> > >> current way of storing credentials and require Barbican in a couple of
> > >> releases. Then Barbican would be a required service. The Barbican team
> > >> might find this to be the easiest route towards convincing other
> projects
> > >> to also use Barbican.
> > >>
> > >> - Brant
> > >>
> > >>
> > >> Can you provides some details on how you'd see this work?
> > >> Since Barbican typically uses Keystone to authenticate users before
> > >> determining which secrets they have access to, this leads to a
> circular
> > >> logic.
> > >>
> > >> Barbican's main purpose is a secret manager.  It supports a variety of
> > >> RBAC and ACL access control methods to determine if a request to
> > >> read/write/delete a secret should be allowed or not.  For secret
> storage,
> > >> Barbican itself needs a secure backend for storage.  There is a
> > >> customizable plugin interface to access secure storage.  The current
> > >> implementations can support a database with encryption, an HSM via
> KMIP,
> > >> and Dogtag.
> > >>
> > >>
> > > I haven't thought about it much so don't have details figured out.
> > > Keystone stores many types of secrets for users, and maybe you're
> thinking
> > > about the user password being tricky. I'm thinking about the users' EC2
> > > credentials (for example). I don't think this would be difficult and
> would
> > > involve creating a credentials backend for keystone that supports
> barbican.
> > > Maybe have a 'keystone' project for credentials keystone is storing? If
> > > you're familiar with the Barbican interface, compare with keystone's
> > > credential interface[0].
> > >
> > > [0] http://git.openstack.org/cgit/openstack/keystone/tree/
> > > keystone/credential/backends/base.py#n26
> > >
> > > - Brant
> > >
> > >
> > The user passwords and the MFA tokens would be particularly difficult as
> > they are to be used for authentication purposes. Anything tied to the
> main
> > AuthN path would require something akin to a "service wide" secret store
> > that could be accessed/controlled by keystone itself and not "on behalf
> of
> > user" where the user still owns the data stored in barbican.
> >
> > I can noodle over this a bit more and see if I can come up with a
> mechanism
> > that (without too much pain) utilizes barbican for the AuthN paths in the
> > current architecture.
> >
> > I think it is doable, but I hesitate to make Keystone's AuthN path rely
> on
> > any external service so we don't run into a circular dependency of
> services
> > causing headaches for users. Keystone has provided a fairly stable base
> for
> > other projects including Barbican to be built on.
> >
> > Now... If the underlying tech behind Barbican could be pushed into
> keystone
> > as the credential driver (and possibly store for passwords?) without
> > needing to lean on Barbican's Server APIs (restful), I think that is
> quite
> > viable and could be of value since we could offload the credentials to a
> > more secure store without needing a "restful service" that uses keystone
> as
> > an AuthN/AuthZ source to determine who has access to what secret.
>
> Things like Barbican are there for the times where it's worth it to
> try and minimize exposure for something _ever_ leaking, so you can't do
> something like record all encrypted traffic and then compromise a key
> later, decrypt the traffic, and gain access to still-secret data.
>
> I'm not sure passwords would fall into that category. You'd be adding
> quite a bit of overhead for something that can be mitigated simply by
> rotating accounts and/or passwords.


I totally agree. Most everything in Keystone falls into this category. We
could use the same tech Barbican uses to be smarter about storing the data,
but I don't think we can use the Rest APIa for the reasons you outlined.

__
> OpenStack Development Mailing List (not for usage questions)
> 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Clint Byrum]

Excerpts from Morgan Fainberg's message of 2017-01-18 15:33:00 -0800:
> On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson  wrote:
> 
> >
> >
> > On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) <
> > dmcco...@cisco.com> wrote:
> >
> >>
> >> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I've seen a few nascent projects wanting to implement their own secret
> >>> storage to either replace Barbican or avoid adding a dependency on it.
> >>> When I've pressed the developers on this point, the only answer I've
> >>> received is to make the operator's lives simpler.
> >>>
> >>>
> >> This is my opinion, but I'd like to see Keystone use Barbican for storing
> >> credentials. It hasn't happened yet because nobody's had the time or
> >> inclination (what we have works). If this happened, we could deprecate the
> >> current way of storing credentials and require Barbican in a couple of
> >> releases. Then Barbican would be a required service. The Barbican team
> >> might find this to be the easiest route towards convincing other projects
> >> to also use Barbican.
> >>
> >> - Brant
> >>
> >>
> >> Can you provides some details on how you'd see this work?
> >> Since Barbican typically uses Keystone to authenticate users before
> >> determining which secrets they have access to, this leads to a circular
> >> logic.
> >>
> >> Barbican's main purpose is a secret manager.  It supports a variety of
> >> RBAC and ACL access control methods to determine if a request to
> >> read/write/delete a secret should be allowed or not.  For secret storage,
> >> Barbican itself needs a secure backend for storage.  There is a
> >> customizable plugin interface to access secure storage.  The current
> >> implementations can support a database with encryption, an HSM via KMIP,
> >> and Dogtag.
> >>
> >>
> > I haven't thought about it much so don't have details figured out.
> > Keystone stores many types of secrets for users, and maybe you're thinking
> > about the user password being tricky. I'm thinking about the users' EC2
> > credentials (for example). I don't think this would be difficult and would
> > involve creating a credentials backend for keystone that supports barbican.
> > Maybe have a 'keystone' project for credentials keystone is storing? If
> > you're familiar with the Barbican interface, compare with keystone's
> > credential interface[0].
> >
> > [0] http://git.openstack.org/cgit/openstack/keystone/tree/
> > keystone/credential/backends/base.py#n26
> >
> > - Brant
> >
> >
> The user passwords and the MFA tokens would be particularly difficult as
> they are to be used for authentication purposes. Anything tied to the main
> AuthN path would require something akin to a "service wide" secret store
> that could be accessed/controlled by keystone itself and not "on behalf of
> user" where the user still owns the data stored in barbican.
> 
> I can noodle over this a bit more and see if I can come up with a mechanism
> that (without too much pain) utilizes barbican for the AuthN paths in the
> current architecture.
> 
> I think it is doable, but I hesitate to make Keystone's AuthN path rely on
> any external service so we don't run into a circular dependency of services
> causing headaches for users. Keystone has provided a fairly stable base for
> other projects including Barbican to be built on.
> 
> Now... If the underlying tech behind Barbican could be pushed into keystone
> as the credential driver (and possibly store for passwords?) without
> needing to lean on Barbican's Server APIs (restful), I think that is quite
> viable and could be of value since we could offload the credentials to a
> more secure store without needing a "restful service" that uses keystone as
> an AuthN/AuthZ source to determine who has access to what secret.

Things like Barbican are there for the times where it's worth it to
try and minimize exposure for something _ever_ leaking, so you can't do
something like record all encrypted traffic and then compromise a key
later, decrypt the traffic, and gain access to still-secret data.

I'm not sure passwords would fall into that category. You'd be adding
quite a bit of overhead for something that can be mitigated simply by
rotating accounts and/or passwords.

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Morgan Fainberg]

On Wed, Jan 18, 2017 at 11:23 AM, Brant Knudson  wrote:

>
>
> On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan) <
> dmcco...@cisco.com> wrote:
>
>>
>> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I've seen a few nascent projects wanting to implement their own secret
>>> storage to either replace Barbican or avoid adding a dependency on it.
>>> When I've pressed the developers on this point, the only answer I've
>>> received is to make the operator's lives simpler.
>>>
>>>
>> This is my opinion, but I'd like to see Keystone use Barbican for storing
>> credentials. It hasn't happened yet because nobody's had the time or
>> inclination (what we have works). If this happened, we could deprecate the
>> current way of storing credentials and require Barbican in a couple of
>> releases. Then Barbican would be a required service. The Barbican team
>> might find this to be the easiest route towards convincing other projects
>> to also use Barbican.
>>
>> - Brant
>>
>>
>> Can you provides some details on how you'd see this work?
>> Since Barbican typically uses Keystone to authenticate users before
>> determining which secrets they have access to, this leads to a circular
>> logic.
>>
>> Barbican's main purpose is a secret manager.  It supports a variety of
>> RBAC and ACL access control methods to determine if a request to
>> read/write/delete a secret should be allowed or not.  For secret storage,
>> Barbican itself needs a secure backend for storage.  There is a
>> customizable plugin interface to access secure storage.  The current
>> implementations can support a database with encryption, an HSM via KMIP,
>> and Dogtag.
>>
>>
> I haven't thought about it much so don't have details figured out.
> Keystone stores many types of secrets for users, and maybe you're thinking
> about the user password being tricky. I'm thinking about the users' EC2
> credentials (for example). I don't think this would be difficult and would
> involve creating a credentials backend for keystone that supports barbican.
> Maybe have a 'keystone' project for credentials keystone is storing? If
> you're familiar with the Barbican interface, compare with keystone's
> credential interface[0].
>
> [0] http://git.openstack.org/cgit/openstack/keystone/tree/
> keystone/credential/backends/base.py#n26
>
> - Brant
>
>
The user passwords and the MFA tokens would be particularly difficult as
they are to be used for authentication purposes. Anything tied to the main
AuthN path would require something akin to a "service wide" secret store
that could be accessed/controlled by keystone itself and not "on behalf of
user" where the user still owns the data stored in barbican.

I can noodle over this a bit more and see if I can come up with a mechanism
that (without too much pain) utilizes barbican for the AuthN paths in the
current architecture.

I think it is doable, but I hesitate to make Keystone's AuthN path rely on
any external service so we don't run into a circular dependency of services
causing headaches for users. Keystone has provided a fairly stable base for
other projects including Barbican to be built on.

Now... If the underlying tech behind Barbican could be pushed into keystone
as the credential driver (and possibly store for passwords?) without
needing to lean on Barbican's Server APIs (restful), I think that is quite
viable and could be of value since we could offload the credentials to a
more secure store without needing a "restful service" that uses keystone as
an AuthN/AuthZ source to determine who has access to what secret.

--Morgan
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

We've also talked about fancier non-keystone-auth like x.509 certificate
s.

- - Douglas

On 1/18/17 11:52 AM, Clint Byrum wrote:
> Excerpts from Dave McCowan (dmccowan)'s message of 2017-01-18
> 15:58:19 +:
>> 
>> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco
>> > wrote: Hi
>> everyone,
>> 
>> I've seen a few nascent projects wanting to implement their own
>> secret storage to either replace Barbican or avoid adding a
>> dependency on it. When I've pressed the developers on this point,
>> the only answer I've received is to make the operator's lives
>> simpler.
>> 
>> 
>> This is my opinion, but I'd like to see Keystone use Barbican for
>> storing credentials. It hasn't happened yet because nobody's had
>> the time or inclination (what we have works). If this happened,
>> we could deprecate the current way of storing credentials and
>> require Barbican in a couple of releases. Then Barbican would be
>> a required service. The Barbican team might find this to be the
>> easiest route towards convincing other projects to also use
>> Barbican.
>> 
>> - Brant
>> 
>> Can you provides some details on how you'd see this work? Since
>> Barbican typically uses Keystone to authenticate users before
>> determining which secrets they have access to, this leads to a
>> circular logic.
>> 
>> Barbican's main purpose is a secret manager.  It supports a
>> variety of RBAC and ACL access control methods to determine if a
>> request to read/write/delete a secret should be allowed or not.
>> For secret storage, Barbican itself needs a secure backend for
>> storage.  There is a customizable plugin interface to access
>> secure storage.  The current implementations can support a
>> database with encryption, an HSM via KMIP, and Dogtag.
> 
> Just bootstrap the genesis admin credentials into Barbican and
> Keystone the same way we bootstrap them into Keystone now. Once
> there's admin creds, they can be validated separate from updating
> them, and there's no circle anymore, Just two one-way
> dependencies.
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYf+7/AAoJEB7Z2EQgmLX7YFQQAJ9J1j/PflaPU18o0Aej1j0p
LLuFRUehR29LKFQJdmmd2GPq+Inuvie9mjRo/Aa89TfF0BpNOJqqma4A7mduHxZQ
QLz5lO0Cg5tuDOKdaml21OJVoxV+8EkslYTn9OOwv0ktL/JxhgSp9wSeJpkkgDKP
lqzCu2WZvHjb1BlDs8DYwW3cOyzJ9vTL4m3UDHz/Z7E2KrW60t8OieJEcYwZH1Iv
r9K4dLE5Qyc552ZB442aR/ypPZS+Wy4/YJwdY6NnS+oI+kkNgW2TVadBkHkRIudy
wTGZSSHIv2NTFugwUOCZF2If+0RkOniTbxev8/xNZZdUJI7N/xeYnc2YozvPHEzD
AG9ghKcFi6drFk+A1cYxy20NaGFxBqM97bXWad5IAhh7c/3Eg0FAf5gl3hYG/nBV
bmEX2LEQiU23yP5ug9Z45KH06rkP7R7i+EG8UpByP88zMREJyPhaaxQFEd5625K7
4Baz7geSHosaK+bTVFdD1FDT8OWxBPbkfJ9hglk2kUoKlhpBLeNPdDNwj4EGz7H3
3tyRlhdaTkETIVIBFOcn6LrZGdgTeveeFVm1XLVPd6+4Ie5akOqrV7we8jFP7bm8
a1X/mzEcdZx74RgLm1+4TAU6N1wgdhdyZoKQCwDrPjPVssI07aNT6BFkSCkAeNdo
pbUudKVnJYS9jhO3BsjR
=8P6e
-END PGP SIGNATURE-

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think that a Vault backend would only be valuable to folks who are
already using Vault.

For deployers who don't yet have a key management solution, a Vault
backend would not solve the problem of having to deploy yet another
service.  In fact it would make it worse since the deployer would have
to deploy both Vault AND Barbican to get a working solution.  It seems
to me that it would create the same concerns that folks are having
about deploying DogTag and Barbican to get a software-only solution.

I do like Vault, and I think that some of the things they've done with
the software-only configuration are pretty cool.  I spent some time
looking into what it would take to wire up Barbican to use Vault as a
backend, and the tricky part is being able to map Keystone auth to one
of Vault's many auth drivers.

For my use case, the effort of sorting out the auth mapping between
the two systems in addition to the overhead of running both Vault and
Barbican seemed like a bigger task than improving the Simple Crypto
driver to remove the encryption key from the conf file.

- - Douglas

On 1/17/17 7:49 AM, Dave McCowan (dmccowan) wrote:
> 
> 
> On 1/16/17, 3:06 PM, "Ian Cordasco" <sigmaviru...@gmail.com>
> wrote:
> 
>> -Original Message- From: Dave McCowan (dmccowan)
>> <dmcco...@cisco.com> Reply: OpenStack Development Mailing List
>> (not for usage questions) <openstack-dev@lists.openstack.org> 
>> Date: January 16, 2017 at 13:03:41 To: OpenStack Development
>> Mailing List (not for usage questions) 
>> <openstack-dev@lists.openstack.org> Subject:  Re: [openstack-dev]
>> [all] [barbican] [security] Why are projects trying to avoid
>> Barbican, still?
>>> Yep. Barbican supports four backend secret stores. [1]
>>> 
>>> The first (Simple Crypto) is easy to deploy, but not
>>> extraordinarily secure, since the secrets are encrypted using a
>>> static key defined in the barbican.conf file.
>>> 
>>> The second and third (PKCS#11 and KMIP) are secure, but require
>>> an HSM as a hardware base to encrypt and/or store the secrets. 
>>> The fourth (Dogtag) is secure, but requires a deployment of
>>> Dogtag to encrypt and store the secrets.
>>> 
>>> We do not currently have a secret store that is both highly
>>> secure and easy to deploy/manage.
>>> 
>>> We, the Barbican community, are very open to any ideas,
>>> blueprints, or patches on how to achieve this. In any of the
>>> homegrown per-project secret stores, has a solution been 
>>> developed that solves both of these?
>>> 
>>> 
>>> [1]
>>> 
>>> http://docs.openstack.org/project-install-guide/key-manager/draft/ba
rbica
>>>
>>> 
n-
>>> backend.html
>> 
>> So there seems to be a consensus that Vault is a good easy and
>> secure solution to deploy. Can Barbican use that as a backend
>> secret store?
> 
> Adding a new secret store plugin for Vault would be a welcome
> addition. We have documentation in our repo on how to write a new
> plugin. [1]   I can schedule some time at the PTG to plan for this
> in Pike if there are interested developers.
> 
> [1] 
> https://github.com/openstack/barbican/blob/master/doc/source/plugin/se
cret_
>
> 
store.rst
> 
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYf9jPAAoJEB7Z2EQgmLX7UQkQAKNFKOfAazPmzQGETKWuy2uP
9G86dGNrRO4PaFKO7asUgqmdtFiMfouTT8yayogT3vLokhOoQW4bBxLKunGQ4Un3
mVg5pYD8zwBtYTKd09WVLEYfiSdUSurKfA6gq/b3l0NC7fEp0zkx58Rzt1/ITW7H
o+90ajghnfl2X6yfE+dudGody5aKoicDqxgzwh6YbIDwz6ZaGfwE9tUGJdQ4OJ1O
YfG1I61JPvNz+r1RJeyREo0SEuNi0RMgWHqigu/H9QfOGNxJrfKGM1KC5TbAnMkA
82BmxNUw/hYQZsSk/beDqelH4JqZmywlMna9YAjLC9VrgvnmC7srHbQBLMsyavBH
Zfv04kG30ucsauxQOni0YfbqhalSb+6wXJipwTdaetwTe2wiVltz1a9pscc/57r9
omBCoNUh+dS1uy8axRSE92oDw2ASfBEH7B5+NBLZ0Y8ZlfN8JU6BqY8cJdpzSSer
CvmyLDiUE1MEYj2L05lPJXZnbiWSJK1FZNNXf6kuJBXfqsNz7QRkrwkVIS1a+Uke
n4U8Fl9c3VlGiLanfnNGHgBOOG9lwL0/g1gc5JtCZYPaNRj/+TSLQBHfgm3SgtSG
6rmJCU7t4PLqdIylDN7uTSPgFX4BCU4yXY9IcfLiz0OLZmbFzsLLG/zYN2dc4iM5
uCpGu9rsziz1ujaTwneC
=gIXT
-END PGP SIGNATURE-

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Brant Knudson]

On Wed, Jan 18, 2017 at 9:58 AM, Dave McCowan (dmccowan)  wrote:

>
> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
> wrote:
>
>> Hi everyone,
>>
>> I've seen a few nascent projects wanting to implement their own secret
>> storage to either replace Barbican or avoid adding a dependency on it.
>> When I've pressed the developers on this point, the only answer I've
>> received is to make the operator's lives simpler.
>>
>>
> This is my opinion, but I'd like to see Keystone use Barbican for storing
> credentials. It hasn't happened yet because nobody's had the time or
> inclination (what we have works). If this happened, we could deprecate the
> current way of storing credentials and require Barbican in a couple of
> releases. Then Barbican would be a required service. The Barbican team
> might find this to be the easiest route towards convincing other projects
> to also use Barbican.
>
> - Brant
>
>
> Can you provides some details on how you'd see this work?
> Since Barbican typically uses Keystone to authenticate users before
> determining which secrets they have access to, this leads to a circular
> logic.
>
> Barbican's main purpose is a secret manager.  It supports a variety of
> RBAC and ACL access control methods to determine if a request to
> read/write/delete a secret should be allowed or not.  For secret storage,
> Barbican itself needs a secure backend for storage.  There is a
> customizable plugin interface to access secure storage.  The current
> implementations can support a database with encryption, an HSM via KMIP,
> and Dogtag.
>
>
I haven't thought about it much so don't have details figured out. Keystone
stores many types of secrets for users, and maybe you're thinking about the
user password being tricky. I'm thinking about the users' EC2 credentials
(for example). I don't think this would be difficult and would involve
creating a credentials backend for keystone that supports barbican. Maybe
have a 'keystone' project for credentials keystone is storing? If you're
familiar with the Barbican interface, compare with keystone's credential
interface[0].

[0]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/credential/backends/base.py#n26

- Brant
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm very much interested in an out-of-the-box software-only backend
driver for Barbican.

I think that one of the reasons people have been hesitant to deploy
Barbican is that we claim that our Simple Crypto software-only driver
is "not secure in any way", when really we should be saying that it
provides minimal security which may or may not be acceptable to your
business.

I believe we could provide a level of security comparable to
software-only Vault with considerably less effort than it would take
to create a driver that can utilize Vault.

We could, for example, add a new API call to provide the encryption
key at runtime instead of requiring it to be present in the conf file.

- - Douglas

On 1/16/17 12:43 PM, Rob C wrote:
> 
> The last I checked, Rob, they also support DogTag IPA which is
> purely a Software based HSM. Hopefully the Barbican team can
> confirm this. -- Ian Cordasco
> 
> 
> Yup, that's my understanding too. However, that requires Barbican
> _and_ Dogtag, an even bigger overhead. Especially as at least
> historically Dogtag has been difficult to maintain. If you have a
> deployment already, there's a great synergy there. If you don't
> then it introduces a lot of overhead.
> 
> I'm interested to know if an out of the box, stand alone
> software-only version of Barbican would be any more appealing
> 
> Cheers -Rob
> 
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYf7TrAAoJEB7Z2EQgmLX7En8P/3Nw+AcPTt5m7oQagy7I7r84
Bmk2AzsHN/GvkeqlRTTu3ilHWswspfwf1AcPACAC6aOnOZ3Y9JX9oF8W9sJlYDBl
edniOBOrLZnRAQrZgLmoU7ifIRf1HkaUiy0nkRQ8t21CbyRzDIzPZ9qC92DVZXxr
Ho/9tJXWUmFXPLUvcOAa0H4jOISvtDCono6HM47JtdARzvWoxDrYY47tFqoY0x4G
ocDkYxqu+IUCoM4HzdiqszJT0PwSgp8yaXtWaZadS2k8yEiQwpnTZEDhHNvGKc+X
Ty2dpR5LzQ1WVcEE4FKW47fNBNsQf7IFwSYXt7k8CUpjK8e+rJ//9ndpozdZGrSn
w/HPO84vVC0a2cN582MzVC9zAuUjsJ4fbh9CxWvT83X84lbor9RTk6XnV3IvzNDd
ytVouSfchVrPwBFt4qgo9W30zUUjcUq2NFhOMDwW9ns2E2cd8PuT9GCRvkzLh1xE
RF/OePXjE0DU3pmjL6lRN0S2/69ndAhKvERKB7kcKxNBvfXQg6CCB3hqf7TBUg0w
Do2WSrUx65PHuYdOquwGCAlMscsX0lnkh1yF19KaohxPp+Pjg2dL905lJx/gt6no
emDbTiJFYhcYJKpmAkVToz6GnUcwL6jLHciP8KmXjjcMnG6dCYjErOfIg1ixGmeT
+mKOupRI6l2G9VlM9Cj1
=sGDy
-END PGP SIGNATURE-

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Clint Byrum]

Excerpts from Dave McCowan (dmccowan)'s message of 2017-01-18 15:58:19 +:
> 
> On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
> > wrote:
> Hi everyone,
> 
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
> 
> 
> This is my opinion, but I'd like to see Keystone use Barbican for storing 
> credentials. It hasn't happened yet because nobody's had the time or 
> inclination (what we have works). If this happened, we could deprecate the 
> current way of storing credentials and require Barbican in a couple of 
> releases. Then Barbican would be a required service. The Barbican team might 
> find this to be the easiest route towards convincing other projects to also 
> use Barbican.
> 
> - Brant
> 
> Can you provides some details on how you'd see this work?
> Since Barbican typically uses Keystone to authenticate users before 
> determining which secrets they have access to, this leads to a circular logic.
> 
> Barbican's main purpose is a secret manager.  It supports a variety of RBAC 
> and ACL access control methods to determine if a request to read/write/delete 
> a secret should be allowed or not.  For secret storage, Barbican itself needs 
> a secure backend for storage.  There is a customizable plugin interface to 
> access secure storage.  The current implementations can support a database 
> with encryption, an HSM via KMIP, and Dogtag.

Just bootstrap the genesis admin credentials into Barbican and Keystone
the same way we bootstrap them into Keystone now. Once there's admin
creds, they can be validated separate from updating them, and there's
no circle anymore, Just two one-way dependencies.

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Dave McCowan (dmccowan)]

On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
> wrote:
Hi everyone,

I've seen a few nascent projects wanting to implement their own secret
storage to either replace Barbican or avoid adding a dependency on it.
When I've pressed the developers on this point, the only answer I've
received is to make the operator's lives simpler.


This is my opinion, but I'd like to see Keystone use Barbican for storing 
credentials. It hasn't happened yet because nobody's had the time or 
inclination (what we have works). If this happened, we could deprecate the 
current way of storing credentials and require Barbican in a couple of 
releases. Then Barbican would be a required service. The Barbican team might 
find this to be the easiest route towards convincing other projects to also use 
Barbican.

- Brant

Can you provides some details on how you'd see this work?
Since Barbican typically uses Keystone to authenticate users before determining 
which secrets they have access to, this leads to a circular logic.

Barbican's main purpose is a secret manager.  It supports a variety of RBAC and 
ACL access control methods to determine if a request to read/write/delete a 
secret should be allowed or not.  For secret storage, Barbican itself needs a 
secure backend for storage.  There is a customizable plugin interface to access 
secure storage.  The current implementations can support a database with 
encryption, an HSM via KMIP, and Dogtag.

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Brant Knudson]

On Mon, Jan 16, 2017 at 7:35 AM, Ian Cordasco 
wrote:

> Hi everyone,
>
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
>
>
This is my opinion, but I'd like to see Keystone use Barbican for storing
credentials. It hasn't happened yet because nobody's had the time or
inclination (what we have works). If this happened, we could deprecate the
current way of storing credentials and require Barbican in a couple of
releases. Then Barbican would be a required service. The Barbican team
might find this to be the easiest route towards convincing other projects
to also use Barbican.

- Brant
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Jay Pipes <jaypi...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 17, 2017 at 12:31:21
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 01/17/2017 07:57 AM, Ian Cordasco wrote:
> > On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar wrote:
> >> Ian,
> >>
> >> This is a fascinating conversation. Let me offer two observations.
> >>
> >> First, Trove has long debated the ideal solution for storing secrets. There
> >> have been many conversations, and Barbican has been considered many times.
> >> We sought input from people who were deploying and operating Trove at 
> >> scale;
> >> customers of Tesora, self described users of the upstream Trove, and some 
> >> of
> >> the (then) active contributors who were also operators.
> >>
> >> The consensus was that installing and deploying OpenStack was hard enough
> >> and requiring the installation of yet more services was problematic. This 
> >> is
> >> not something which singles out Barbican in any way. For example, Trove 
> >> uses
> >> Swift as the default object store where backups are stored, and in
> >> implementing replication we leveraged the backup capability. This means 
> >> that
> >> to have replication, one needs to have Swift. Several deployers have
> >> objected to this since they don't have swift. But that is a dependency 
> >> which
> >> we considered to be a hard dependency and offer no alternatives; you can
> >> have Ceph if you so desire but we still access it as a swift store.
> >> Similarly we needed some capabilities of job scheduling and opted to use
> >> mistral for this; we didn't reimplement all of these capabilities in Trove.
> >>
> >> However, when it comes to secret storage, the consensus of opinion is
> >> Yet another service.
> >
> > So, what spurred this thread is that I'm currently working on Craton
> > which wants to store deployment secrets for operators and I've
> > recently received a lot of private mail about Glare and how one of its
> > goals is to replace Barbican (as well as Glance).
>
> Problem #1: private emails. Why? Encourage whomever is privately
> emailing you to instead post to the mailing list, otherwise parties are
> not acting in the Open[Stack] Way.

That has come up with those people.

> Problem #2: What does Glare have to do with secret storage? I can
> understand someone saying that Glare might eventually replace Glance,
> but I'm not aware of anyone ever building crypto use cases or
> functionality into the design of Glare. Ever.

This is exactly my understanding as well. Glare was meant to be an
artifact service, not a secrets service. I guess a reductionist could
claim all data is an artifact, but that's obviously a flawed argument.

--
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Jay Pipes]

On 01/16/2017 07:19 PM, Joshua Harlow wrote:

Fox, Kevin M wrote:

Your right, it is not what the big tent was about, but the big tent
had some unintended side affects. The list, as you stated:

* No longer having a formal incubation and graduation period/review for
applying projects
* Having a single, objective list of requirements and responsibilities
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the
same "space" (e.g. deployment or metrics)

Turned into (my opinion):

#1, projects, having a formal incubation/graduation period had the
opportunity to get feedback on what they could do to better integrate
with other projects and were strongly encouraged to do so to make
progress towards graduation. Without the formality, no one tended to
bother.

#2, Not having a single, objective list of
requirements/responsibility: I believe not having a list made folks
take a hard look at what other projects were doing and try harder to
play nice in order to get graduated or risk the unknown of folks
coming back over and over and telling them more integration was required.

#3, the benefits/drawbacks of specifically allowing competition is
rather hard to predict. It can encourage alternate solutions to be
created and create a place where better ideas can overcome less good
ideas. But it also removes pressure to cooperate on one project rather
then just take the sometimes much easier route of just doing it
yourself in your own project.

I'm not blaming the big tent for all the ills of the OpenStack world.
It has had some real benefits. This problem is something bigger then
the big tent. It preexisted the tent. The direction the pressure to
share was very unidirectional pre big tent, applied to new projects
much more then old projects.

But, I'm just saying the Big Tent had an (unintended) net negative
affect making this particular problem worse.

Looking at the why of a problem is one of the important steps to
formulating a solution. OpenStack no longer has the amount of tooling
to help elevate the issue it had under the time before the Big Tent.
Nothing has come up since to replace it.

I'm not stating that the big tent should be abolished and we go back
to the way things were. But I also know the status quo is not working
either. How do we fix this? Anyone have any thoughts?


Embrace the larger world instead of trying to recreate parts of it,
create alliances with the CNCF and/or other companies


The CNCF isn't a company...


that are getting actively involved there and make bets that solutions
there are things that people want to use directly (instead of turning
openstack into some kind of 'integration aka, middleware engine').


The complaint about Barbican that I heard from most folks on this thread 
was that it added yet another service to deploy to an OpenStack deployment.


If we use technology from the CNCF or elsewhere, we're still going to 
end up deploying yet another service. Just like if we want to use 
ZooKeeper for group membership instead of the Nova DB.


So, while I applaud the general idea of looking at the CNCF projects as 
solutions to some problems, you wouldn't be solving the actual issue 
brought to attention by operators and OpenStack project contributors (to 
Magnum/Craton): of needing to install yet another dependency.




How many folks have been watching
https://github.com/cncf/toc/tree/master/proposals or
https://github.com/cncf/toc/pulls?


I don't look at that feed, but I do monitor the pull requests for k8s 
and some other projects like rkt and ACI/OCI specs.



Start accepting that what we call OpenStack may be better off as
extracting the *current* good parts of OpenStack and cutting off some of
the parts that aren't really worth it/nobody really uses/deploys anyway


I'm curious what you think would be left in OpenStack?

BTW, the CNCF is already creating projects that duplicate functionality 
that's been available for years in other open source projects -- see 
prometheus and fluentd [1] -- in the guise of "unifying" things for a 
cloud-native world. I suspect that trend will continue as vendors jump 
from OpenStack to CNCF projects because they perceive it as the new 
shiny thing and capable of accepting their vendor-specific code quicker 
than OpenStack.


In fact, if you look at the CNCF projects, you see the exact same 
disagreement about the exact same two areas that we see so much 
duplication in the OpenStack community: deployment/installation and 
logging/monitoring/metrics. I mean, how many ways are there to deploy 
k8s at this point?


The things that the OpenStack ecosystem has proliferated as services or 
plugins are the exact same things that the CNCF projects are building 
into their architecture. How many service discovery mechanisms can 
Prometheus use? How many source and destination backends can fluentd 
support? And now with certain vendors trying to get more 
hardware-specific 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Jay Pipes]

On 01/17/2017 07:57 AM, Ian Cordasco wrote:

On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar  wrote:

Ian,

This is a fascinating conversation. Let me offer two observations.

First, Trove has long debated the ideal solution for storing secrets. There
have been many conversations, and Barbican has been considered many times.
We sought input from people who were deploying and operating Trove at scale;
customers of Tesora, self described users of the upstream Trove, and some of
the (then) active contributors who were also operators.

The consensus was that installing and deploying OpenStack was hard enough
and requiring the installation of yet more services was problematic. This is
not something which singles out Barbican in any way. For example, Trove uses
Swift as the default object store where backups are stored, and in
implementing replication we leveraged the backup capability. This means that
to have replication, one needs to have Swift. Several deployers have
objected to this since they don't have swift. But that is a dependency which
we considered to be a hard dependency and offer no alternatives; you can
have Ceph if you so desire but we still access it as a swift store.
Similarly we needed some capabilities of job scheduling and opted to use
mistral for this; we didn't reimplement all of these capabilities in Trove.

However, when it comes to secret storage, the consensus of opinion is
Yet another service.


So, what spurred this thread is that I'm currently working on Craton
which wants to store deployment secrets for operators and I've
recently received a lot of private mail about Glare and how one of its
goals is to replace Barbican (as well as Glance).


Problem #1: private emails. Why? Encourage whomever is privately 
emailing you to instead post to the mailing list, otherwise parties are 
not acting in the Open[Stack] Way.


Problem #2: What does Glare have to do with secret storage? I can 
understand someone saying that Glare might eventually replace Glance, 
but I'm not aware of anyone ever building crypto use cases or 
functionality into the design of Glare. Ever.


Best,
-jay

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Lance Bragstad]

I would consider that to be something that spans further than just barbican
and keystone. The ability to restrict a token to a single
service/operation/resource is a super interesting problem especially when
you start to consider operational dependencies between the services. If the
approach spans multiple service (which in this case I think it would need
to since it seems closely related to policy) communication gaps will only
make achieving it harder. I think Sean nailed it with his comment about
championing an effort across projects and closing communication gaps. We
are currently doing this on a smaller scale with the horizon team to smooth
out issues between horizon and keystone based on a set of things discussed
in Barcelona [0]. It's seems to be proving successful for both teams.

I'd love to set aside some time to get a discussion rolling in Atlanta
about this.


[0] http://eavesdrop.openstack.org/#Keystone/Horizon_Collaboration_Meeting

On Tue, Jan 17, 2017 at 10:55 AM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> Is this a Barbican problem or a Keystone one? The inability to restrict a
> token to go only to one service but instead any hacked service can be used
> to get tokens that can be used on any other service seems to to me to be a
> more general Keystone architectural problem to solve?
>
> Thanks,
> Kevin
> --
> *From:* Duncan Thomas [duncan.tho...@gmail.com]
> *Sent:* Tuesday, January 17, 2017 6:04 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [all] [barbican] [security] Why are
> projects trying to avoid Barbican, still?
>
>
>
> On 17 January 2017 at 13:41, Dave McCowan (dmccowan) <dmcco...@cisco.com>
> wrote:
>
>>
>> I don't know everything that was proposed in the Juno timeframe, or
>> before, but the Nova and Cinder integration has been done now.  The
>> documentation is at [1].  A cinder user can create an encryption key
>> through Barbican when creating a volume, then the same user (or a user with
>> permissions granted by that user), as a nova user, can retrieve that key
>> when mounting the encrypted volume.
>>
>
> Sure, cinder can add a secret and nova can retrieve it. But glance can
> *also* retrieve it. So can trove. And any other service that gets a normal
> keystone token from the user (i.e. just about all of them). This is, for
> some threat models, far worse that the secret being nice and safe int he
> cinder DB and only ever given out to nova via a trusted API path. The
> original design vision I saw for barbican was intended to have much better
> controls than this, but they never showed up AFAIK. And that's just the
> problem - people think 'Oh, barbican is storing the cinder volume secrets,
> great, we're secure' when actually barbican has made the security situation
> worse not better. It's a pretty terrible secrets-as-a-service product at
> the moment. Fixing it is not trivial.
>
> --
> Duncan Thomas
>
> __
> 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Dave McCowan (dmccowan)]

On 1/17/17, 5:37 AM, "Thierry Carrez"  wrote:

>I think the focus question is an illusion, as Ed brilliantly explained
>in https://blog.leafe.com/openstack-focus/
>
>The issue here is that it's just a lot more profitable career-wise and a
>lot less risky to work first-level user-visible features like Machine
>Learning as a service, than it is to work on infrastructural services
>like Glance, Keystone or Barbican. Developers naturally prefer to go to
>shiny objects than to boring technology. As long as their corporate
>sponsors are happy with them ignoring critical services, that will
>continue. Saying that some of those things are not part of our
>community, while they are developed by our community, is sticking our
>heads in the sand.

This trend identified by Ed and Thierry is evident in the group of
Barbican contributors.  Many of our previously active contributors have
moved on to other projects.  There are some quality ideas in this thread.
I hope I'm just stating the obvious here: there are no Barbican
contributors waiting in the wings with extra cycles to develop them.

If a Vault plugin or cross-project fine-grained access controls are
important to you or your company, please help us out.  I promise the
community is open to new ideas, new developers, and new reviewers.


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fox, Kevin M]

Is this a Barbican problem or a Keystone one? The inability to restrict a token 
to go only to one service but instead any hacked service can be used to get 
tokens that can be used on any other service seems to to me to be a more 
general Keystone architectural problem to solve?

Thanks,
Kevin

From: Duncan Thomas [duncan.tho...@gmail.com]
Sent: Tuesday, January 17, 2017 6:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
trying to avoid Barbican, still?



On 17 January 2017 at 13:41, Dave McCowan (dmccowan) 
<dmcco...@cisco.com<mailto:dmcco...@cisco.com>> wrote:

I don't know everything that was proposed in the Juno timeframe, or before, but 
the Nova and Cinder integration has been done now.  The documentation is at 
[1].  A cinder user can create an encryption key through Barbican when creating 
a volume, then the same user (or a user with permissions granted by that user), 
as a nova user, can retrieve that key when mounting the encrypted volume.

Sure, cinder can add a secret and nova can retrieve it. But glance can *also* 
retrieve it. So can trove. And any other service that gets a normal keystone 
token from the user (i.e. just about all of them). This is, for some threat 
models, far worse that the secret being nice and safe int he cinder DB and only 
ever given out to nova via a trusted API path. The original design vision I saw 
for barbican was intended to have much better controls than this, but they 
never showed up AFAIK. And that's just the problem - people think 'Oh, barbican 
is storing the cinder volume secrets, great, we're secure' when actually 
barbican has made the security situation worse not better. It's a pretty 
terrible secrets-as-a-service product at the moment. Fixing it is not trivial.

--
Duncan Thomas
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Sean Dague]

On 01/16/2017 08:35 AM, Ian Cordasco wrote:
> Hi everyone,
> 
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
> 
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
> 
> To help others help me, let me provide my point of view. Barbican's
> been around for a few years already and has been deployed by several
> companies which have probably audited it for security purposes. Most
> of the technology involved in Barbican is proven to be secure and the
> way the project has strung those pieces together has been analyzed by
> the OSSP (OpenStack's own security group). It doesn't have a
> requirement on a hardware TPM which means there's no hardware upgrade
> cost. Furthermore, several services already provide the option of
> using Barbican (but won't place a hard requirement on it). It stands
> to reason (in my opinion) that if new services have a need for secrets
> and other services already support using Barbican as secret storage,
> then those new services should be using Barbican. It seems a bit
> short-sighted of its developers to say that their users are definitely
> not deploying Barbican when projects like Magnum have soft
> dependencies on it.
> 
> Is the problem perhaps that no one is aware of other projects using
> Barbican? Is the status on the project navigator alarming (it looks
> like some of this information is potentially out of date)? Has
> Barbican been deemed too hard to deploy?
> 
> I really want to understand why so many projects feel the need to
> implement their own secrets storage. This seems a bit short-sighted
> and foolish. While these projects are making themselves easier to
> deploy, if not done properly they are potentially endangering their
> users and that seems like a bigger problem than deploying Barbican to
> me.

I don't pretend to have all the answers, but when doing some exploration
around the question of barbican as a default service during the late
summer, there were some community disconnects as well.

For instance, the barbican devstack plugin was just setting up barbican.
It wasn't actually configuring any existing services to use barbican, so
there wasn't any simple way to experiment with development with it (this
looks to have been fixed in Sept), or to understand gate reliability so
that it could be made less optional.

There was also a real concern about testability. For testing purposes
fixed key managers make a ton of sense, because you can crack them open
when things go wrong very easily to see what was going on. The barbican
team was pushing back on maintaining one of those on their side, because
it is inherently not secure. That moved the key manager plug point back
into the projects instead of a hard dependency on barbican, with a
testing mode that could be run. Joel and I had a long conversation about
this at the Nova midcycle in Portland. I'm not entirely sure where this
all landed.

There were also previous concerns about the stability of the API, where
version 2 -> 3 changes were made without a deprecation path or
guarantees. Only the fact that no one was deploying it saved people from
a pretty major upgrade breakage.

I think there is also a very real concern about how secure the secrets
are given how open ended the tokens are for users. Duncan raised this in
another part of the thread. From the outside it feels like Keystone and
Barbican need to be much closer integrated given that token security
implications directly impact on the security of the secrets in question.
If those things don't get solved coherently together, there are lots of
exposures there.

I definitely think that Barbican would be a good project to get elevated
to required component. Encrypting disks at rest by default with sane
keys should be standard behavior for an IaaS as it massively decreases
the data exposure of rogue VMs. (``dd if=/dev/vda | strings`` can turn
up interesting data in shared environments that aren't encrypted).

Doing so basically is going to require someone to champion project
managing this whole process, and discovering and bridging the existing
communication gaps that are there. There doesn't seem to be a ton of
natural overlap between contributors to barbican and the base IaaS
services today, which means plenty of communication gaps.

-Sean

-- 
Sean Dague
http://dague.net


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

On Tue, Jan 17, 2017 at 8:04 AM, Duncan Thomas  wrote:
> controls than this, but they never showed up AFAIK. And that's just the
> problem - people think 'Oh, barbican is storing the cinder volume secrets,
> great, we're secure' when actually barbican has made the security situation
> worse not better. It's a pretty terrible secrets-as-a-service product at the
> moment. Fixing it is not trivial.

So this is the second time you've asserted that Barbican is "a pretty
terrible secrets-as-a-service product". Instead of repeatedly saying
the same thing, have you worked with them on this? From your own
accounts, it sounds like you're not providing the constructively
critical feedback necessary to help the Barbican team and haven't
attempted to prior to this thread (although I'd not call your
criticisms constructive). I somehow doubt you'd be accepting of this
kind of feedback if it were aimed at Cinder. Are there open bugs that
have been ignored that you've filed? Items you've brought up at their
meetings?

To be clear, I started this thread to help the Barbican team gather
actionable items to further adoption because it seems a worthwhile
goal. Yes Barbican can improve, so can Cinder. So let's keep these
discussions constructive, okay?

-- 
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Duncan Thomas]

On 17 January 2017 at 13:41, Dave McCowan (dmccowan) 
wrote:

>
> I don't know everything that was proposed in the Juno timeframe, or
> before, but the Nova and Cinder integration has been done now.  The
> documentation is at [1].  A cinder user can create an encryption key
> through Barbican when creating a volume, then the same user (or a user with
> permissions granted by that user), as a nova user, can retrieve that key
> when mounting the encrypted volume.
>

Sure, cinder can add a secret and nova can retrieve it. But glance can
*also* retrieve it. So can trove. And any other service that gets a normal
keystone token from the user (i.e. just about all of them). This is, for
some threat models, far worse that the secret being nice and safe int he
cinder DB and only ever given out to nova via a trusted API path. The
original design vision I saw for barbican was intended to have much better
controls than this, but they never showed up AFAIK. And that's just the
problem - people think 'Oh, barbican is storing the cinder volume secrets,
great, we're secure' when actually barbican has made the security situation
worse not better. It's a pretty terrible secrets-as-a-service product at
the moment. Fixing it is not trivial.

-- 
Duncan Thomas
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Dave McCowan (dmccowan)]

On 1/16/17, 3:06 PM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:

>-Original Message-
>From: Dave McCowan (dmccowan) <dmcco...@cisco.com>
>Reply: OpenStack Development Mailing List (not for usage questions)
><openstack-dev@lists.openstack.org>
>Date: January 16, 2017 at 13:03:41
>To: OpenStack Development Mailing List (not for usage questions)
><openstack-dev@lists.openstack.org>
>Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>projects trying to avoid Barbican, still?
>> Yep. Barbican supports four backend secret stores. [1]
>>
>> The first (Simple Crypto) is easy to deploy, but not extraordinarily
>> secure, since the secrets are encrypted using a static key defined in
>>the
>> barbican.conf file.
>>
>> The second and third (PKCS#11 and KMIP) are secure, but require an HSM
>>as
>> a hardware base to encrypt and/or store the secrets.
>> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
>> encrypt and store the secrets.
>>
>> We do not currently have a secret store that is both highly secure and
>> easy to deploy/manage.
>>
>> We, the Barbican community, are very open to any ideas, blueprints, or
>> patches on how to achieve this.
>> In any of the homegrown per-project secret stores, has a solution been
>> developed that solves both of these?
>>
>>
>> [1]
>> 
>>http://docs.openstack.org/project-install-guide/key-manager/draft/barbica
>>n-
>> backend.html
>
>So there seems to be a consensus that Vault is a good easy and secure
>solution to deploy. Can Barbican use that as a backend secret store?

Adding a new secret store plugin for Vault would be a welcome addition.
We have documentation in our repo on how to write a new plugin. [1]   I
can schedule some time at the PTG to plan for this in Pike if there are
interested developers.

[1] 
https://github.com/openstack/barbican/blob/master/doc/source/plugin/secret_
store.rst


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Dave McCowan (dmccowan)]

From: Duncan Thomas <duncan.tho...@gmail.com<mailto:duncan.tho...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, January 16, 2017 at 5:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
trying to avoid Barbican, still?

To give a totally different prospective on why somebody might dislike Barbican 
(I'm one of those people). Note that I'm working from pretty hazy memories so I 
don't guarantee I've got everything spot on, and I am without a doubt giving a 
very one sided view. But hey, that's the side I happen to sit on. I certainly 
don't mean to cause great offence to the people concerned, but rather to give  
ahistory from a PoV that hasn't appeared yet.

Cinder needed somewhere to store volume encryption keys. Long, long ago, 
Barbican gave a great presentation about secrets as a service, ACLs on secrets, 
setups where one service could ask for keep material to be created and only 
accessible to some other service. Having one service give another service 
permission to get at a secret (but never be able to access that secret itself). 
All the clever things that cinder could possibly leverage. It would also handle 
hardware security modules and all of the other craziness that no sane person 
wants to understand the fine details of. Key revocation, rekeying and some 
other stuff was mentioned as being possible future work.

So I waited, and I waited, and I asked some security people about what Barbican 
was doing, and I got told it had gone off and done some unrelated to anything 
we wanted certificate cleverness stuff for some other service, but 
secrets-as-a-service would be along at some point. Eventually, a long time 
after all my enthusiasm had waned, the basic feature

It doesn't do what it says on the tin. It isn't very good at keeping secrets. 
If I've got a token then I can get the keys for all my volumes. That kind of 
sucks. For several threat models, I'd have done better to just stick the keys 
in the cinder db.

I really wish I'd got a video of that first presentation, because it would be 
an interesting project to implement. Barbican though, from a really narrow 
focused since usecase view point really isn't very good though.

(If I've missed something and Barbican can do the clever ACL type stuff that 
was talked about, please let me know - I'd be very interested in trying to fit 
it to cinder, and I'm not even working on cinder professionally currently.)

I don't know everything that was proposed in the Juno timeframe, or before, but 
the Nova and Cinder integration has been done now.  The documentation is at 
[1].  A cinder user can create an encryption key through Barbican when creating 
a volume, then the same user (or a user with permissions granted by that user), 
as a nova user, can retrieve that key when mounting the encrypted volume.

[1] 
http://docs.openstack.org/mitaka/config-reference/block-storage/volume-encryption.html

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

Just a quick note on Castellan, at the moment it's not a particularly
strong abstraction for key management in general, just the openstack
key management interface.

The reason this is important is because if I recall correctly, Castellan
requires a keystone token for auth. It should be no suprise that COTS
key managers, software or hardware, do not support this method of
authentication.

Unless something has changed recently, Castellan is good for allowing
teams to pivot between a local key management implementation or
Barbican but a long way from allowing a direct pivot to another key
management system.

I do recall some efforts to move beyond this limitation and implement
KMIP[1] for direct access to HSMs that support it, however I'm not sure
what the end result there was.

[1]
https://specs.openstack.org/openstack/barbican-specs/specs/mitaka/kmip-key-manager.html

On Tue, Jan 17, 2017 at 12:57 PM, Ian Cordasco 
wrote:

> On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar 
> wrote:
> > Ian,
> >
> > This is a fascinating conversation. Let me offer two observations.
> >
> > First, Trove has long debated the ideal solution for storing secrets.
> There
> > have been many conversations, and Barbican has been considered many
> times.
> > We sought input from people who were deploying and operating Trove at
> scale;
> > customers of Tesora, self described users of the upstream Trove, and
> some of
> > the (then) active contributors who were also operators.
> >
> > The consensus was that installing and deploying OpenStack was hard enough
> > and requiring the installation of yet more services was problematic.
> This is
> > not something which singles out Barbican in any way. For example, Trove
> uses
> > Swift as the default object store where backups are stored, and in
> > implementing replication we leveraged the backup capability. This means
> that
> > to have replication, one needs to have Swift. Several deployers have
> > objected to this since they don't have swift. But that is a dependency
> which
> > we considered to be a hard dependency and offer no alternatives; you can
> > have Ceph if you so desire but we still access it as a swift store.
> > Similarly we needed some capabilities of job scheduling and opted to use
> > mistral for this; we didn't reimplement all of these capabilities in
> Trove.
> >
> > However, when it comes to secret storage, the consensus of opinion is
> > Yet another service.
>
> So, what spurred this thread is that I'm currently working on Craton
> which wants to store deployment secrets for operators and I've
> recently received a lot of private mail about Glare and how one of its
> goals is to replace Barbican (as well as Glance).
>
> I'm quite happy that Trove has worked hard not to reimplement its
> requirements that were already satisfied by OpenStack projects. That's
> kind of what I'm hoping to help people do with Barbican in this
> thread.
>
> > Here is the second observation. This conversation reminds me of many
> > conversations from years past "Why do you want to use a NoSQL database,
> we
> > have a  database already". I've sat in on heated arguments
> > amongst architects who implemented "lightweight key-value storage based
> on
> > " and didn't use the corporate standard RDBMS.
>
> This I don't quite agree with this comparison. Surely when NoSQL came
> out, people ridiculed it for not having the same properties as RDBMS,
> but there's a large difference in people criticizing NoSQL databases
> having not used them and me asking people to use software that's
> already been audited for security and written by people who understand
> the underlying technologies.
>
> I'm sure if you said to your users and operators: "These N services
> need to store secrets and each has implemented that in its own way
> with no common configuration or storage location. None of them can
> take advantage of HSMs you have present in your infrastructure, and
> none of the people who really developed this are experts at storing
> secrets, but they tried their best!" Those operators would start to
> gnash their teeth and even maybe curse you under their breath. If you
> said "These services all need to store secrets securely, and that
> means we need to add Barbican which was written by people who took the
> time to document their threat models, perform a security analysis, and
> have worked with the larger security community to develop it." They'd
> be happier. I do understand, however, that your customers aren't
> deploying all the services that might use Barbican, and that's fine.
>
> What I'm gleaning from this conversation is that most of us have
> customers who only use 1 extra service that has a soft dependency on
> Barbican but never more than one. I have customers using Octavia and
> Magnum and a team that wants to use Craton, so it seems to me like we
> would benefit from doing the hard work of deploying Barbican but that
> situation is 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

On Mon, Jan 16, 2017 at 6:20 PM, Amrith Kumar  wrote:
> Ian,
>
> This is a fascinating conversation. Let me offer two observations.
>
> First, Trove has long debated the ideal solution for storing secrets. There
> have been many conversations, and Barbican has been considered many times.
> We sought input from people who were deploying and operating Trove at scale;
> customers of Tesora, self described users of the upstream Trove, and some of
> the (then) active contributors who were also operators.
>
> The consensus was that installing and deploying OpenStack was hard enough
> and requiring the installation of yet more services was problematic. This is
> not something which singles out Barbican in any way. For example, Trove uses
> Swift as the default object store where backups are stored, and in
> implementing replication we leveraged the backup capability. This means that
> to have replication, one needs to have Swift. Several deployers have
> objected to this since they don't have swift. But that is a dependency which
> we considered to be a hard dependency and offer no alternatives; you can
> have Ceph if you so desire but we still access it as a swift store.
> Similarly we needed some capabilities of job scheduling and opted to use
> mistral for this; we didn't reimplement all of these capabilities in Trove.
>
> However, when it comes to secret storage, the consensus of opinion is
> Yet another service.

So, what spurred this thread is that I'm currently working on Craton
which wants to store deployment secrets for operators and I've
recently received a lot of private mail about Glare and how one of its
goals is to replace Barbican (as well as Glance).

I'm quite happy that Trove has worked hard not to reimplement its
requirements that were already satisfied by OpenStack projects. That's
kind of what I'm hoping to help people do with Barbican in this
thread.

> Here is the second observation. This conversation reminds me of many
> conversations from years past "Why do you want to use a NoSQL database, we
> have a  database already". I've sat in on heated arguments
> amongst architects who implemented "lightweight key-value storage based on
> " and didn't use the corporate standard RDBMS.

This I don't quite agree with this comparison. Surely when NoSQL came
out, people ridiculed it for not having the same properties as RDBMS,
but there's a large difference in people criticizing NoSQL databases
having not used them and me asking people to use software that's
already been audited for security and written by people who understand
the underlying technologies.

I'm sure if you said to your users and operators: "These N services
need to store secrets and each has implemented that in its own way
with no common configuration or storage location. None of them can
take advantage of HSMs you have present in your infrastructure, and
none of the people who really developed this are experts at storing
secrets, but they tried their best!" Those operators would start to
gnash their teeth and even maybe curse you under their breath. If you
said "These services all need to store secrets securely, and that
means we need to add Barbican which was written by people who took the
time to document their threat models, perform a security analysis, and
have worked with the larger security community to develop it." They'd
be happier. I do understand, however, that your customers aren't
deploying all the services that might use Barbican, and that's fine.

What I'm gleaning from this conversation is that most of us have
customers who only use 1 extra service that has a soft dependency on
Barbican but never more than one. I have customers using Octavia and
Magnum and a team that wants to use Craton, so it seems to me like we
would benefit from doing the hard work of deploying Barbican but that
situation is rare.

> Finally, it is my personal belief that making software pluggable such that
> "if it discovers Barbican, it uses it, if it discovers XYZ it uses it, if it
> discovers PQR it uses that ..." is a very expensive design paradigm.  Unless
> Barbican, PQR, XYZ and any other implementation provide such material value
> to the consumer, and there is significant deployment and usage of each, the
> cost of maintaining the transparent pluggability of these, the cost of
> testing, and development all add up very quickly.

I believe this is exactly what Castellan is designed to be. That
interface so that services that want to have a soft requirement on
Barbican can do so through Castellan.

> Which is why when some project wants to store a secret, it ciphers it using
> some one way hash and stuffs that in a database (if that's all it needs).

Sometimes you need to get that secret back out though and that one way
hash won't cut it. Also you have to balance what most people on this
list consider "normal" deployments of OpenStack against the increasing
demand to be able to deploy OpenStack on a FIPS compliant 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

On Mon, Jan 16, 2017 at 6:11 PM, Joshua Harlow  wrote:
>> Is the problem perhaps that no one is aware of other projects using
>> Barbican? Is the status on the project navigator alarming (it looks
>> like some of this information is potentially out of date)? Has
>> Barbican been deemed too hard to deploy?
>>
>> I really want to understand why so many projects feel the need to
>> implement their own secrets storage. This seems a bit short-sighted
>> and foolish. While these projects are making themselves easier to
>> deploy, if not done properly they are potentially endangering their
>> users and that seems like a bigger problem than deploying Barbican to
>> me.
>>
>
> Just food for thought, and I'm pretty sure it's probably the same for
> various others; but one part that I feel is a reason that folks don't deploy
> barbican is because most companies need a solution that works beyond
> OpenStack and whether people like it or not, a OpenStack specific solution
> isn't really something that is attractive (especially with the growing
> adoption of other things that are *not* OpenStack).
>
> Another reason, some companies have or are already building/built solutions
> that offer functionality like what's in https://github.com/square/keywhiz
> and others and such things integrate with kubernetes and **their existing**
> systems ... natively already so why would they bother with a service like
> barbican?
>
> IMHO we've got to get our heads out of the sand with regard to some of this
> stuff, expecting people to consume all things OpenStack and only all things
> OpenStack is a losing battle; companies will consume what is right for their
> need, whether that is in the OpenStack community or not, it doesn't really
> matter (maybe at one point it did).

As long as they're using something secure, that's fine by me. Instead
these projects all want to reimplement the same functionality on their
own.

Does Castellan need to become something that can integrate with
Barbican + all of these other projects?

-- 
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Flavio Percoco]

On 16/01/17 16:57 -0500, Jay Pipes wrote:

On 01/16/2017 04:09 PM, Fox, Kevin M wrote:

If the developers that had issue with the lack of functionality,
contributed to Barbican rather then go off on their own, the problem
would have been solved much more quickly. The lack of sharing means
the problems don't get fixed as fast.


Agreed completely.


As for operators, If the more common projects all started depending
on it, it would be commonly deployed.


Also agreed.


Would the operators deploy Barbican just for Magnum? maybe not. maybe
so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
it if Neutron and Keystone depended on it, yeah. they would. And then
all the other projects would benefit from it being there, such as
Magnum.


Totally agreed.


The sooner OpenStack as a whole can decide on some new core
components so that projects can start hard depending on them, the
better I think. That process kind of stopped with the arrival of the
big tent.


You are using a false equivalence again.

As I've mentioned numerous times before on the mailing list, the Big 
Tent was NOT either of these things:


* Expanding what the "core components" of OpenStack
* Expanding the mission or scope of OpenStack

What the Big Tent -- technically "Project Structure Reform" -- was 
about was actually the following:


* No longer having a formal incubation and graduation period/review 
for applying projects
* Having a single, objective list of requirements and responsibilities 
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in 
the same "space" (e.g. deployment or metrics)


What you are complaining about (rightly IMHO) regarding OpenStack 
project contributors not contributing missing functionality to 
Barbican has absolutely nothing to do with the Big Tent:


There's no competing secret storage project in OpenStack other than 
Barbican/Castellan.


Furthermore, this behaviour of projects choosing to DIY/NIH something 
that existed in other projects was around long before the advent of 
the Big Tent. In fact, in this specific case, the Magnum team knew 
about Barbican, previously depended on it, and chose to make Barbican 
an option not because Barbican wasn't OpenStack -- it absolutely WAS 
-- but because it wasn't commonly deployed, which limited their own 
adoption.


What you are asking for, Kevin, is a single opinionated and 
consolidated OpenStack deployment; a single OpenStack "product" if you 
will. This is a perfectly valid request. However it has nothing to do 
with the Big Tent governance reform.


I guess this is also why castellan was created in the first place, which is to
try to avoid a single opinionated deployment, except that there's only one
secret storage service right now.

FWIW, The same thing happened with Zaqar, which was one of the first (if not the
first) project to join the Big Tent. To my knowledge, it's still neither widely
used nor deployed. Heat is using it, TripleO is using it (probably the biggest
consumer of Zaqar today). I can see Zaqar being adopted by several other 
services.

The point is, as Kevin mentioned, we would benefit more from consuming more of
our services rather than re-inventing some of this logics in every project.
We've faced this issue in different areas and the best solution has been to
consolidate on a fixed set of solutions that we can manage, support and
contribute. For example, Oslo.

So yeah, I'd love to see more projects consuming Barbican, even if it means that
a new service is required to have a working OpenStack.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Tim Bell]

On 17 Jan 2017, at 11:28, Maish Saidel-Keesing 
> wrote:


Please see inline.

On 17/01/17 9:36, Tim Bell wrote:

...
Are we really talking about Barbican or has the conversation drifted towards 
Big Tent concerns?

Perhaps we can flip this thread on it’s head and more positively discuss what 
can be done to improve Barbican, or ways that we can collaboratively address 
any issues. I’m almost wondering if some opinions about Barbican are even 
coming from its heavy users, or users who’ve placed much time into 
developing/improving Barbican? If not, let’s collectively change that.


When we started deploying Magnum, there was a pre-req for Barbican to store the 
container engine secrets. We were not so enthusiastic since there was no puppet 
configuration or RPM packaging.  However, with a few upstream contributions, 
these are now all resolved.

the operator documentation has improved, HA deployment is working and the 
unified openstack client support is now available in the latest versions.
Tim - where exactly is this documentation?

We followed the doc for installation at 
http://docs.openstack.org/project-install-guide/newton/, specifically for our 
environment (RDO/CentOS) 
http://docs.openstack.org/project-install-guide/key-manager/newton/

Tim


These extra parts may not be a direct deliverable of the code contributions 
itself but they make a major difference on deployability which Barbican now 
satisfies. Big tent projects should aim to cover these areas also if they wish 
to thrive in the community.

Tim


Thanks,
Kevin


Brandon B. Jozsa

--
Best Regards,
Maish Saidel-Keesing
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Thierry Carrez]

Qiming Teng wrote:
> On Mon, Jan 16, 2017 at 08:21:02PM +, Fox, Kevin M wrote:
>> IMO, This is why the big tent has been so damaging to OpenStack's progress. 
>> Instead of lifting the commons up, by requiring dependencies on other 
>> projects, there by making them commonly deployed and high quality, post big 
>> tent, each project reimplements just enough to get away with making 
>> something optional, and then the commons, and OpenStack as a whole suffers. 
>> This behavior MUST STOP if OpenStack is to make progress again. Other 
>> projects, such as Kubernetes are making tremendous progress because they are 
>> not hamstrung by one component trying desperately not to depend on another 
>> when the dependency is appropriate. They enhance the existing component 
>> until its suitable and the whole project benefits. Yes, as an isolated dev, 
>> the behavior to make deps optional seems to make sense. But as a whole, 
>> OpenStack is suffering and will become increasingly irrelevant moving 
>> forward if the current path is continued. Please, please reconsider what the 
>> current stance on dependencies is d
>>  oing to the community. This problem is not just isolated to barbican, but 
>> lots of other projects as well. We can either help pull each other up, or we 
>> can step on each other to try and get "on top". I'd rather we help each 
>> other rather then the destructive path we seem to be on.
> 
> Very well said, Kevin. The problem is not just about Barbican. Time for
> the TC and the whole community to rethink or even just to realize
> where we are heading ... Time for each and every projects to do some
> introspection ... Time to solve this chicken-and-egg problem.

The service dependency issue is, indeed, a difficult problem to solve.
In the early days of OpenStack, we decided that every service could
assume that a number of base services would be available: a relational
database (MySQL), a message queue (RabbitMQ), and an AuthN/AuthZ token
service (Keystone). That served us well, but we were unable to grow that
set of "base services".

We need more advanced features, like a distributed lock manager
(Zookeeper?), or a secrets vault (Barbican?), but rather than making the
hard decision, we work around their absence in every project, badly
emulating those features using what we have. This has nothing to do with
the big tent or the way we structure projects. It just has to do with
the size of this community. It was easier to agree to depend on MySQL
and RabbitMQ and Keystone when we were 100.

Now, how do we solve it ? First, we need to realize what the issue is,
define language around it. Using the Architecture WG as a vehicle, I
started to push the idea of defining "base services"[1] (resources that
other services can assume will be present). This is the first step:
realizing we do have base services, and need a way to *extend* them.

[1]
https://git.openstack.org/cgit/openstack/arch-wg/tree/proposals/base-services.rst

The next step will be to propose NEW base services. It's simpler than
you think -- the TC will just say it's fine to assume that service X
will be present. We obviously need to pick the right solutions, the ones
that solve the problem set and actually are not horrible to deploy. I
expect the Architecture WG to help in that analysis. But beyond that,
making the decision that it is OK to depend on them is not that hard.

> Stick together, there seems still a chance for future; otherwise, we
> will feel guilty wasting people's life building something that is
> falling apart eventually. Should we kill all "sh**-as-a-service"
> projects and focus on the few "core" services and hope they will meet
> all users' requirements? Or, should we give every project an equal
> chance to be adopted? Who is blocking other services to get adopted?
> How many projects are listed on the project navigator?

I think the focus question is an illusion, as Ed brilliantly explained
in https://blog.leafe.com/openstack-focus/

The issue here is that it's just a lot more profitable career-wise and a
lot less risky to work first-level user-visible features like Machine
Learning as a service, than it is to work on infrastructural services
like Glance, Keystone or Barbican. Developers naturally prefer to go to
shiny objects than to boring technology. As long as their corporate
sponsors are happy with them ignoring critical services, that will
continue. Saying that some of those things are not part of our
community, while they are developed by our community, is sticking our
heads in the sand.

We can certainly influence where those corporate sponsors dedicate their
development resources (and I think we should definitely pursue the base
service stuff, to send a strong signal), but we don't directly control
where the resources are spent.

-- 
Thierry Carrez (ttx)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Maish Saidel-Keesing]

Please see inline.


On 17/01/17 9:36, Tim Bell wrote:
>
>> On 17 Jan 2017, at 01:19, Brandon B. Jozsa > > wrote:
>>
>> Inline
>>
>> On January 16, 2017 at 7:04:00 PM, Fox, Kevin M (kevin@pnnl.gov
>> ) wrote:
>>
>>>
>>> I'm not stating that the big tent should be abolished and we go back
>>> to the way things were. But I also know the status quo is not
>>> working either. How do we fix this? Anyone have any thoughts? 
>>>
>>
>> Are we really talking about Barbican or has the conversation drifted
>> towards Big Tent concerns?
>>
>> Perhaps we can flip this thread on it’s head and more positively
>> discuss what can be done to improve Barbican, or ways that we can
>> collaboratively address any issues. I’m almost wondering if some
>> opinions about Barbican are even coming from its heavy users, or
>> users who’ve placed much time into developing/improving Barbican? If
>> not, let’s collectively change that.
>>
>
> When we started deploying Magnum, there was a pre-req for Barbican to
> store the container engine secrets. We were not so enthusiastic since
> there was no puppet configuration or RPM packaging.  However, with a
> few upstream contributions, these are now all resolved.
>
> the operator documentation has improved, HA deployment is working and
> the unified openstack client support is now available in the latest
> versions.
Tim - where exactly is this documentation?
>
> These extra parts may not be a direct deliverable of the code
> contributions itself but they make a major difference on deployability
> which Barbican now satisfies. Big tent projects should aim to cover
> these areas also if they wish to thrive in the community.
>
> Tim
>
>>
>>> Thanks, 
>>> Kevin 
>>
>> Brandon B. Jozsa
>>

-- 
Best Regards,
Maish Saidel-Keesing
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Tim Bell]

On 17 Jan 2017, at 01:19, Brandon B. Jozsa 
> wrote:

Inline


On January 16, 2017 at 7:04:00 PM, Fox, Kevin M 
(kevin@pnnl.gov) wrote:

I'm not stating that the big tent should be abolished and we go back to the way 
things were. But I also know the status quo is not working either. How do we 
fix this? Anyone have any thoughts?


Are we really talking about Barbican or has the conversation drifted towards 
Big Tent concerns?

Perhaps we can flip this thread on it’s head and more positively discuss what 
can be done to improve Barbican, or ways that we can collaboratively address 
any issues. I’m almost wondering if some opinions about Barbican are even 
coming from its heavy users, or users who’ve placed much time into 
developing/improving Barbican? If not, let’s collectively change that.


When we started deploying Magnum, there was a pre-req for Barbican to store the 
container engine secrets. We were not so enthusiastic since there was no puppet 
configuration or RPM packaging.  However, with a few upstream contributions, 
these are now all resolved.

the operator documentation has improved, HA deployment is working and the 
unified openstack client support is now available in the latest versions.

These extra parts may not be a direct deliverable of the code contributions 
itself but they make a major difference on deployability which Barbican now 
satisfies. Big tent projects should aim to cover these areas also if they wish 
to thrive in the community.

Tim


Thanks,
Kevin


Brandon B. Jozsa

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Qiming Teng]

On Mon, Jan 16, 2017 at 08:21:02PM +, Fox, Kevin M wrote:
> IMO, This is why the big tent has been so damaging to OpenStack's progress. 
> Instead of lifting the commons up, by requiring dependencies on other 
> projects, there by making them commonly deployed and high quality, post big 
> tent, each project reimplements just enough to get away with making something 
> optional, and then the commons, and OpenStack as a whole suffers. This 
> behavior MUST STOP if OpenStack is to make progress again. Other projects, 
> such as Kubernetes are making tremendous progress because they are not 
> hamstrung by one component trying desperately not to depend on another when 
> the dependency is appropriate. They enhance the existing component until its 
> suitable and the whole project benefits. Yes, as an isolated dev, the 
> behavior to make deps optional seems to make sense. But as a whole, OpenStack 
> is suffering and will become increasingly irrelevant moving forward if the 
> current path is continued. Please, please reconsider what the current stance 
> on dependencies is d
>  oing to the community. This problem is not just isolated to barbican, but 
> lots of other projects as well. We can either help pull each other up, or we 
> can step on each other to try and get "on top". I'd rather we help each other 
> rather then the destructive path we seem to be on.
> 
> My 2 cents.
> Kevin
> 

Very well said, Kevin. The problem is not just about Barbican. Time for
the TC and the whole community to rethink or even just to realize
where we are heading ... Time for each and every projects to do some
introspection ... Time to solve this chicken-and-egg problem.

Stick together, there seems still a chance for future; otherwise, we
will feel guilty wasting people's life building something that is
falling apart eventually. Should we kill all "sh**-as-a-service"
projects and focus on the few "core" services and hope they will meet
all users' requirements? Or, should we give every project an equal
chance to be adopted? Who is blocking other services to get adopted?
How many projects are listed on the project navigator?

- Qiming


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fei Long Wang]

On 17/01/17 13:00, Fox, Kevin M wrote:
> Your right, it is not what the big tent was about, but the big tent had some 
> unintended side affects. The list, as you stated:
>
> * No longer having a formal incubation and graduation period/review for
> applying projects
> * Having a single, objective list of requirements and responsibilities
> for inclusion into the OpenStack development community
> * Specifically allowing competition of different source projects in the
> same "space" (e.g. deployment or metrics)
>
> Turned into (my opinion):
>
> #1, projects, having a formal incubation/graduation period had the 
> opportunity to get feedback on what they could do to better integrate with 
> other projects and were strongly encouraged to do so to make progress towards 
> graduation. Without the formality, no one tended to bother.
>
> #2, Not having a single, objective list of requirements/responsibility: I 
> believe not having a list made folks take a hard look at what other projects 
> were doing and try harder to play nice in order to get graduated or risk the 
> unknown of folks coming back over and over and telling them more integration 
> was required.
>
> #3, the benefits/drawbacks of specifically allowing competition is rather 
> hard to predict. It can encourage alternate solutions to be created and 
> create a place where better ideas can overcome less good ideas. But it also 
> removes pressure to cooperate on one project rather then just take the 
> sometimes much easier route of just doing it yourself in your own project.
>
> I'm not blaming the big tent for all the ills of the OpenStack world. It has 
> had some real benefits. This problem is something bigger then the big tent. 
> It preexisted the tent. The direction the pressure to share was very 
> unidirectional pre big tent, applied to new projects much more then old 
> projects.
>
> But, I'm just saying the Big Tent had an (unintended) net negative affect 
> making this particular problem worse.
>
> Looking at the why of a problem is one of the important steps to formulating 
> a solution. OpenStack no longer has the amount of tooling to help elevate the 
> issue it had under the time before the Big Tent. Nothing has come up since to 
> replace it.
>
> I'm not stating that the big tent should be abolished and we go back to the 
> way things were. But I also know the status quo is not working either. How do 
> we fix this? Anyone have any thoughts? 

Could we create a new tag (at
https://governance.openstack.org/tc/reference/tags/) to indicate the
project is trusted to be integrated. Then, if there is a existing
project want to use a feature in the trusted-integrated project, then no
new wheel. To be more clear, the integration is a force integration.
Look at this list, https://www.openstack.org/software/project-navigator/
most of the projects has been developed more than 3 years,
unfortunately, they're not trusted, on the contrary, sometimes we're
brave to use some 3rd party library very new. That's a little ironic.

>
> Thanks,
> Kevin
> ________________
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Monday, January 16, 2017 1:57 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
> On 01/16/2017 04:09 PM, Fox, Kevin M wrote:
>> If the developers that had issue with the lack of functionality,
>> contributed to Barbican rather then go off on their own, the problem
>>  would have been solved much more quickly. The lack of sharing means
>>  the problems don't get fixed as fast.
> Agreed completely.
>
>> As for operators, If the more common projects all started depending
>> on it, it would be commonly deployed.
> Also agreed.
>
>> Would the operators deploy Barbican just for Magnum? maybe not. maybe
>> so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
>> it if Neutron and Keystone depended on it, yeah. they would. And then
>> all the other projects would benefit from it being there, such as
>> Magnum.
> Totally agreed.
>
>  > The sooner OpenStack as a whole can decide on some new core
>> components so that projects can start hard depending on them, the
>> better I think. That process kind of stopped with the arrival of the
>> big tent.
> You are using a false equivalence again.
>
> As I've mentioned numerous times before on the mailing list, the Big
> Tent was NOT either of these things:
>
> * Expanding what the "core components" of OpenStack
> * Expanding the mission or scope of OpenStack
>
> What the Big Tent -- technically "Project Structure Reform" -- was about

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Amrith Kumar]

Ian,

This is a fascinating conversation. Let me offer two observations.

First, Trove has long debated the ideal solution for storing secrets. There
have been many conversations, and Barbican has been considered many times.
We sought input from people who were deploying and operating Trove at scale;
customers of Tesora, self described users of the upstream Trove, and some of
the (then) active contributors who were also operators.

The consensus was that installing and deploying OpenStack was hard enough
and requiring the installation of yet more services was problematic. This is
not something which singles out Barbican in any way. For example, Trove uses
Swift as the default object store where backups are stored, and in
implementing replication we leveraged the backup capability. This means that
to have replication, one needs to have Swift. Several deployers have
objected to this since they don't have swift. But that is a dependency which
we considered to be a hard dependency and offer no alternatives; you can
have Ceph if you so desire but we still access it as a swift store.
Similarly we needed some capabilities of job scheduling and opted to use
mistral for this; we didn't reimplement all of these capabilities in Trove.

However, when it comes to secret storage, the consensus of opinion is
Yet another service.

Here is the second observation. This conversation reminds me of many
conversations from years past "Why do you want to use a NoSQL database, we
have a  database already". I've sat in on heated arguments
amongst architects who implemented "lightweight key-value storage based on
" and didn't use the corporate standard RDBMS.

One size doesn't fit all. And today, ten years on, it is clear that there
are legitimate situations where one would be silly to require an architect
to use a RDBMS; we talk of polyglot persistence as a matter of course.

The thing is this; Barbican may be a fine project with a ton of capabilities
that I don't even know of nor have the ability to comprehend. But there's a
minimum threshold of requirements that I need to have before the benefit of
the new dependency becomes valuable. From Trove's perspective, I don't
believe we have crossed that threshold (yet). If Barbican were a library not
a project, it may be a much easier sell for deployers.

Finally, it is my personal belief that making software pluggable such that
"if it discovers Barbican, it uses it, if it discovers XYZ it uses it, if it
discovers PQR it uses that ..." is a very expensive design paradigm.  Unless
Barbican, PQR, XYZ and any other implementation provide such material value
to the consumer, and there is significant deployment and usage of each, the
cost of maintaining the transparent pluggability of these, the cost of
testing, and development all add up very quickly.

Which is why when some project wants to store a secret, it ciphers it using
some one way hash and stuffs that in a database (if that's all it needs).

My 2c is that requiring projects to use Barbican as the secret store is the
equivalent of requiring developers (10 years ago) to use an RDBMS. One size
doesn't fit all ... Barbican is a "one size" secret store, I don't need all
of the bells and whistles just as the guy who wants a key value store
doesn't mind eventual consistency, lost writes, but can't take the cost of a
traditional RDBMS.

Thanks,

-amrith



> -Original Message-
> From: Ian Cordasco [mailto:sigmaviru...@gmail.com]
> Sent: Monday, January 16, 2017 8:36 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [all] [barbican] [security] Why are projects
trying to
> avoid Barbican, still?
> 
> Hi everyone,
> 
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
> 
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
> 
> To help others help me, let me provide my point of view. Barbican's been
> around for a few years already and has been deployed by several companies
> which have probably audited it for security purposes. Most of the
technology
> involved in Barbican is proven to be secure and the way the project has
> strung those pieces together has been analyzed by the OSSP (OpenStack's
> own security group). It doesn't have a requirement on a hardware TPM
> which means there's no hardware upgrade cost. Furthermore, several
> services already provide the option of using Barbican (but won't place a
hard
> requirement on it). It stands to reason (in my opinion) that if new
services
> have a need for secrets

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Joshua Harlow]

Fox, Kevin M wrote:

Your right, it is not what the big tent was about, but the big tent had some 
unintended side affects. The list, as you stated:

* No longer having a formal incubation and graduation period/review for
applying projects
* Having a single, objective list of requirements and responsibilities
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the
same "space" (e.g. deployment or metrics)

Turned into (my opinion):

#1, projects, having a formal incubation/graduation period had the opportunity 
to get feedback on what they could do to better integrate with other projects 
and were strongly encouraged to do so to make progress towards graduation. 
Without the formality, no one tended to bother.

#2, Not having a single, objective list of requirements/responsibility: I 
believe not having a list made folks take a hard look at what other projects 
were doing and try harder to play nice in order to get graduated or risk the 
unknown of folks coming back over and over and telling them more integration 
was required.

#3, the benefits/drawbacks of specifically allowing competition is rather hard 
to predict. It can encourage alternate solutions to be created and create a 
place where better ideas can overcome less good ideas. But it also removes 
pressure to cooperate on one project rather then just take the sometimes much 
easier route of just doing it yourself in your own project.

I'm not blaming the big tent for all the ills of the OpenStack world. It has 
had some real benefits. This problem is something bigger then the big tent. It 
preexisted the tent. The direction the pressure to share was very 
unidirectional pre big tent, applied to new projects much more then old 
projects.

But, I'm just saying the Big Tent had an (unintended) net negative affect 
making this particular problem worse.

Looking at the why of a problem is one of the important steps to formulating a 
solution. OpenStack no longer has the amount of tooling to help elevate the 
issue it had under the time before the Big Tent. Nothing has come up since to 
replace it.

I'm not stating that the big tent should be abolished and we go back to the way 
things were. But I also know the status quo is not working either. How do we 
fix this? Anyone have any thoughts?


Embrace the larger world instead of trying to recreate parts of it, 
create alliances with the CNCF and/or other companies that are getting 
actively involved there and make bets that solutions there are things 
that people want to use directly (instead of turning openstack into some 
kind of 'integration aka, middleware engine').


How many folks have been watching 
https://github.com/cncf/toc/tree/master/proposals or 
https://github.com/cncf/toc/pulls?


Start accepting that what we call OpenStack may be better off as 
extracting the *current* good parts of OpenStack and cutting off some of 
the parts that aren't really worth it/nobody really uses/deploys anyway 
(and say starting to modernize the parts that are left by say moving 
them under the CNCF umbrella and adopting some of the technology there 
instead).


Rinse and repeat this same shift after say another ~6 years when the 
CNCF accumulates enough projects that nobody really uses/deploys.


-Josh




__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Brandon B. Jozsa]

Inline


On January 16, 2017 at 7:04:00 PM, Fox, Kevin M 
(kevin@pnnl.gov) wrote:

I'm not stating that the big tent should be abolished and we go back to the way 
things were. But I also know the status quo is not working either. How do we 
fix this? Anyone have any thoughts?


Are we really talking about Barbican or has the conversation drifted towards 
Big Tent concerns?

Perhaps we can flip this thread on it’s head and more positively discuss what 
can be done to improve Barbican, or ways that we can collaboratively address 
any issues. I’m almost wondering if some opinions about Barbican are even 
coming from its heavy users, or users who’ve placed much time into 
developing/improving Barbican? If not, let’s collectively change that.


Thanks,
Kevin


Brandon B. Jozsa
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Joshua Harlow]

Is the problem perhaps that no one is aware of other projects using
Barbican? Is the status on the project navigator alarming (it looks
like some of this information is potentially out of date)? Has
Barbican been deemed too hard to deploy?

I really want to understand why so many projects feel the need to
implement their own secrets storage. This seems a bit short-sighted
and foolish. While these projects are making themselves easier to
deploy, if not done properly they are potentially endangering their
users and that seems like a bigger problem than deploying Barbican to
me.



Just food for thought, and I'm pretty sure it's probably the same for 
various others; but one part that I feel is a reason that folks don't 
deploy barbican is because most companies need a solution that works 
beyond OpenStack and whether people like it or not, a OpenStack specific 
solution isn't really something that is attractive (especially with the 
growing adoption of other things that are *not* OpenStack).


Another reason, some companies have or are already building/built 
solutions that offer functionality like what's in 
https://github.com/square/keywhiz and others and such things integrate 
with kubernetes and **their existing** systems ... natively already so 
why would they bother with a service like barbican?


IMHO we've got to get our heads out of the sand with regard to some of 
this stuff, expecting people to consume all things OpenStack and only 
all things OpenStack is a losing battle; companies will consume what is 
right for their need, whether that is in the OpenStack community or not, 
it doesn't really matter (maybe at one point it did).


My 2 cents,

Josh

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fox, Kevin M]

Your right, it is not what the big tent was about, but the big tent had some 
unintended side affects. The list, as you stated:

* No longer having a formal incubation and graduation period/review for
applying projects
* Having a single, objective list of requirements and responsibilities
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the
same "space" (e.g. deployment or metrics)

Turned into (my opinion):

#1, projects, having a formal incubation/graduation period had the opportunity 
to get feedback on what they could do to better integrate with other projects 
and were strongly encouraged to do so to make progress towards graduation. 
Without the formality, no one tended to bother.

#2, Not having a single, objective list of requirements/responsibility: I 
believe not having a list made folks take a hard look at what other projects 
were doing and try harder to play nice in order to get graduated or risk the 
unknown of folks coming back over and over and telling them more integration 
was required.

#3, the benefits/drawbacks of specifically allowing competition is rather hard 
to predict. It can encourage alternate solutions to be created and create a 
place where better ideas can overcome less good ideas. But it also removes 
pressure to cooperate on one project rather then just take the sometimes much 
easier route of just doing it yourself in your own project.

I'm not blaming the big tent for all the ills of the OpenStack world. It has 
had some real benefits. This problem is something bigger then the big tent. It 
preexisted the tent. The direction the pressure to share was very 
unidirectional pre big tent, applied to new projects much more then old 
projects.

But, I'm just saying the Big Tent had an (unintended) net negative affect 
making this particular problem worse.

Looking at the why of a problem is one of the important steps to formulating a 
solution. OpenStack no longer has the amount of tooling to help elevate the 
issue it had under the time before the Big Tent. Nothing has come up since to 
replace it.

I'm not stating that the big tent should be abolished and we go back to the way 
things were. But I also know the status quo is not working either. How do we 
fix this? Anyone have any thoughts?

Thanks,
Kevin

From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday, January 16, 2017 1:57 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
trying to avoid Barbican, still?

On 01/16/2017 04:09 PM, Fox, Kevin M wrote:
> If the developers that had issue with the lack of functionality,
> contributed to Barbican rather then go off on their own, the problem
>  would have been solved much more quickly. The lack of sharing means
>  the problems don't get fixed as fast.

Agreed completely.

> As for operators, If the more common projects all started depending
> on it, it would be commonly deployed.

Also agreed.

> Would the operators deploy Barbican just for Magnum? maybe not. maybe
> so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
> it if Neutron and Keystone depended on it, yeah. they would. And then
> all the other projects would benefit from it being there, such as
> Magnum.

Totally agreed.

 > The sooner OpenStack as a whole can decide on some new core
> components so that projects can start hard depending on them, the
> better I think. That process kind of stopped with the arrival of the
> big tent.

You are using a false equivalence again.

As I've mentioned numerous times before on the mailing list, the Big
Tent was NOT either of these things:

* Expanding what the "core components" of OpenStack
* Expanding the mission or scope of OpenStack

What the Big Tent -- technically "Project Structure Reform" -- was about
was actually the following:

* No longer having a formal incubation and graduation period/review for
applying projects
* Having a single, objective list of requirements and responsibilities
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the
same "space" (e.g. deployment or metrics)

What you are complaining about (rightly IMHO) regarding OpenStack
project contributors not contributing missing functionality to Barbican
has absolutely nothing to do with the Big Tent:

There's no competing secret storage project in OpenStack other than
Barbican/Castellan.

Furthermore, this behaviour of projects choosing to DIY/NIH something
that existed in other projects was around long before the advent of the
Big Tent. In fact, in this specific case, the Magnum team knew about
Barbican, previously depended on it, and chose to make Barbican an
option not because Barbican wasn't OpenStack -- it absolutely WAS -- but
because it wasn't

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Adam Harwell]

The "single master token" issue is something I think a lot of services may
suffer from, and it's definitely something the Barbican folks are aware of
(I've made it a point to personally bring this up many times, including
hijacking parts of the keystone and barbican sessions at the Tokyo, Austin,
and Barcelona summits). When ACLs work, they should do this job,  but there
should also be better ways to do this. I know there have been proposals
around using more tightly scoped Trusts (I participated in proposing some)
but I don't know how much traction they actually got.

Yes, currently Barbican does both secret storage and certificate
provisioning, though I'm certain that basic secret storage was fully
implemented before any of the certificate stuff ever happened… I believe
you are correct though that it should be more tightly focused, and I think
the Barbican team agrees as well -- to my (admittedly fuzzy) recollection
there was agreement to split the certificate provisioning system into
another project as of version two of the API. Maybe Dave or Doug can
confirm this?

And for the record, Neutron-LBaaS and Octavia have at least a soft
requirement for Barbican, which is to say we only support our TLS
Termination features if Barbican is deployed. We do have our own
Castellan-like interface, but it only has a Barbican driver, and we'd love
to have that interface merged with Castellan if possible (I'm still salty
that this didn't happen years ago, but that's a much longer story).

--Adam Harwell

On Mon, Jan 16, 2017, 14:36 Duncan Thomas  wrote:

> To give a totally different prospective on why somebody might dislike
> Barbican (I'm one of those people). Note that I'm working from pretty hazy
> memories so I don't guarantee I've got everything spot on, and I am without
> a doubt giving a very one sided view. But hey, that's the side I happen to
> sit on. I certainly don't mean to cause great offence to the people
> concerned, but rather to give  ahistory from a PoV that hasn't appeared yet.
>
> Cinder needed somewhere to store volume encryption keys. Long, long ago,
> Barbican gave a great presentation about secrets as a service, ACLs on
> secrets, setups where one service could ask for keep material to be created
> and only accessible to some other service. Having one service give another
> service permission to get at a secret (but never be able to access that
> secret itself). All the clever things that cinder could possibly leverage.
> It would also handle hardware security modules and all of the other
> craziness that no sane person wants to understand the fine details of. Key
> revocation, rekeying and some other stuff was mentioned as being possible
> future work.
>
> So I waited, and I waited, and I asked some security people about what
> Barbican was doing, and I got told it had gone off and done some unrelated
> to anything we wanted certificate cleverness stuff for some other service,
> but secrets-as-a-service would be along at some point. Eventually, a long
> time after all my enthusiasm had waned, the basic feature
>
> It doesn't do what it says on the tin. It isn't very good at keeping
> secrets. If I've got a token then I can get the keys for all my volumes.
> That kind of sucks. For several threat models, I'd have done better to just
> stick the keys in the cinder db.
>
> I really wish I'd got a video of that first presentation, because it would
> be an interesting project to implement. Barbican though, from a really
> narrow focused since usecase view point really isn't very good though.
>
> (If I've missed something and Barbican can do the clever ACL type stuff
> that was talked about, please let me know - I'd be very interested in
> trying to fit it to cinder, and I'm not even working on cinder
> professionally currently.)
> __
> 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Duncan Thomas]

To give a totally different prospective on why somebody might dislike
Barbican (I'm one of those people). Note that I'm working from pretty hazy
memories so I don't guarantee I've got everything spot on, and I am without
a doubt giving a very one sided view. But hey, that's the side I happen to
sit on. I certainly don't mean to cause great offence to the people
concerned, but rather to give  ahistory from a PoV that hasn't appeared yet.

Cinder needed somewhere to store volume encryption keys. Long, long ago,
Barbican gave a great presentation about secrets as a service, ACLs on
secrets, setups where one service could ask for keep material to be created
and only accessible to some other service. Having one service give another
service permission to get at a secret (but never be able to access that
secret itself). All the clever things that cinder could possibly leverage.
It would also handle hardware security modules and all of the other
craziness that no sane person wants to understand the fine details of. Key
revocation, rekeying and some other stuff was mentioned as being possible
future work.

So I waited, and I waited, and I asked some security people about what
Barbican was doing, and I got told it had gone off and done some unrelated
to anything we wanted certificate cleverness stuff for some other service,
but secrets-as-a-service would be along at some point. Eventually, a long
time after all my enthusiasm had waned, the basic feature

It doesn't do what it says on the tin. It isn't very good at keeping
secrets. If I've got a token then I can get the keys for all my volumes.
That kind of sucks. For several threat models, I'd have done better to just
stick the keys in the cinder db.

I really wish I'd got a video of that first presentation, because it would
be an interesting project to implement. Barbican though, from a really
narrow focused since usecase view point really isn't very good though.

(If I've missed something and Barbican can do the clever ACL type stuff
that was talked about, please let me know - I'd be very interested in
trying to fit it to cinder, and I'm not even working on cinder
professionally currently.)
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Jay Pipes]

On 01/16/2017 04:09 PM, Fox, Kevin M wrote:

If the developers that had issue with the lack of functionality,
contributed to Barbican rather then go off on their own, the problem
 would have been solved much more quickly. The lack of sharing means
 the problems don't get fixed as fast.


Agreed completely.


As for operators, If the more common projects all started depending
on it, it would be commonly deployed.


Also agreed.


Would the operators deploy Barbican just for Magnum? maybe not. maybe
so. For Magnum, Ironic, and Sahara, more likely . Would they deploy
it if Neutron and Keystone depended on it, yeah. they would. And then
all the other projects would benefit from it being there, such as
Magnum.


Totally agreed.

> The sooner OpenStack as a whole can decide on some new core

components so that projects can start hard depending on them, the
better I think. That process kind of stopped with the arrival of the
big tent.


You are using a false equivalence again.

As I've mentioned numerous times before on the mailing list, the Big 
Tent was NOT either of these things:


* Expanding what the "core components" of OpenStack
* Expanding the mission or scope of OpenStack

What the Big Tent -- technically "Project Structure Reform" -- was about 
was actually the following:


* No longer having a formal incubation and graduation period/review for 
applying projects
* Having a single, objective list of requirements and responsibilities 
for inclusion into the OpenStack development community
* Specifically allowing competition of different source projects in the 
same "space" (e.g. deployment or metrics)


What you are complaining about (rightly IMHO) regarding OpenStack 
project contributors not contributing missing functionality to Barbican 
has absolutely nothing to do with the Big Tent:


There's no competing secret storage project in OpenStack other than 
Barbican/Castellan.


Furthermore, this behaviour of projects choosing to DIY/NIH something 
that existed in other projects was around long before the advent of the 
Big Tent. In fact, in this specific case, the Magnum team knew about 
Barbican, previously depended on it, and chose to make Barbican an 
option not because Barbican wasn't OpenStack -- it absolutely WAS -- but 
because it wasn't commonly deployed, which limited their own adoption.


What you are asking for, Kevin, is a single opinionated and consolidated 
OpenStack deployment; a single OpenStack "product" if you will. This is 
a perfectly valid request. However it has nothing to do with the Big 
Tent governance reform.


Best,
-jay

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fei Long Wang]

On 17/01/17 10:09, Fox, Kevin M wrote:
> If the developers that had issue with the lack of functionality, contributed 
> to Barbican rather then go off on their own, the problem would have been 
> solved much more quickly. The lack of sharing means the problems don't get 
> fixed as fast.
>
> As for operators, If the more common projects all started depending on it, it 
> would be commonly deployed. Would the operators deploy Barbican just for 
> Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely . 
> Would they deploy it if Neutron and Keystone depended on it, yeah. they would.

IMHO, I think one of reasons is some projects just care the projects
themselves. They don't want to add any any dependency for the other
projects if they can. Though we know we should think this from higher
level, which can finally benefit OpenStack.  In other words, we only
care about if the project I'm working on can be adopted more widely. We
don't think this from the whole community's view. Big tent is making
things worse from this point of view. Most of the new non-core services
want more adoption, so any thing may impact their adoptions will be
removed from the list. As for core service, anything may impact their
existing positions will be removed from the list. It maybe correct from
the project's view, but it's not good from the OpenStack's view. For
example, if Nova or Neutron need a secret store, what are they going to
do? I'm sure Barbican will be a soft dep, just like Magnum did.

We're fear to let the projects end up depending on each other. I don't
think integration is wrong if the integration is made for good reasons.

> And then all the other projects would benefit from it being there, such as 
> Magnum. The sooner OpenStack as a whole can decide on some new core 
> components so that projects can start hard depending on them, the better I 
> think. That process kind of stopped with the arrival of the big tent.
>
> Thanks,
> Kevin
>
> 
> From: Adrian Otto [adrian.o...@rackspace.com]
> Sent: Monday, January 16, 2017 11:55 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
>> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <dmcco...@cisco.com> 
>> wrote:
>>
>> On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
>>
>>> -Original Message-
>>> From: Rob C <hyaku...@gmail.com>
>>> Reply: OpenStack Development Mailing List (not for usage questions)
>>> <openstack-dev@lists.openstack.org>
>>> Date: January 16, 2017 at 10:33:20
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> <openstack-dev@lists.openstack.org>
>>> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>>> projects trying to avoid Barbican, still?
>>>
>>>> Thanks for raising this on the mailing list Ian, I too share some of
>>>> your consternation regarding this issue.
>>>>
>>>> I think the main point has already been hit on, developers don't want to
>>>> require that Barbican be deployed in order for their service to be
>>>> used.
>>>>
>>>> The resulting spread of badly audited secret management code is pretty
>>>> ugly and makes certifying OpenStack for some types of operation very
>>>> difficult, simply listing where key management "happens" and what
>>>> protocols are in use quickly becomes a non-trivial operation with some
>>>> teams using hard coded values while others use configurable algorithms
>>>> and no connection between any of them.
>>>>
>>>> In some ways I think that the castellan project was supposed to help
>>>> address the issue. The castellan documentation[1] is a little sparse but
>>>> my understanding is that it exists as an abstraction layer for
>>>> key management, such that a service can just be set to use castellan,
>>>> which in turn can be told to use either a local key-manager, provided by
>>>> the project or Barbican when it is available.
>>>>
>>>> Perhaps a miss-step previously was that Barbican made no efforts to
>>>> really provide a robust non-HSM mode of operation. An obvious contrast
>>>> here is with Hashicorp Vault[2] which has garnered significant market
>>>> share in key management because it's software-only* mode of operation is
>>>> well documented, robust and cryptographically sound. I think that the
>>>>

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Lingxian Kong]

On Tue, Jan 17, 2017 at 10:09 AM, Fox, Kevin M  wrote:

> As for operators, If the more common projects all started depending on it,
> it would be commonly deployed. Would the operators deploy Barbican just for
> Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely .
> Would they deploy it if Neutron and Keystone depended on it, yeah. they
> would. And then all the other projects would benefit from it being there,
> such as Magnum.


Agree.

The problem is, was one project created just for being used together with
other OpenStack projects or it could be used perfectly in standalone mode?
There are a lot of projects nowadays in OpenStack besides the several most
important ones (Nova, Cinder, Neutron, Keystone, Glance, etc.). Most new
projects will say they can be used separately without necessarily in
OpenStack deployment, the question is, what are the advantages of the
project over the existing solutions? If the operators could get more
benefit by deploying and maintaining a new service than using a
pre-existing one?

>From my perspective (maybe I'm wrong), many projects are struggling in
OpenStack world, and at the same time, they are not that competitive with
solutions outside OpenStack world.

Just my $0.002



Cheers,
Lingxian Kong (Larry)
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fei Long Wang]

On 17/01/17 09:21, Fox, Kevin M wrote:
> IMO, This is why the big tent has been so damaging to OpenStack's progress. 
> Instead of lifting the commons up, by requiring dependencies on other 
> projects, there by making them commonly deployed and high quality, post big 
> tent, each project reimplements just enough to get away with making something 
> optional, and then the commons, and OpenStack as a whole suffers. This 
> behavior MUST STOP if OpenStack is to make progress again. Other projects, 
> such as Kubernetes are making tremendous progress because they are not 
> hamstrung by one component trying desperately not to depend on another when 
> the dependency is appropriate. They enhance the existing component until its 
> suitable and the whole project benefits. Yes, as an isolated dev, the 
> behavior to make deps optional seems to make sense. But as a whole, OpenStack 
> is suffering and will become increasingly irrelevant moving forward if the 
> current path is continued. Please, please reconsider what the current stance 
> on dependencies is doing to 
>  the community. This problem is not just isolated to barbican, but lots of 
> other projects as well. We can either help pull each other up, or we can step 
> on each other to try and get "on top". I'd rather we help each other rather 
> then the destructive path we seem to be on. 
+ 100

As the PTL of Zaqar, I know some projects using agent are reluctant to
leverage Zaqar to resolve potential security/communication issues. As a
result, customer/deployer don't want to deploy the project. So that
said, a new dependency may make the deployment harder, but sometimes
without the support/benefit from the other services, that project may
won't be on the list unless you reimplement the wheel.

> My 2 cents.
> Kevin
>
> 
> From: Chris Friesen [chris.frie...@windriver.com]
> Sent: Monday, January 16, 2017 9:25 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
> trying to avoid Barbican, still?
>
> On 01/16/2017 10:31 AM, Rob C wrote:
>
>> I think the main point has already been hit on, developers don't want to
>> require that Barbican be deployed in order for their service to be
>> used.
> I think that this is a perfectly reasonable stance for developers to take.  As
> long as Barbican is an optional component, then making your service depend on 
> it
> has a good chance of limiting your potential install base.
>
> Given that, it seems like the ideal model from a security perspective would be
> to use Barbican if it's available at runtime, otherwise use something 
> else...but
> that has development and maintenance costs.
>
> Chris
>
> __
> 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

-- 
Cheers & Best regards,
FeiLong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 



__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fox, Kevin M]

If the developers that had issue with the lack of functionality, contributed to 
Barbican rather then go off on their own, the problem would have been solved 
much more quickly. The lack of sharing means the problems don't get fixed as 
fast.

As for operators, If the more common projects all started depending on it, it 
would be commonly deployed. Would the operators deploy Barbican just for 
Magnum? maybe not. maybe so. For Magnum, Ironic, and Sahara, more likely . 
Would they deploy it if Neutron and Keystone depended on it, yeah. they would. 
And then all the other projects would benefit from it being there, such as 
Magnum. The sooner OpenStack as a whole can decide on some new core components 
so that projects can start hard depending on them, the better I think. That 
process kind of stopped with the arrival of the big tent.

Thanks,
Kevin


From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Monday, January 16, 2017 11:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
trying to avoid Barbican, still?

> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <dmcco...@cisco.com> 
> wrote:
>
> On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
>
>> -Original Message-
>> From: Rob C <hyaku...@gmail.com>
>> Reply: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Date: January 16, 2017 at 10:33:20
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>> projects trying to avoid Barbican, still?
>>
>>> Thanks for raising this on the mailing list Ian, I too share some of
>>> your consternation regarding this issue.
>>>
>>> I think the main point has already been hit on, developers don't want to
>>> require that Barbican be deployed in order for their service to be
>>> used.
>>>
>>> The resulting spread of badly audited secret management code is pretty
>>> ugly and makes certifying OpenStack for some types of operation very
>>> difficult, simply listing where key management "happens" and what
>>> protocols are in use quickly becomes a non-trivial operation with some
>>> teams using hard coded values while others use configurable algorithms
>>> and no connection between any of them.
>>>
>>> In some ways I think that the castellan project was supposed to help
>>> address the issue. The castellan documentation[1] is a little sparse but
>>> my understanding is that it exists as an abstraction layer for
>>> key management, such that a service can just be set to use castellan,
>>> which in turn can be told to use either a local key-manager, provided by
>>> the project or Barbican when it is available.
>>>
>>> Perhaps a miss-step previously was that Barbican made no efforts to
>>> really provide a robust non-HSM mode of operation. An obvious contrast
>>> here is with Hashicorp Vault[2] which has garnered significant market
>>> share in key management because it's software-only* mode of operation is
>>> well documented, robust and cryptographically sound. I think that the
>>> lack of a sane non-HSM mode, has resulted in developers trying to create
>>> their own and contributed to the situation.

Bingo!

>>> I'd be interested to know if development teams would be less concerned
>>> about requiring Barbican deployments, if it had a robust non-HSM
>>> (i.e software only) mode of operation. Lowering the cost of deployment
>>> for organisations that want sensible key management without the expense
>>> of deploying multi-site HSMs.
>>>
>>> * Vault supports HSM deployments also
>>>
>>> [1] http://docs.openstack.org/developer/castellan/
>>> [2] https://www.vaultproject.io/
>>
>> The last I checked, Rob, they also support DogTag IPA which is purely
>> a Software based HSM. Hopefully the Barbican team can confirm this.
>> --
>> Ian Cordasco
>
> Yep.  Barbican supports four backend secret stores. [1]
>
> The first (Simple Crypto) is easy to deploy, but not extraordinarily
> secure, since the secrets are encrypted using a static key defined in the
> barbican.conf file.
>
> The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> a hardware base to encrypt and/or store the secrets.
> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
>

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ade Lee]

Seems to me that there are two different audiences here.

Developers want something that is easy to set up and develop against.
For that, the simple crypto plugin is provided, and it requires
essentially no setup.

In case Barbican is not available, developers should be coding against
castellan.

Deployers want something relatively simple and secure.  This could be
an HSM, or it could be Dogtag (which can be configured to store secrets
in either an HSM or in a software based HSM).

There seems to be a misconception that Dogtag is hard to deploy.  That
may have been the case in the past, but there have been great strides
that have been made to make Dogtag deployment easier.  We now have
puppet scripts etc.

In Barcelona, for example, we held a couple of workshops where Barbican
was deployed by over a hundred people using Dogtag.  The installation
scripts (which took about 10 minutes to run) can be found here:  
https://github.com/cloudkeep/barbican-workshop

And yes, Dogtag is not a simple python app. But it has been
successfully deployed behind thousands of FreeIPA installations in HA
and non-HA modes, with minimal maintenance.

This is not to say that something like a Vault back-end should not be
developed.  It absolutely should.  But we should note that any real
secure back-end is going to require some investment of time/
understanding on the deployer's side for maintenance or for setting up
HA.  And Dogtag is not as bad as it is sometimes made out to be.


Its not without its warts though, and I'll be happy to work with anyone
who has trouble with it.
 
Ade

On Mon, 2017-01-16 at 10:50 -0800, Ian Cordasco wrote:
> -Original Message-
> From: Chris Friesen <chris.frie...@windriver.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: January 16, 2017 at 11:26:41
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.
> org>
> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
> projects trying to avoid Barbican, still?
> 
> > 
> > On 01/16/2017 10:31 AM, Rob C wrote:
> > 
> > > 
> > > I think the main point has already been hit on, developers don't
> > > want to
> > > require that Barbican be deployed in order for their service to
> > > be
> > > used.
> > 
> > I think that this is a perfectly reasonable stance for developers
> > to take. As
> > long as Barbican is an optional component, then making your service
> > depend on it
> > has a good chance of limiting your potential install base.
> > 
> > Given that, it seems like the ideal model from a security
> > perspective would be
> > to use Barbican if it's available at runtime, otherwise use
> > something else...but
> > that has development and maintenance costs.
> 
> More seriously it requires developers who aren't familiar with
> securely storing that kind of data re-implement exactly what Barbican
> has done, potentially.
> 
> Being realistic, and not to discount anyone's willingness to try, but
> I think the largest group of people qualified to build, review, and
> maintain that kind of software would be the Barbican team.
> 
> I guess the question then becomes: How many operators would be
> willing
> to deploy Barbican versus having to update each service as
> vulnerabilities are found, disclosed, and fixed in their clouds. If
> Barbican is as difficult to deploy as Rob is suggesting (that even
> DogTag is difficult to deploy) maybe developers should be focusing on
> fixing that instead of haphazardly reimplementing Barbican?
> 
> --
> Ian Cordasco
> 
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Fox, Kevin M]

IMO, This is why the big tent has been so damaging to OpenStack's progress. 
Instead of lifting the commons up, by requiring dependencies on other projects, 
there by making them commonly deployed and high quality, post big tent, each 
project reimplements just enough to get away with making something optional, 
and then the commons, and OpenStack as a whole suffers. This behavior MUST STOP 
if OpenStack is to make progress again. Other projects, such as Kubernetes are 
making tremendous progress because they are not hamstrung by one component 
trying desperately not to depend on another when the dependency is appropriate. 
They enhance the existing component until its suitable and the whole project 
benefits. Yes, as an isolated dev, the behavior to make deps optional seems to 
make sense. But as a whole, OpenStack is suffering and will become increasingly 
irrelevant moving forward if the current path is continued. Please, please 
reconsider what the current stance on dependencies is doing to 
 the community. This problem is not just isolated to barbican, but lots of 
other projects as well. We can either help pull each other up, or we can step 
on each other to try and get "on top". I'd rather we help each other rather 
then the destructive path we seem to be on.

My 2 cents.
Kevin


From: Chris Friesen [chris.frie...@windriver.com]
Sent: Monday, January 16, 2017 9:25 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [barbican] [security] Why are projects 
trying to avoid Barbican, still?

On 01/16/2017 10:31 AM, Rob C wrote:

> I think the main point has already been hit on, developers don't want to
> require that Barbican be deployed in order for their service to be
> used.

I think that this is a perfectly reasonable stance for developers to take.  As
long as Barbican is an optional component, then making your service depend on it
has a good chance of limiting your potential install base.

Given that, it seems like the ideal model from a security perspective would be
to use Barbican if it's available at runtime, otherwise use something else...but
that has development and maintenance costs.

Chris

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Adam Harwell]

Someone mentioned Castellan, and was exactly correct -- Castellan is
supposed to allow for flexibility, so developers can code for the Castellan
interface and simply configure it to use Barbican or whatever else they
want.

The only drawback of Castellan at the moment is that it doesn't directly
support certificate storage (that is, if you are using groupings of
cert/intermediates/PK, they have to be stored individually). Otherwise,
using that interface would make it very easy to allow use of Barbican for
any clouds that deploy it, and something else (maybe even a *common*
something simple) otherwise (though I am fully behind just using Barbican).

   --Adam Harwell (LBaaS/Octavia)

On Mon, Jan 16, 2017, 11:57 Adrian Otto <adrian.o...@rackspace.com> wrote:

>
> > On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <
> dmcco...@cisco.com> wrote:
> >
> > On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
> >
> >> -Original Message-
> >> From: Rob C <hyaku...@gmail.com>
> >> Reply: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Date: January 16, 2017 at 10:33:20
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> <openstack-dev@lists.openstack.org>
> >> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
> >> projects trying to avoid Barbican, still?
> >>
> >>> Thanks for raising this on the mailing list Ian, I too share some of
> >>> your consternation regarding this issue.
> >>>
> >>> I think the main point has already been hit on, developers don't want
> to
> >>> require that Barbican be deployed in order for their service to be
> >>> used.
> >>>
> >>> The resulting spread of badly audited secret management code is pretty
> >>> ugly and makes certifying OpenStack for some types of operation very
> >>> difficult, simply listing where key management "happens" and what
> >>> protocols are in use quickly becomes a non-trivial operation with some
> >>> teams using hard coded values while others use configurable algorithms
> >>> and no connection between any of them.
> >>>
> >>> In some ways I think that the castellan project was supposed to help
> >>> address the issue. The castellan documentation[1] is a little sparse
> but
> >>> my understanding is that it exists as an abstraction layer for
> >>> key management, such that a service can just be set to use castellan,
> >>> which in turn can be told to use either a local key-manager, provided
> by
> >>> the project or Barbican when it is available.
> >>>
> >>> Perhaps a miss-step previously was that Barbican made no efforts to
> >>> really provide a robust non-HSM mode of operation. An obvious contrast
> >>> here is with Hashicorp Vault[2] which has garnered significant market
> >>> share in key management because it's software-only* mode of operation
> is
> >>> well documented, robust and cryptographically sound. I think that the
> >>> lack of a sane non-HSM mode, has resulted in developers trying to
> create
> >>> their own and contributed to the situation.
>
> Bingo!
>
> >>> I'd be interested to know if development teams would be less concerned
> >>> about requiring Barbican deployments, if it had a robust non-HSM
> >>> (i.e software only) mode of operation. Lowering the cost of deployment
> >>> for organisations that want sensible key management without the expense
> >>> of deploying multi-site HSMs.
> >>>
> >>> * Vault supports HSM deployments also
> >>>
> >>> [1] http://docs.openstack.org/developer/castellan/
> >>> [2] https://www.vaultproject.io/
> >>
> >> The last I checked, Rob, they also support DogTag IPA which is purely
> >> a Software based HSM. Hopefully the Barbican team can confirm this.
> >> --
> >> Ian Cordasco
> >
> > Yep.  Barbican supports four backend secret stores. [1]
> >
> > The first (Simple Crypto) is easy to deploy, but not extraordinarily
> > secure, since the secrets are encrypted using a static key defined in the
> > barbican.conf file.
> >
> > The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> > a hardware base to encrypt and/or store the secrets.
> > The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
> &

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Dave McCowan (dmccowan) <dmcco...@cisco.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 13:03:41
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?
> Yep. Barbican supports four backend secret stores. [1]
>
> The first (Simple Crypto) is easy to deploy, but not extraordinarily
> secure, since the secrets are encrypted using a static key defined in the
> barbican.conf file.
>
> The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> a hardware base to encrypt and/or store the secrets.
> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
> encrypt and store the secrets.
>
> We do not currently have a secret store that is both highly secure and
> easy to deploy/manage.
>
> We, the Barbican community, are very open to any ideas, blueprints, or
> patches on how to achieve this.
> In any of the homegrown per-project secret stores, has a solution been
> developed that solves both of these?
>
>
> [1]
> http://docs.openstack.org/project-install-guide/key-manager/draft/barbican-
> backend.html

So there seems to be a consensus that Vault is a good easy and secure
solution to deploy. Can Barbican use that as a backend secret store?

--
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Adrian Otto]

> On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) <dmcco...@cisco.com> 
> wrote:
> 
> On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:
> 
>> -Original Message-
>> From: Rob C <hyaku...@gmail.com>
>> Reply: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Date: January 16, 2017 at 10:33:20
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>> projects trying to avoid Barbican, still?
>> 
>>> Thanks for raising this on the mailing list Ian, I too share some of
>>> your consternation regarding this issue.
>>> 
>>> I think the main point has already been hit on, developers don't want to
>>> require that Barbican be deployed in order for their service to be
>>> used.
>>> 
>>> The resulting spread of badly audited secret management code is pretty
>>> ugly and makes certifying OpenStack for some types of operation very
>>> difficult, simply listing where key management "happens" and what
>>> protocols are in use quickly becomes a non-trivial operation with some
>>> teams using hard coded values while others use configurable algorithms
>>> and no connection between any of them.
>>> 
>>> In some ways I think that the castellan project was supposed to help
>>> address the issue. The castellan documentation[1] is a little sparse but
>>> my understanding is that it exists as an abstraction layer for
>>> key management, such that a service can just be set to use castellan,
>>> which in turn can be told to use either a local key-manager, provided by
>>> the project or Barbican when it is available.
>>> 
>>> Perhaps a miss-step previously was that Barbican made no efforts to
>>> really provide a robust non-HSM mode of operation. An obvious contrast
>>> here is with Hashicorp Vault[2] which has garnered significant market
>>> share in key management because it's software-only* mode of operation is
>>> well documented, robust and cryptographically sound. I think that the
>>> lack of a sane non-HSM mode, has resulted in developers trying to create
>>> their own and contributed to the situation.

Bingo!

>>> I'd be interested to know if development teams would be less concerned
>>> about requiring Barbican deployments, if it had a robust non-HSM
>>> (i.e software only) mode of operation. Lowering the cost of deployment
>>> for organisations that want sensible key management without the expense
>>> of deploying multi-site HSMs.
>>> 
>>> * Vault supports HSM deployments also
>>> 
>>> [1] http://docs.openstack.org/developer/castellan/
>>> [2] https://www.vaultproject.io/
>> 
>> The last I checked, Rob, they also support DogTag IPA which is purely
>> a Software based HSM. Hopefully the Barbican team can confirm this.
>> --
>> Ian Cordasco
> 
> Yep.  Barbican supports four backend secret stores. [1]
> 
> The first (Simple Crypto) is easy to deploy, but not extraordinarily
> secure, since the secrets are encrypted using a static key defined in the
> barbican.conf file.
> 
> The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
> a hardware base to encrypt and/or store the secrets.
> The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
> encrypt and store the secrets.
> 
> We do not currently have a secret store that is both highly secure and
> easy to deploy/manage.
> 
> We, the Barbican community, are very open to any ideas, blueprints, or
> patches on how to achieve this.
> In any of the homegrown per-project secret stores, has a solution been
> developed that solves both of these?
> 
> 
> [1] 
> http://docs.openstack.org/project-install-guide/key-manager/draft/barbican-
> backend.html

The above list of four backend secret stores, each with serious drawbacks is 
the reason why Barbican has not been widely adopted. Other projects are 
reluctant to depend on Barbican because it’s not present in most clouds. 
Magnum, for example believed that using Barbican for certificate storage was 
the correct design, and we implemented our solution such that it required 
Barbican. We quickly discovered that it was hurting Magnum’s adoption by 
multiple cloud operators that were reluctant to add the Barbican service in 
order to add Magnum. So, we built internal certificate storage to decouple 
Magnum from Barbican. It’s even les

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Dave McCowan (dmccowan)]

On 1/16/17, 11:52 AM, "Ian Cordasco" <sigmaviru...@gmail.com> wrote:

>-Original Message-
>From: Rob C <hyaku...@gmail.com>
>Reply: OpenStack Development Mailing List (not for usage questions)
><openstack-dev@lists.openstack.org>
>Date: January 16, 2017 at 10:33:20
>To: OpenStack Development Mailing List (not for usage questions)
><openstack-dev@lists.openstack.org>
>Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
>projects trying to avoid Barbican, still?
>
>> Thanks for raising this on the mailing list Ian, I too share some of
>> your consternation regarding this issue.
>>
>> I think the main point has already been hit on, developers don't want to
>> require that Barbican be deployed in order for their service to be
>> used.
>>
>> The resulting spread of badly audited secret management code is pretty
>> ugly and makes certifying OpenStack for some types of operation very
>> difficult, simply listing where key management "happens" and what
>> protocols are in use quickly becomes a non-trivial operation with some
>> teams using hard coded values while others use configurable algorithms
>> and no connection between any of them.
>>
>> In some ways I think that the castellan project was supposed to help
>> address the issue. The castellan documentation[1] is a little sparse but
>> my understanding is that it exists as an abstraction layer for
>> key management, such that a service can just be set to use castellan,
>> which in turn can be told to use either a local key-manager, provided by
>> the project or Barbican when it is available.
>>
>> Perhaps a miss-step previously was that Barbican made no efforts to
>> really provide a robust non-HSM mode of operation. An obvious contrast
>> here is with Hashicorp Vault[2] which has garnered significant market
>> share in key management because it's software-only* mode of operation is
>> well documented, robust and cryptographically sound. I think that the
>> lack of a sane non-HSM mode, has resulted in developers trying to create
>> their own and contributed to the situation.
>>
>> I'd be interested to know if development teams would be less concerned
>> about requiring Barbican deployments, if it had a robust non-HSM
>> (i.e software only) mode of operation. Lowering the cost of deployment
>> for organisations that want sensible key management without the expense
>> of deploying multi-site HSMs.
>>
>> * Vault supports HSM deployments also
>>
>> [1] http://docs.openstack.org/developer/castellan/
>> [2] https://www.vaultproject.io/
>
>The last I checked, Rob, they also support DogTag IPA which is purely
>a Software based HSM. Hopefully the Barbican team can confirm this.
>--
>Ian Cordasco

Yep.  Barbican supports four backend secret stores. [1]

The first (Simple Crypto) is easy to deploy, but not extraordinarily
secure, since the secrets are encrypted using a static key defined in the
barbican.conf file.

The second and third (PKCS#11 and KMIP) are secure, but require an HSM as
a hardware base to encrypt and/or store the secrets.
The fourth (Dogtag) is secure, but requires a deployment of Dogtag to
encrypt and store the secrets.

We do not currently have a secret store that is both highly secure and
easy to deploy/manage.

We, the Barbican community, are very open to any ideas, blueprints, or
patches on how to achieve this.
In any of the homegrown per-project secret stores, has a solution been
developed that solves both of these?


[1] 
http://docs.openstack.org/project-install-guide/key-manager/draft/barbican-
backend.html


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Chris Friesen <chris.frie...@windriver.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 11:26:41
To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 01/16/2017 10:31 AM, Rob C wrote:
>
> > I think the main point has already been hit on, developers don't want to
> > require that Barbican be deployed in order for their service to be
> > used.
>
> I think that this is a perfectly reasonable stance for developers to take. As
> long as Barbican is an optional component, then making your service depend on 
> it
> has a good chance of limiting your potential install base.
>
> Given that, it seems like the ideal model from a security perspective would be
> to use Barbican if it's available at runtime, otherwise use something 
> else...but
> that has development and maintenance costs.

More seriously it requires developers who aren't familiar with
securely storing that kind of data re-implement exactly what Barbican
has done, potentially.

Being realistic, and not to discount anyone's willingness to try, but
I think the largest group of people qualified to build, review, and
maintain that kind of software would be the Barbican team.

I guess the question then becomes: How many operators would be willing
to deploy Barbican versus having to update each service as
vulnerabilities are found, disclosed, and fixed in their clouds. If
Barbican is as difficult to deploy as Rob is suggesting (that even
DogTag is difficult to deploy) maybe developers should be focusing on
fixing that instead of haphazardly reimplementing Barbican?

--
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

>
>
> The last I checked, Rob, they also support DogTag IPA which is purely
> a Software based HSM. Hopefully the Barbican team can confirm this.
> --
> Ian Cordasco
>

Yup, that's my understanding too. However, that requires Barbican _and_
Dogtag, an even bigger overhead. Especially as at least historically
Dogtag has been difficult to maintain. If you have a deployment already,
there's a great synergy there. If you don't then it introduces a lot of
overhead.

I'm interested to know if an out of the box, stand alone software-only
version of Barbican would be any more appealing

Cheers
-Rob
__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Chris Friesen]

On 01/16/2017 10:31 AM, Rob C wrote:


I think the main point has already been hit on, developers don't want to
require that Barbican be deployed in order for their service to be
used.


I think that this is a perfectly reasonable stance for developers to take.  As 
long as Barbican is an optional component, then making your service depend on it 
has a good chance of limiting your potential install base.


Given that, it seems like the ideal model from a security perspective would be 
to use Barbican if it's available at runtime, otherwise use something else...but 
that has development and maintenance costs.


Chris

__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Rob C <hyaku...@gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 10:33:20
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> Thanks for raising this on the mailing list Ian, I too share some of
> your consternation regarding this issue.
>
> I think the main point has already been hit on, developers don't want to
> require that Barbican be deployed in order for their service to be
> used.
>
> The resulting spread of badly audited secret management code is pretty
> ugly and makes certifying OpenStack for some types of operation very
> difficult, simply listing where key management "happens" and what
> protocols are in use quickly becomes a non-trivial operation with some
> teams using hard coded values while others use configurable algorithms
> and no connection between any of them.
>
> In some ways I think that the castellan project was supposed to help
> address the issue. The castellan documentation[1] is a little sparse but
> my understanding is that it exists as an abstraction layer for
> key management, such that a service can just be set to use castellan,
> which in turn can be told to use either a local key-manager, provided by
> the project or Barbican when it is available.
>
> Perhaps a miss-step previously was that Barbican made no efforts to
> really provide a robust non-HSM mode of operation. An obvious contrast
> here is with Hashicorp Vault[2] which has garnered significant market
> share in key management because it's software-only* mode of operation is
> well documented, robust and cryptographically sound. I think that the
> lack of a sane non-HSM mode, has resulted in developers trying to create
> their own and contributed to the situation.
>
> I'd be interested to know if development teams would be less concerned
> about requiring Barbican deployments, if it had a robust non-HSM
> (i.e software only) mode of operation. Lowering the cost of deployment
> for organisations that want sensible key management without the expense
> of deploying multi-site HSMs.
>
> * Vault supports HSM deployments also
>
> [1] http://docs.openstack.org/developer/castellan/
> [2] https://www.vaultproject.io/

The last I checked, Rob, they also support DogTag IPA which is purely
a Software based HSM. Hopefully the Barbican team can confirm this.
--
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Rob C]

Thanks for raising this on the mailing list Ian, I too share some of
your consternation regarding this issue.

I think the main point has already been hit on, developers don't want to
require that Barbican be deployed in order for their service to be
used.

The resulting spread of badly audited secret management code is pretty
ugly and makes certifying OpenStack for some types of operation very
difficult, simply listing where key management "happens" and what
protocols are in use quickly becomes a non-trivial operation with some
teams using hard coded values while others use configurable algorithms
and no connection between any of them.

In some ways I think that the castellan project was supposed to help
address the issue. The castellan documentation[1] is a little sparse but
my understanding is that it exists as an abstraction layer for
key management, such that a service can just be set to use castellan,
which in turn can be told to use either a local key-manager, provided by
the project or Barbican when it is available.

Perhaps a miss-step previously was that Barbican made no efforts to
really provide a robust non-HSM mode of operation. An obvious contrast
here is with Hashicorp Vault[2] which has garnered significant market
share in key management because it's software-only* mode of operation is
well documented, robust and cryptographically sound. I think that the
lack of a sane non-HSM mode, has resulted in developers trying to create
their own and contributed to the situation.

I'd be interested to know if development teams would be less concerned
about requiring Barbican deployments, if it had a robust non-HSM
(i.e software only) mode of operation. Lowering the cost of deployment
for organisations that want sensible key management without the expense
of deploying multi-site HSMs.

* Vault supports HSM deployments also

[1] http://docs.openstack.org/developer/castellan/
[2] https://www.vaultproject.io/

On Mon, Jan 16, 2017 at 4:14 PM, Ian Cordasco <sigmaviru...@gmail.com>
wrote:

> -Original Message-
> From: Hayes, Graham <graham.ha...@hpe.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: January 16, 2017 at 09:26:00
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
> projects trying to avoid Barbican, still?
>
> > On 16/01/2017 13:38, Ian Cordasco wrote:
> > > Is the problem perhaps that no one is aware of other projects using
> > > Barbican? Is the status on the project navigator alarming (it looks
> > > like some of this information is potentially out of date)? Has
> > > Barbican been deemed too hard to deploy?
> >
> > I know that historically it was considered hard to do a HA deploy of
> > Barbican. When we initially evaluated DNSSEC in Designate (many years
> > ago now) it was one of the sticking points.
> >
> > This may have (and most likely has) changed, but we seem to have long
> > memories.
>
> I know Rackspace recently made Barbican available to its cloud
> customers. I suspect it's easier now to perform an HA deploy.
>
> > It could be a side effect of the Big Tent - there are so many projects
> > doing so many different things that projects don't want deployers to
> > have deploy everything.
>
> Yeah, I completely understand that. The thing is that in one case,
> there's a project that currently relies on Barbican and wants to
> replace that with a completely brand new service that will be doing
> other things and then wants to layer secrets on top of it. It seems to
> me like a terrible case of both scope creep and not actually caring
> about the security the users expect from services that have to
> interact with secrets. N services (besides Barbican) implementing
> their own secrets storage each in their own way seem like N different
> services that will be dealing with vulnerabilities and security
> releases for the next few years. Perhaps that's pessimistic, but
> looking at that with my operator hat on, I'd rather have to update *1*
> service (barbican) rather than N if there's some vulnerability that
> comes up. It's the same argument when it comes down to packaging and
> vendoring dependencies. Update once instead of N times for each
> package that has a copy of the library bundled in it.
>
> > > I really want to understand why so many projects feel the need to
> > > implement their own secrets storage. This seems a bit short-sighted
> > > and foolish. While these projects are making themselves easier to
> > > deploy, if not done properly they are potentially endangering their
> > > users and that seems lik

Re: [openstack-dev] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

-Original Message-
From: Hayes, Graham <graham.ha...@hpe.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: January 16, 2017 at 09:26:00
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [all] [barbican] [security] Why are
projects trying to avoid Barbican, still?

> On 16/01/2017 13:38, Ian Cordasco wrote:
> > Is the problem perhaps that no one is aware of other projects using
> > Barbican? Is the status on the project navigator alarming (it looks
> > like some of this information is potentially out of date)? Has
> > Barbican been deemed too hard to deploy?
>
> I know that historically it was considered hard to do a HA deploy of
> Barbican. When we initially evaluated DNSSEC in Designate (many years
> ago now) it was one of the sticking points.
>
> This may have (and most likely has) changed, but we seem to have long
> memories.

I know Rackspace recently made Barbican available to its cloud
customers. I suspect it's easier now to perform an HA deploy.

> It could be a side effect of the Big Tent - there are so many projects
> doing so many different things that projects don't want deployers to
> have deploy everything.

Yeah, I completely understand that. The thing is that in one case,
there's a project that currently relies on Barbican and wants to
replace that with a completely brand new service that will be doing
other things and then wants to layer secrets on top of it. It seems to
me like a terrible case of both scope creep and not actually caring
about the security the users expect from services that have to
interact with secrets. N services (besides Barbican) implementing
their own secrets storage each in their own way seem like N different
services that will be dealing with vulnerabilities and security
releases for the next few years. Perhaps that's pessimistic, but
looking at that with my operator hat on, I'd rather have to update *1*
service (barbican) rather than N if there's some vulnerability that
comes up. It's the same argument when it comes down to packaging and
vendoring dependencies. Update once instead of N times for each
package that has a copy of the library bundled in it.

> > I really want to understand why so many projects feel the need to
> > implement their own secrets storage. This seems a bit short-sighted
> > and foolish. While these projects are making themselves easier to
> > deploy, if not done properly they are potentially endangering their
> > users and that seems like a bigger problem than deploying Barbican to
> > me.
>
> +100 - One of the reasons we didn't just write our own signing was I
> am allergic to writing crypto code - I am not very good at it, and there
> is a project that people that either are, or know how to use the libs
> correctly.

I have the same allergy! This is why I've been pushing folks talking
about implementing their own secrets storage.

--
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Hayes, Graham]

On 16/01/2017 13:38, Ian Cordasco wrote:
> Hi everyone,
>
> I've seen a few nascent projects wanting to implement their own secret
> storage to either replace Barbican or avoid adding a dependency on it.
> When I've pressed the developers on this point, the only answer I've
> received is to make the operator's lives simpler.
>
> I've been struggling to understand the reasoning behind this and I'm
> wondering if there are more people around who can help me understand.
>
> To help others help me, let me provide my point of view. Barbican's
> been around for a few years already and has been deployed by several
> companies which have probably audited it for security purposes. Most
> of the technology involved in Barbican is proven to be secure and the
> way the project has strung those pieces together has been analyzed by
> the OSSP (OpenStack's own security group). It doesn't have a
> requirement on a hardware TPM which means there's no hardware upgrade
> cost. Furthermore, several services already provide the option of
> using Barbican (but won't place a hard requirement on it). It stands
> to reason (in my opinion) that if new services have a need for secrets
> and other services already support using Barbican as secret storage,
> then those new services should be using Barbican. It seems a bit
> short-sighted of its developers to say that their users are definitely
> not deploying Barbican when projects like Magnum have soft
> dependencies on it.
>
> Is the problem perhaps that no one is aware of other projects using
> Barbican? Is the status on the project navigator alarming (it looks
> like some of this information is potentially out of date)? Has
> Barbican been deemed too hard to deploy?

I know that historically it was considered hard to do a HA deploy of
Barbican. When we initially evaluated DNSSEC in Designate (many years
ago now) it was one of the sticking points.

This may have (and most likely has) changed, but we seem to have long
memories.

It could be a side effect of the Big Tent - there are so many projects
doing so many different things that projects don't want deployers to
have deploy everything.

> I really want to understand why so many projects feel the need to
> implement their own secrets storage. This seems a bit short-sighted
> and foolish. While these projects are making themselves easier to
> deploy, if not done properly they are potentially endangering their
> users and that seems like a bigger problem than deploying Barbican to
> me.

+100 - One of the reasons we didn't just write our own signing was I
am allergic to writing crypto code - I am not very good at it, and there
is a project that people that either are, or know how to use the libs
correctly.


__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Chris Dent]

On Mon, 16 Jan 2017, Ian Cordasco wrote:


I really want to understand why so many projects feel the need to
implement their own secrets storage. This seems a bit short-sighted
and foolish. While these projects are making themselves easier to
deploy, if not done properly they are potentially endangering their
users and that seems like a bigger problem than deploying Barbican to
me.


What I've heard in the past is that no one wants to rely on
something that they cannot guarantee will be present in a
deployment. The debate surrounding what ought to be guaranteed in a
deployment is part of what inspired the notion of a "base services"
which is a topic up for proposal in the architecture working group:

https://review.openstack.org/#/c/419397/

(In other words: yeah, important topic.)
--
Chris Dent ¯\_(ツ)_/¯   https://anticdent.org/
freenode: cdent tw: @anticdent__
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] [all] [barbican] [security] Why are projects trying to avoid Barbican, still?

[Ian Cordasco]

Hi everyone,

I've seen a few nascent projects wanting to implement their own secret
storage to either replace Barbican or avoid adding a dependency on it.
When I've pressed the developers on this point, the only answer I've
received is to make the operator's lives simpler.

I've been struggling to understand the reasoning behind this and I'm
wondering if there are more people around who can help me understand.

To help others help me, let me provide my point of view. Barbican's
been around for a few years already and has been deployed by several
companies which have probably audited it for security purposes. Most
of the technology involved in Barbican is proven to be secure and the
way the project has strung those pieces together has been analyzed by
the OSSP (OpenStack's own security group). It doesn't have a
requirement on a hardware TPM which means there's no hardware upgrade
cost. Furthermore, several services already provide the option of
using Barbican (but won't place a hard requirement on it). It stands
to reason (in my opinion) that if new services have a need for secrets
and other services already support using Barbican as secret storage,
then those new services should be using Barbican. It seems a bit
short-sighted of its developers to say that their users are definitely
not deploying Barbican when projects like Magnum have soft
dependencies on it.

Is the problem perhaps that no one is aware of other projects using
Barbican? Is the status on the project navigator alarming (it looks
like some of this information is potentially out of date)? Has
Barbican been deemed too hard to deploy?

I really want to understand why so many projects feel the need to
implement their own secrets storage. This seems a bit short-sighted
and foolish. While these projects are making themselves easier to
deploy, if not done properly they are potentially endangering their
users and that seems like a bigger problem than deploying Barbican to
me.

-- 
Ian Cordasco
Glance, Hacking, Bandit, and Craton core reviewer

__
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