settingsLogin | Registersettings

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

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jan 18, 2017 in openstack-dev by sigmavirus24_at_gmai (8,720 points)   1 2 3

58 Responses

0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

responded Jan 16, 2017 by cdent_plus_os_at_ant (12,800 points)   2 2 4
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by graham.hayes_at_hpe. (6,780 points)   1 2 2
0 votes

-----Original Message-----
From: Hayes, Graham graham.hayes@hpe.com
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 16, 2017 at 09:26:00
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 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by sigmavirus24_at_gmai (8,720 points)   1 2 3
0 votes

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 sigmavirus24@gmail.com
wrote:

-----Original Message-----
From: Hayes, Graham graham.hayes@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by Rob_C (1,240 points)   1
0 votes

-----Original Message-----
From: Rob C hyakuhei@gmail.com
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 16, 2017 at 10:33:20
To: OpenStack Development Mailing List (not for usage questions)

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by sigmavirus24_at_gmai (8,720 points)   1 2 3
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by Chris_Friesen (20,420 points)   3 14 24
0 votes

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by Rob_C (1,240 points)   1
0 votes

-----Original Message-----
From: Chris Friesen chris.friesen@windriver.com
Reply: OpenStack Development Mailing List (not for usage questions)

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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by sigmavirus24_at_gmai (8,720 points)   1 2 3
0 votes

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

-----Original Message-----
From: Rob C hyakuhei@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by Dave_McCowan_(dmccow (1,500 points)   1
0 votes

On Jan 16, 2017, at 11:02 AM, Dave McCowan (dmccowan) dmccowan@cisco.com wrote:

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

-----Original Message-----
From: Rob C hyakuhei@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 less secure than using Barbican with Simple Crypto, but it solved our adoption problem. Furthermore, that’s how most clouds are using Magnum, because they still don’t run Barbican.

Bottom line: As long as cloud operators have any reluctance to adopt Barbican, other community projects will avoid depending on it, even when it’s the right technical solution.

Regards,

Adrian


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 16, 2017 by Adrian_Otto (11,060 points)   2 3 6
...