Re: [openstack-dev] [barbican][tc] Seeking feedback on the OpenStack cloud vision

[Dave McCowan (dmccowan)]

Hello Zane--
   Yes, this vision is consistent with the Barbican team's vision.

   Barbican provides an abstraction layer over HSMs and other secret
storage services.  We have a plugin architecture to enable this
abstraction over a variety of backends.  Vault is a recent addition to our
supported options.  Barbican uses Keystone for authentication and
oslo.policy for RBAC, which allows for multi-tenancy and makes secret
storage consistent with other OpenStack services.

   The topic of cross-project dependencies is one we've been wrestling
with for a while.  At the Pike PTG[1], we had discussions with the
Architecture Working Group on how to address this.  We concluded that the
cross-project requirement should not be on Barbican, but on a "Castellan
compatible secret store".  At the time, Barbican was the only choice, but
we wanted to encourage new development.

  We shifted ownership of Castellan (a python key manager abstraction
layer) from the Barbican team to the Oslo team.  The idea was that people
would write Castellan plugins for key managers other than Barbican.  Later
that year, a Castellan plugin for Vault was contributed.[2]  At this time,
the direct-to-vault plugin does not use Keystone for authentication or
oslo.policy for RBAC.  Users can configure the Barbican-to-Vault
architecture if they need to meet those requirements.
   
tl;dr: This vision looks good.  The Castellan and Barbican software
provides abstraction for either the key storage or the key manager, so the
cross project dependency can be "a key manager", instead of specifically
Barbican.

--Dave


[1] https://etherpad.openstack.org/p/barbican-pike-ptg-barbican-discussion
[2] https://review.openstack.org/#/c/483080/


On 10/24/18, 11:16 AM, "Zane Bitter"  wrote:

>Greetings, Barbican team!
>As you may be aware, I've been working with other folks in the community
>on documenting a vision for OpenStack clouds (formerly known as the
>'Technical Vision') - essentially to interpret the mission statement in
>long-form, in a way that we can use to actually help guide decisions.
>You can read the latest draft here: https://review.openstack.org/592205
>
>We're trying to get feedback from as many people as possible - in many
>ways the value is in the process of coming together to figure out what
>we're trying to achieve as a community with OpenStack and how we can
>work together to build it. The document is there to help us remember
>what we decided so we don't have to do it all again over and over.
>
>The vision is structured with two sections that apply broadly to every
>project in OpenStack - describing the principles that we believe are
>essential to every cloud, and the ones that make OpenStack different
>from some other clouds. The third section is a list of design goals that
>we want OpenStack as a whole to be able to meet - ideally each project
>would be contributing toward one or more of these design goals.
>
>Barbican provides an abstraction over HSMs and software equivalents
>(like Vault), so the immediate design goal that it meets is the
>'Hardware Virtualisation' one. However, the most interesting part of the
>document for the Barbican team is probably the section on cross-project
>dependencies. In discussions at the PTG, the TC concluded that we
>shouldn't force projects to adopt hard dependencies on other services
>(like Barbican), but recommend that they do so when there is a benefit
>to the user. The challenge here I think is that not duplicating
>security-sensitive code such as secret storage is well known to be
>something that is both of great benefit to the user and highly tempting
>to take a shortcut on. Your feedback on whether we have got the right
>balance is important.
>
>If you would like me or another TC member to join one of your team IRC
>meetings to discuss further what the vision means for your team, please
>reply to this thread to set it up. You are also welcome to bring up any
>questions in the TC IRC channel, #openstack-tc - there's more of us
>around during Office Hours
>(https://governance.openstack.org/tc/#office-hours), but you can talk to
>us at any time.
>
>Feedback can also happen either in this thread or on the review
>https://review.openstack.org/592205
>
>If the team is generally happy with the vision as it is and doesn't have
>any specific feedback, that's cool but I'd like to request that at least
>the PTL leave a vote on the review. It's important to know whether we
>are actually developing a consensus in the community or just talking to
>ourselves :)
>
>many thanks,
>Zane.
>
>__
>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)

Re: [openstack-dev] [barbican] NEW weekly meeting time

[Dave McCowan (dmccowan)]

+1
This is a great time.

On 6/14/18, 4:30 PM, "Ade Lee"  wrote:

>The new time slot has been pretty difficult for folks to attend.
>I'd like to propose a new time slot, which will hopefully be more
>amenable to everyone.
>
>Tuesday 12:00 UTC
>
>https://www.timeanddate.com/worldclock/fixedtime.html?hour=12=00
>c=0
>
>This works out to 8 am EST, around 1pm in Europe, and 8 pm in China.
>Please vote by responding to this email.
>
>Thanks,
>Ade
>
>__
>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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Dave McCowan (dmccowan)]

On 12/12/17, 3:15 PM, "Doug Hellmann" <d...@doughellmann.com> wrote:

>Excerpts from Dave McCowan (dmccowan)'s message of 2017-12-12 19:56:49
>+:
>> 
>> On 12/12/17, 10:38 AM, "Doug Hellmann" <d...@doughellmann.com> wrote:
>> 
>> >
>> >> On Dec 12, 2017, at 9:42 AM, Paul Bourke <paul.bou...@oracle.com>
>>wrote:
>> >> 
>> >> From my understanding it would be a cleanup operation - which to be
>> >>honest, would be very much welcomed. I recently did a little work with
>> >>Castellan to integrate it with Murano and found the auth code to be
>>very
>> >>messy, and flat out broken in some cases. If it's possible to let the
>> >>barbican client take care of this that sounds good to me.
>> >> 
>> >> > Which mode is used the most in the services that consume castellan
>> >> > today?
>> >> 
>> >> Afaik Barbican is the only backend that currently exists in Castellan
>> >>[0]. Looking again it seems some support has been added for vault
>>which
>> >>is great, but I reckon Barbican would still be the primary use.
>> >> 
>> >> I haven't been hugely active in Castellan but if the team would like
>> >>some more input on this or reviews please do ping me, I'd be glad to
>> >>help.
>> >
>> >What I mean is, in the services consuming Castellan, how do they expect
>> >it to authenticate to Barbican? As the current user or as a hard-coded
>> >fixed user controlled by the deployer? I would think most services
>>would
>> >need to connect as the ³current² user talking to them so they can
>>access
>> >that user¹s secrets from Barbican. Removing the keystoneauth stuff from
>> >the driver would therefore break all of those applications.
>> >
>> >Doug
>> 
>> We're a mix right now.  Nova and Cinder pass through the a user's token
>>to
>> retrieve the user's key for encrypted volumes.  Octavia uses its service
>> account to retrieve certificates for load balancing TLS connections.
>> Users must grant Octavia read permissions in advance.
>
>OK, so it sounds like we do need to continue to support both
>approaches to authentication.
>
>> Keystone is currently the only authentication option for Barbican.  I
>> believe the proposal to decouple keystoneauth is advance work for adding
>> new auth methods and backends as future work.  Vault and Custodia are
>>two
>> such backends in progress.  They don't support keystoneauth and likely
>> won't, so we'll need alternatives.
>
>Each driver manages its own authentication, right? Why do we need to
>remove the keystoneauth stuff in the barbican driver in order to enable
>other drivers?

I would use the word "decouple", with the intent to give the option of
using Castellan without having a dependency on keystoneauth.  But, I don't
want to speak for original posters who used the word "remove" in case they
have other ideas.

Until recently Barbican was the only secret store and Keystone was the
only authentication service, so we didn't have to sort through the
modularity.


>
>> 
>> Reviews and contributions to Castellan and Barbican have been light over
>> the last cycle, while deployment interest and feature requests have been
>> high.  Any help will be appreciated!
>> 
>> --Dave
>> 

__
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] [castellan] Removing Keystoneauth Dependency in Castellan Discussion

[Dave McCowan (dmccowan)]

On 12/12/17, 10:38 AM, "Doug Hellmann"  wrote:

>
>> On Dec 12, 2017, at 9:42 AM, Paul Bourke  wrote:
>> 
>> From my understanding it would be a cleanup operation - which to be
>>honest, would be very much welcomed. I recently did a little work with
>>Castellan to integrate it with Murano and found the auth code to be very
>>messy, and flat out broken in some cases. If it's possible to let the
>>barbican client take care of this that sounds good to me.
>> 
>> > Which mode is used the most in the services that consume castellan
>> > today?
>> 
>> Afaik Barbican is the only backend that currently exists in Castellan
>>[0]. Looking again it seems some support has been added for vault which
>>is great, but I reckon Barbican would still be the primary use.
>> 
>> I haven't been hugely active in Castellan but if the team would like
>>some more input on this or reviews please do ping me, I'd be glad to
>>help.
>
>What I mean is, in the services consuming Castellan, how do they expect
>it to authenticate to Barbican? As the current user or as a hard-coded
>fixed user controlled by the deployer? I would think most services would
>need to connect as the ³current² user talking to them so they can access
>that user¹s secrets from Barbican. Removing the keystoneauth stuff from
>the driver would therefore break all of those applications.
>
>Doug

We're a mix right now.  Nova and Cinder pass through the a user's token to
retrieve the user's key for encrypted volumes.  Octavia uses its service
account to retrieve certificates for load balancing TLS connections.
Users must grant Octavia read permissions in advance.

Keystone is currently the only authentication option for Barbican.  I
believe the proposal to decouple keystoneauth is advance work for adding
new auth methods and backends as future work.  Vault and Custodia are two
such backends in progress.  They don't support keystoneauth and likely
won't, so we'll need alternatives.

Reviews and contributions to Castellan and Barbican have been light over
the last cycle, while deployment interest and feature requests have been
high.  Any help will be appreciated!

--Dave


__
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] [barbican][nova][cinder][tacker][glance] Remove Certificate Orders and CAs from API

[Dave McCowan (dmccowan)]

On 12/5/17, 11:37 AM, "Matt Riedemann"  wrote:

>On 12/5/2017 2:52 AM, na...@vn.fujitsu.com wrote:
>> Hi all,
>> 
>> Barbican's team are considering whether the Certificate Orders and CAs
>>should be removed or not [1]. And we would like to hear information from
>>other projects. If you are using this feature for your project, please
>>raise your hand. We will discuss about this.
>> 
>> [1] https://review.openstack.org/#/c/462363/
>> 
>
>I see Peter Hamilton is +1 on this so I assume Nova is fine with it.
>
>As an outsider to Barbican, just reading the commit message I don't
>really have any idea *why* this removal is happening; there is no link
>to background discussion or a summary of whatever discussion has
>happened, or if this is part of a larger series of changes to remove
>support for a feature from the REST API - nor a release note. So you
>might want to think about that from a discoverability / posterity point
>of view.
>
>-- 
>
>Thanks,
>
>Matt

We originally announced deprecation of the CA features from Barbican in
September 2016 [1], following lots of community discussion and input.
Barbican currently emits a warning if a CA feature is configured.  In this
patch, we're finalizing the process by removing the code.

I agree we need to get a better explanation into the release notes and
documentation to document for history.

Thanks!
--Dave

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103793.ht
ml


__
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] [ptls] MOAR UPDATES: Sydney Project Onboarding

[Dave McCowan (dmccowan)]

We're working on the Barbican Onboarding session now.  I don't think our Boston 
session went very well, and the results borne out; we were unable to convert 
any attendee to active contributor.  It was a much bigger group than I was 
expecting and everyone was at a different starting point .  I was unprepared 
for both of those situations.

I'd like to hear some success stories from Boston to learn from.

For projects that were successful, what topics did you cover?
For prospective Sydney Onboarders, what do you want to learn at these sessions?

Thanks!
dave-mccowan

From: Kendall Nelson >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, October 23, 2017 at 7:09 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [ptls] MOAR UPDATES: Sydney Project Onboarding

Hello Everyone :)

Everyone that has requested a slot has been added to the official schedule[1].

If conflicts arise with other talks you have or you want to add more 
presenters, please contact 
speakersupp...@openstack.org. They can get 
any issues with the schedule resolved.

We do still have spots available. If you have not yet signed up, please let me 
know immediately and I can add you to one of the available slots.

Thank you everyone! I hope you all get a good group of new contributors!

-Kendall Nelson (diablo_rojo)

[1] 
https://www.openstack.org/summit/sydney-2017/summit-schedule/global-search?t=project+onboarding
__
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] [cinder][nova][castellan] Toward deprecating ConfKeyManager

[Dave McCowan (dmccowan)]

Hi Alan--
Since a fixed-key implementation is not secure, I would prefer not adding 
it to Castellan.  Our desire is that Castellan can be a best-practice project 
to encourage operators to use key management securely.
I'm all for consolidating code and providing good migration paths from 
ConfKeyManager to Castellan.
Can we create a new oslo project to facilitate this?  Something like 
oslo.fixed_key_manager.
I would rather keep a fixed_key implementation out of Castellan if possible.
--Dave

There is an ongoing effort to deprecate the ConfKeyManager, but care
must be taken when migrating existing ConfKeyManager deployments to
Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,
but the process of switching from one key manager to another will need
to be done smoothly to ensure encrypted volumes continue to function
during the migration period.

One thing that will help the migration process is consolidating the
two ConfKeyManager implementations (one in Cinder and one in Nova).
The two are functionally identical, as dictated by the need to derive
the exact same secret from the fixed_key. While it may seem counter-
intuitive, adding a ConfKeyManager implementation to Castellan will
facilitate the process of deprecating them in Cinder and Nova.

To that end, I identified a series of small steps to get us there:

1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova
so they are identical (right now their help texts are slightly
different). This step avoids triggering a DuplicateOptError exception
in the next step.

2) Add a ConfKeyManager implementation to Castellan. This essentially
involves copying in one of the existing implementations (either Cinder's
or Nova's).

3) Replace Cinder's and Nova's implementations with references to the
one in Castellan. This can be done in a way that retains compatibility
with the key_manager "backend" (was "api_class") config options
currently used by Cinder and Nova. The code in
cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py
will collapse down to this:

  from castellan.key_manager import conf_key_manager

  class ConfKeyManager(conf_key_manager.ConfKeyManager):
  pass

Having a common ConfKeyManager implementation will make it much
easier to support migrating things to Barbican, and that's an important
step toward the goal of deprecating the ConfKeyManager entirely.

Please let me know your thoughts, as I plan to begin proposing patches.

Regards,

Alan Bishop

__
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] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library

[Dave McCowan (dmccowan)]

On 8/1/17, 8:02 PM, "Tony Breeds" <t...@bakeyournoodle.com> wrote:

>On Tue, Aug 01, 2017 at 04:58:22PM -0400, Doug Hellmann wrote:
>> Excerpts from Dave McCowan (dmccowan)'s message of 2017-08-01 20:48:12
>>+:
>> > This note is to request a Feature Freeze Exemption (FFE) for the
>>python-barbicanclient library in Pike.
>> > 
>> > Python-barbicanclient 4.5.0 was intended to be the Pike release.
>>However, after it was released, testing with the Heat and Octavia
>>projects found that it contained an incompatible change resulting in
>>Tracebacks for those projects.
>> > 
>> > The issue was reported in this bug.
>> > https://bugs.launchpad.net/python-barbicanclient/+bug/1706841
>> > 
>> > A first, and partial, attempt to fix this was merged in this patch.
>> > https://review.openstack.org/487721
>> > This patch is included in release 4.5.1.
>> > 
>> > A second, and successful, fix was merged in this patch.
>> > https://review.openstack.org/489518
>> > This patch is included in release 4.5.2.
>> > 
>> > The Barbican team requests a feature freeze exemption for
>>python-barbicanclient release 4.5.2 to be the release for Pike.
>>Releases 4.5.0 and 4.5.1 should be blocked in global requirements.
>> > 
>> > Thanks,
>> > Dave
>> > IRC:dave-mccowan
>> 
>> This sounds reasonable. It's a critical problem but only affects a small
>> number of projects, so the risk is fairly small.
>
>The current users of python-barbicanclient are:
>Package  : python-barbicanclient
>[python-barbicanclient!=4.5.0,>=4.0.0] (used by 16 projects)
>Also affects : 16 projects
>openstack/castellan   []
>openstack/cinder  [tc:approved-release]
>openstack/compute-hyperv  []
>openstack/heat[tc:approved-release]
>openstack/kolla   []
>openstack/magnum  []
>openstack/mistral []
>openstack/neutron-lbaas   []
>openstack/neutron-lbaas-dashboard []
>openstack/nova[tc:approved-release]
>openstack/octavia []
>openstack/octavia-dashboard   []
>openstack/openstackclient []
>openstack/python-openstackclient  []
>openstack/solum   []
>openstack/tacker  []
>
>But IIUC it's really only octavia and heat that don't work with 4.5.x
>
>Looking at the change logs:
>
>[tony@thor python-barbicanclient]$ git log --decorate --oneline
>--no-merges 4.4.0^..HEAD
>714fce2 (HEAD -> master, origin/master, origin/HEAD, gerrit/master)
>Support import modules from barbicanclient.client module
>49505b9 (tag: 4.5.1) Workaround for importing objects from old path
>ea509a5 Update api references according to refactor result
>e0e3703 Add secret_type filter to CLI
>f844a0e Updated from global requirements
>a95c1a1 Update the documentation link for doc migration
>51d8bfa Updated from global requirements
>c497189 fix default version
>3c7d909 Updated from global requirements
>e599dfd Update doc references
>2479529 import content from cli-reference in openstack-manuals
>9af9169 rearrange the existing docs into the new standard layout
>4eed5c8 Switch from oslosphinx to openstackdocstheme
>439ee25 (tag: 4.4.0) Updated from global requirements
>97906c8 Refactor barbicanclient
>
>So all the changes look okay to me, assuming the 4.5.1 and 4.5.2 patches
>work.
>
>> I assume you've done enough testing to feel comfortable that 4.5.2 will
>> work better than 4.5.0 and 4.5.1?
>
>Once we have the release I'll create no-op changes in all the affected
>projects that depend on the u-c bump.
>
>What concerns me a little is that we can't test this without a release
>and once we do the release we're committed to some form of g-r
>alteration with the impacts associated with it.
>
>Would it be terrible to branch stable/pike @ 4.4.0 and leav all the
>4.5.x stuff for queens?

I'm feeling good with the testing now done on 4.5.2 and would prefer to
make that the Pike release.  If we were to revert to 4.4.0 for Pike, we
would be missing at least one feature and the doc changes that were
planned for Pike.

--Dave


__
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] [release][requirements][barbican][octavia][LBaaS][heat] FFE Request for python-barbicanclient library

[Dave McCowan (dmccowan)]

This note is to request a Feature Freeze Exemption (FFE) for the 
python-barbicanclient library in Pike.

Python-barbicanclient 4.5.0 was intended to be the Pike release.  However, 
after it was released, testing with the Heat and Octavia projects found that it 
contained an incompatible change resulting in Tracebacks for those projects.

The issue was reported in this bug.
https://bugs.launchpad.net/python-barbicanclient/+bug/1706841

A first, and partial, attempt to fix this was merged in this patch.
https://review.openstack.org/487721
This patch is included in release 4.5.1.

A second, and successful, fix was merged in this patch.
https://review.openstack.org/489518
This patch is included in release 4.5.2.

The Barbican team requests a feature freeze exemption for python-barbicanclient 
release 4.5.2 to be the release for Pike.  Releases 4.5.0 and 4.5.1 should be 
blocked in global requirements.

Thanks,
Dave
IRC:dave-mccowan

__
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] [security][barbican] PTG room sharing

[Dave McCowan (dmccowan)]

On 8/1/17, 12:21 PM, "Thierry Carrez"  wrote:

>Luke Hinds wrote:
>> Thanks Dave, I will let Kendall know that we can free up the room from
>> Mon / Tuesday, and instead have the sec proj join barbican on Wed /
>>Thur. 
>
>Note that we have extra room on Monday/Tuesday, so it would be OK to
>keep the room to have cross-project "security discussions", even if
>you'll have your team internal-facing meetings on Wed-Fri...
>
>For example we could use the time to advance the discussion around
>making Castellan/barbican a base service that every other project can
>depend on being present. Or any other cross-project discussion with a
>security focus.
>
>-- 
>Thierry Carrez (ttx)

Thanks!  I'd like to keep the room available for potential cross-project
meetings.  In Atlanta, we did have project teams drop in to discuss how to
integrate with Castellan/Barbican.


__
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] [security][barbican] PTG room sharing

[Dave McCowan (dmccowan)]

Hello Barbican Team,

I believe there were some discussions on room sharing between the security 
project and barbican team.

We are still keen on this in the security project. How would you like to work 
out logistics?

Should we share PTG planning etherpads?

We have 4 days between us, not sure if we will need all four, did you have 
anything in mind here? So far I don't expect the security project will need 
more then a day at max (if that).

p.s. I am plan to come onto the Barbican irc weekly meeting, if you prefer to 
sketch out the details there.

Regards,

Luke

Hi Luke--
We'd be happy to continue of tradition of sharing mid-cycle/PTG meeting 
time and place.
Per the schedule, Security has a room reserved Monday and Tuesday; Barbican 
has a room reserved Wednesday and Thursday.
Our etherpad is here: https://etherpad.openstack.org/p/barbican-ptg-queens.

Anyone with an interest in key management, encryption, or other security 
topics please feel welcome to join us and add your name and topics to the 
etherpad.

Thanks!
--Dave

__
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] [barbican] Help for Barbican and UWSGI Community Goal

[Dave McCowan (dmccowan)]

On 6/23/17, 2:24 PM, "Matthew Treinish" <mtrein...@kortar.org> wrote:

>On Fri, Jun 23, 2017 at 04:11:50PM +0000, Dave McCowan (dmccowan) wrote:
>> The Barbican team is currently lacking a UWSGI expert.
>> We need help identifying what work items we have to meet the UWSGI
>>community goal.[1]
>> Could someone with expertise in this area review our code and docs [2]
>>and help me put together a to-do list?
>
>So honestly barbican is probably already like 90% complete by the way
>there. It
>was already running everything as a proper wsgi script under uwsgi. The
>only thing
>missing was the apache config to use mod_proxy_uwsgi to have all the api
>servers
>running on port 80.
>
>It was also doing everything manually instead of relying on the common
>functionality in PBR and devstack to handle creating wsgi entrypoints and
>deploying wsgi apps.
>
>I pushed up:
>
>https://review.openstack.org/#/q/topic:deploy-in-wsgi
>
>To take care of the gaps and make everything use the common mechanisms. It
>probably will need a little bit of work before it's ready to go. (I didn't
>bother testing anything before I pushed it)
>
>-Matt Treinish

Thanks Matt!


__
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] [barbican] Help for Barbican and UWSGI Community Goal

[Dave McCowan (dmccowan)]

The Barbican team is currently lacking a UWSGI expert.
We need help identifying what work items we have to meet the UWSGI community 
goal.[1]
Could someone with expertise in this area review our code and docs [2] and help 
me put together a to-do list?

Thanks!
Dave (dave-mccowan)

[1] https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html
[2] https://git.openstack.org/cgit/openstack/barbican/tree/

__
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] [openstack-ansible][security] Rename openstack-ansible-security role?

[Dave McCowan (dmccowan)]

>
>So my questions are:
>
>  1) Should the openstack-ansible-security role be
> renamed to alleviate confusion?

+1 on the rename.

>
>  2) If it should be renamed, what's your suggestion?

How about linux-ansible-security?

>
>Thanks!
>
>- --
>Major Hayden
>
>[0] 
>https://www.openstack.org/summit/boston-2017/summit-schedule/events/17616/
>securing-openstack-clouds-and-beyond-with-ansible



__
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] [barbican] [security] Project Onboarding in Boston

[Dave McCowan (dmccowan)]

Greetings!

If you are interested in learning more about Barbican with a goal to 
contribute, please come to the Barbican Project Onboarding session on Tuesday, 
May 9, at 2pm in Room MR101.

We'll be sharing the time slot with the Security project for those interested 
in becoming an OpenStack Security contributor.

Please RSVP here and indicate your preference on topics to cover and the 
methods of learning.

https://etherpad.openstack.org/p/BOS-forum-barbican-onboarding

We'll optimize the session based on interest and number of expected attendees.

Thanks!
--Dave McCowan

__
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] [barbican] Nominating Jeremy Liu for Barbican Core

[Dave McCowan (dmccowan)]

I'm pleased to nominate Jeremy Liu for Barbican core.

He's been a top reviewer and contributor to Barbican since Newton and his 
efforts are very much appreciated.

http://stackalytics.com/?module=barbican-group_id=liujiong=pike

Barbicaneers, please indicate your agreement by responding with +1.

--Dave

__
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] [barbican][castellan] How to share secrets in barbican

[Dave McCowan (dmccowan)]

Another option:

If you want to give User-A read access to all Project-B secrets, you could
assign User-A the role of "observer" in Project-B.

This would use the default RBAC policy, not give every user access to the
secrets, and be more convenient than adding each user to the ACL of each
secret.

Tacker would use the Operator's token to retrieve secrets, and not shared
credentials from the configuration file.

On 3/31/17, 2:58 AM, "yanxingan"  wrote:

>
>Thanks Kaitlin Farr.
>
>In tacker vim usecase, an operator [user A] may create a vim with an
>account[user B] to access the NFVI. I want to store user B's password in
>barbican.
>
>There are two methods to store secret:
>1. All user A's vim secrets are stored in one common reserved
>project/user as mentioned.
>2. For each user A, the vim secret is stored in it's own domain
>respectively.
>
>The problem of 2 is:
>1) Vim can not be shared between different projects with default
>barbican RBAC policy.
>2) It's not secure to open the access to all users via RBAC policy. In
>addition, barbican may be invoked by other projects, e.g. nova, neutron
>lb.
>3) It's not convenient to add every user to the ACL of A's secret.
>
>Is barbican ACL suport a "shared" similar attribute to a secret?
>
>
>On 2017/3/31 3:05, Farr, Kaitlin M. wrote:
>>
>>>As i known, the secrets are saved in a user's domain, and other
>>>project/user can not retrieve the secrets.
>>> But i have a situation that many users need retrieve a same secret.
>>>
>>> After looking into the castellan usage,  I see the method that
>>>saving the credentials in configuration,
>>>  then all operators use this pre-created user to create/retrieve
>>>secrets.
>>>  I want to know, is this way typical and easy-accepted? Does other
>>>projects face this issue?
>>
>>
>> ​By default, the secrets in Barbican are available at the project-level
>> [1]. I am not sure specifically which project or feature you are
>> referring to that all users need to access to one secret, but I would
>> suggest that editing the Barbican RBAC policy or ACL is a more elegant
>> solution than storing username/pw in the conf file. You can find more
>> details about RBAC at [2] and a sample policy.json file at [3].
>>
>> Kaitlin Farr
>>
>> 1. 
>>https://developer.openstack.org/api-guide/key-manager/acls.html#default-a
>>cl
>> 2. 
>>https://docs.openstack.org/developer/barbican/admin-guide-cloud/access_co
>>ntrol.html
>> 3. 
>>https://github.com/openstack/barbican/blob/master/etc/barbican/policy.jso
>>n
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Project Navigator Updates - Feedback Request

[Dave McCowan (dmccowan)]

On 3/31/17, 4:43 AM, "Thierry Carrez"  wrote:

>Brian Rosmaita wrote:
>> On 3/29/17 12:55 AM, Jimmy McArthur wrote:
>> [snip]
>>> What we really need is the following:
>>>
>>> * A project history, including the date of project inception that's
>>> included in the TC tags.
>>> * An API history in an easily digestible format that all projects
>>>share.
>>> So whether you're doing micro releases or not, just something that
>>> allows us to show, based on a release timeline, which API versions per
>>> project are applicable for each OpenStack release. This really needs to
>>> be consistent from project to project b/c at the moment everyone
>>>handles
>>> it differently.
>> 
>> See what you think of these.  They add an "apis" section to the glance
>> section of projects.yaml in the governance repo.
>> 
>> http://paste.openstack.org/show/604775/ has a complete history, where
>> for each release, the complete set of versions of the API that are
>> available in that release (and their statuses) are listed.
>> 
>> http://paste.openstack.org/show/604776/ has an abbreviated history,
>> where only the changes in available APIs are listed from version to
>> version, and if there's no change, the release isn't listed at all.
>> 
>> I don't know if this format would work for microversions, though.  (And
>> I don't know if it's a good idea in the first place.)
>
>I like the idea to provide unified API information, however I'm not sure
>the Technical Committee should stand in the way of getting that
>information updated. The less we force through strict governance
>processes, the better, so everything that can be maintained by some
>other group should be.
>
>This is closer to documentation than governance, so I wonder if this
>document should not be maintained at the API WG or the Docs team or
>service catalog level -- just keeping the same team names so that
>information can be easily cross-referenced with the governance repository.
>
>I'll raise the discussion in open discussion at the next TC meeting.
>
>-- 
>Thierry Carrez (ttx)

There used to be an item on Navigator for "Existence of quality packages
in popular distributions."   It was removed, with the intent to replace it
with a better way to maintain and update this information. [1][2]

Is now a good time to re-implement this tag as well?

[1] https://bugs.launchpad.net/openstack-org/+bug/1656843
[2] https://github.com/OpenStackweb/openstack-org/pull/59




__
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] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager

[Dave McCowan (dmccowan)]

+1 from me.  That looks easy to implement and maintain.

On 3/20/17, 2:49 PM, "Davanum Srinivas" <dava...@gmail.com> wrote:

>Dave,
>
>Here's the precendent from oslo.policy:
>https://review.openstack.org/#/admin/groups/556,members
>
>The reason for setting it up this way with individuals + oslo core +
>keystone core is to make sure both core teams are involved in the
>review process and any future contributors who are not part of either
>team can be give core rights in oslo.policy.
>
>Is it ok to continue this model?
>
>Thanks,
>Dims
>
>On Mon, Mar 20, 2017 at 9:20 AM, Dave McCowan (dmccowan)
><dmcco...@cisco.com> wrote:
>> This sounds good to me.  I see it as a "promotion" for Castellan into
>>the
>> core of OpenStack.  I think a good first step in this direction is to
>> create a castellan-drivers team in Launchpad and a castellan-core team
>>in
>> Gerrit.  We can seed the list with Barbican core reviewers and any Oslo
>> volunteers.
>>
>> The Barbican/Castellan weekly IRC meeting is today at 2000UTC in
>> #openstack-meeting-alt, if anyone want to join to discuss.
>>
>> Thanks!
>> dave-mccowan
>>
>> On 3/16/17, 12:43 PM, "Davanum Srinivas" <dava...@gmail.com> wrote:
>>
>>>+1 from me to bring castellan under Oslo governance with folks from
>>>both oslo and Barbican as reviewers without a project rename. Let's
>>>see if that helps get more adoption of castellan
>>>
>>>Thanks,
>>>Dims
>>>
>>>On Thu, Mar 16, 2017 at 12:25 PM, Farr, Kaitlin M.
>>><kaitlin.f...@jhuapl.edu> wrote:
>>>> This thread has generated quite the discussion, so I will try to
>>>> address a few points in this email, echoing a lot of what Dave said.
>>>>
>>>> Clint originally explained what we are trying to solve very well. The
>>>>hope was
>>>> that the rename would emphasize that Castellan is just a basic
>>>> interface that supports operations common between key managers
>>>> (the existing Barbican back end and other back ends that may exist
>>>> in the future), much like oslo.db supports the common operations
>>>> between PostgreSQL and MySQL. The thought was that renaming to have
>>>> oslo part of the name would help reinforce that it's just an
>>>>interface,
>>>> rather than a standalone key manager. Right now, the only Castellan
>>>> back end that would work in DevStack is Barbican. There has been talk
>>>> in the past for creating other Castellan back ends (Vault or Tang),
>>>>but
>>>> no one has committed to writing the code for those yet.
>>>>
>>>> The intended proposal was to rename the project, maintain the current
>>>> review team (which is only a handful of Barbican people), and bring on
>>>> a few Oslo folks, if any were available and interested, to give advice
>>>> about (and +2s for) OpenStack library best practices. However, perhaps
>>>> pulling it under oslo's umbrella without a rename is blessing it
>>>>enough.
>>>>
>>>> In response to Julien's proposal to make Castellan "the way you can do
>>>> key management in Python" -- it would be great if Castellan were that
>>>> abstract, but in practice it is pretty OpenStack-specific. Currently,
>>>> the Barbican team is great at working on key management projects
>>>> (including both Barbican and Castellan), but a lot of our focus now is
>>>> how we can maintain and grow integration with the rest of the
>>>>OpenStack
>>>> projects, for which having the name and expertise of oslo would be a
>>>> great help.
>>>>
>>>> Thanks,
>>>>
>>>> Kaitlin
>>>>
>>>>___
>>>>__
>>>>_
>>>> 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
>>>
>>>
>>>
>>>--
>>>Davanum Srinivas :: https://twitter.com/dims
>>>
>>>
>>>__
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: 
>>>openstack-dev-requ...@lists.openstack.org?subject

Re: [openstack-dev] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager

[Dave McCowan (dmccowan)]

This sounds good to me.  I see it as a "promotion" for Castellan into the
core of OpenStack.  I think a good first step in this direction is to
create a castellan-drivers team in Launchpad and a castellan-core team in
Gerrit.  We can seed the list with Barbican core reviewers and any Oslo
volunteers.

The Barbican/Castellan weekly IRC meeting is today at 2000UTC in
#openstack-meeting-alt, if anyone want to join to discuss.

Thanks!
dave-mccowan

On 3/16/17, 12:43 PM, "Davanum Srinivas"  wrote:

>+1 from me to bring castellan under Oslo governance with folks from
>both oslo and Barbican as reviewers without a project rename. Let's
>see if that helps get more adoption of castellan
>
>Thanks,
>Dims
>
>On Thu, Mar 16, 2017 at 12:25 PM, Farr, Kaitlin M.
> wrote:
>> This thread has generated quite the discussion, so I will try to
>> address a few points in this email, echoing a lot of what Dave said.
>>
>> Clint originally explained what we are trying to solve very well. The
>>hope was
>> that the rename would emphasize that Castellan is just a basic
>> interface that supports operations common between key managers
>> (the existing Barbican back end and other back ends that may exist
>> in the future), much like oslo.db supports the common operations
>> between PostgreSQL and MySQL. The thought was that renaming to have
>> oslo part of the name would help reinforce that it's just an interface,
>> rather than a standalone key manager. Right now, the only Castellan
>> back end that would work in DevStack is Barbican. There has been talk
>> in the past for creating other Castellan back ends (Vault or Tang), but
>> no one has committed to writing the code for those yet.
>>
>> The intended proposal was to rename the project, maintain the current
>> review team (which is only a handful of Barbican people), and bring on
>> a few Oslo folks, if any were available and interested, to give advice
>> about (and +2s for) OpenStack library best practices. However, perhaps
>> pulling it under oslo's umbrella without a rename is blessing it enough.
>>
>> In response to Julien's proposal to make Castellan "the way you can do
>> key management in Python" -- it would be great if Castellan were that
>> abstract, but in practice it is pretty OpenStack-specific. Currently,
>> the Barbican team is great at working on key management projects
>> (including both Barbican and Castellan), but a lot of our focus now is
>> how we can maintain and grow integration with the rest of the OpenStack
>> projects, for which having the name and expertise of oslo would be a
>> great help.
>>
>> Thanks,
>>
>> Kaitlin
>> 
>>_
>>_
>> 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
>
>
>
>-- 
>Davanum Srinivas :: https://twitter.com/dims
>
>__
>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] [oslo][barbican][castellan] Proposal to rename Castellan to oslo.keymanager

[Dave McCowan (dmccowan)]

On 3/15/17, 6:51 AM, "Julien Danjou"  wrote:

>On Mon, Mar 13 2017, Clint Byrum wrote:
>
>> To me, Oslo is a bunch of libraries that encompass "the way OpenStack
>> does ". When  is key management, projects are, AFAICT,
>>universally
>> using Castellan at the moment. So I think it fits in Oslo
>> conceptually.
>
>It would be cool if it could rather be "the way you can do XXX in
>Python" rather than being too much OpenStack centric. :)
>
>> As far as what benefit there is to renaming it, the biggest one is
>> divesting Castellan of the controversy around Barbican. There's no
>> disagreement that explicitly handling key management is necessary. There
>> is, however, still hesitance to fully adopt Barbican in that role. In
>> fact I heard about some alternatives to Barbican, namely "Vault"[1] and
>> "Tang"[2], that may be useful for subsets of the community, or could
>> even grow into de facto standards for key management.
>>
>> So, given that there may be other backends, and the developers would
>> like to embrace that, I see value in renaming. It would help, I think,
>> Castellan's developers to be able to focus on key management and not
>> have to explain to every potential user "no we're not Barbican's cousin,
>> we're just an abstraction..".
>
>I don't think the Castellan name is a problem in itself, because at
>least to me it does not sound like it's Barbican specific. I'd prefer it
>to be a Python generic library that supports an OpenStack project as one
>of its driver. So I'd hate to have it named oslo.foobar.
>
>As far as moving it under the Oslo library, I understand that the point
>would be to make a point stating that this library is not a
>Barbican-specific solution etc. I think it addresses the problem in the
>wrongŠ but pragmatic way.
>
>What I think would be more interesting is to rename the _Barbican team_
>to the "People-who-work-on-keychain-stuff team". That team would build 2
>things, which are Barbican and Castellan (and maybe more later). That'd
>make more sense than trying to fit everything in Oslo, and would also
>help other projects to do the same thing in the future, and, maybe, one
>day, alleviate the whole problem.
>
>Other than that, sure, we can move it to Oslo I guess. :)

The Barbican community has always been the
"People-who-work-on-key-management-stuff" team.  We launched Castellan in
2015 with the explicit purpose of being a generic abstraction for key
managers.[1]  At that time, we envisioned developing a KMIP plugin to
connect directly to an HSM.  Currently, the interest level is higher
around a plugin for software based secure storage, such as Vault.
However, patches for additional plugins have not been forthcoming.

Castellan was designed from the ground up to be a generic abstraction, and
I, and the rest of the Barbican community, hope to see more driver
development for it.  If a change of name or governance helps, we're all
for it.  But, I hope everyone knows there is no push back from the
"People-who-work-on-key-management-stuff".  We welcome all contributions.

In addition, we want the Castellan library to be the go-to library for any
project that wants to add key management.  It is already used by Nova,
Cinder, Glance, Neutron, Octavia, and Magnum.  If a change in name or
governance helps other projects adopt Castellan, again, we're all for it.
In the meantime, we encourage and stand ready to help all adopters.

dave-mccowan
PTL, "People-who-work-on-key-management-stuff"

[1] https://wiki.openstack.org/wiki/Castellan



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Rolling upgrade in Barbican project

[Dave McCowan (dmccowan)]

Hi Nam--
   Thanks for writing.  Offline rolling upgrades is part of the current
Barbican project.  Better support and documentation for upgrades would be
a welcome addition.

1) API Versioning

Currently, Barbican only has one API version.  The wiki you reference is
an old list of ideas that we started collecting for when/if we create a
V2.  I agree, that as part of any new API version, we'll need to consider
upgrades and backwards compatibility.

2) Database Upgrades

I think we have good support support for doing database upgrades when
upgrading the version of Barbican.  We offer a barbican-db-manage script
to handles upgrades. [1]
It would be good to improve the documentation on this process.  It would
also be good to add a gate job to automatically test upgrading Barbican.

3) RPC Versioning

Adding versioning to our RPC message would be good to future-proof our
design.  Perhaps we should leave the message objects stable for now, and
add a version field in the future when/if a scenario occurs that requires
us to change these message objects.


[1] 
https://docs.openstack.org/developer/barbican/contribute/database_migration
s.html

--Dave (dave-mccowan)



On 2/28/17, 4:52 AM, "na...@vn.fujitsu.com"  wrote:

>Hi everyone,
>
>Recently, there are many emails to discuss a topic that "Why are projects
>trying to avoid Barbican, still?" [0]. That is very an interesting topic.
>Now I would like to make a new topic related to Rolling upgrade. I am
>trying to find  information about the strategy to support rolling-upgrade
>for Barbican project. Unfortunately, there is not any results, if any,
>could you please update it for me.
>
>In my point of view, in order to support this feature, there will be
>three impacts which need to solve:
>
>1. API versioning:
>
>Maybe, Barbican will have version two [1] so I think we should have a
>plan to still support version 1 on version 2. What do you about this
>point?
>
>2. Database
>
>- For OVO (Oslo version object) [2], I am wondering we should use OVO for
>this project. In my option, I am afraid that OVO is overkill for this
>project.
>- For DB upgrading, currently there are some files [3-4] to drop and
>alter column. This really should not have because there is not still have
>a solution in case of delete or alter DB. That why there is a rule that
>don't allow somebody to delete/alter DB in Nova and Neutron :) Do you
>think we should prepare for this?
>
>3. RPC
>
>There is not version parameter when sending AMQP [5]. This parameter is
>really necessary to distinguish the message is Ocata or Pike.
>
>That is some points in my option, what do you think we should have to
>plan to support this feature and I am very glad to discuss this topic
>with you on this thread mailing-list.
>
>[0] 
>http://lists.openstack.org/pipermail/openstack-dev/2017-January/thread.htm
>l#110192 
>[1] https://wiki.openstack.org/wiki/Barbican/v2
>[2] https://www.slideshare.net/davanum/ovo-deep-dive
>[3] 
>https://github.com/openstack/barbican/blob/master/barbican/model/migration
>/alembic_migrations/versions/3041b53b95d7_remove_size_limits_on_meta_table
>_values.py 
>[4] 
>https://github.com/openstack/barbican/blob/master/barbican/model/migration
>/alembic_migrations/versions/254495565185_removing_redundant_fields_from_o
>rder.py 
>[5] 
>https://github.com/openstack/barbican/blob/master/barbican/queue/client.py
>#L49 
>
> --
>Best Regard,
>
>Nam NH
>OpenStack team
>
>
>__
>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 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?

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

[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 >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, January 16, 2017 at 5:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
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?

[Dave McCowan (dmccowan)]

On 1/16/17, 11:52 AM, "Ian Cordasco"  wrote:

>-Original Message-
>From: Rob C 
>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

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] [barbican] Project Navigator Out of Date?

[Dave McCowan (dmccowan)]

Hi Ian--
   Thanks for the reminder.  As PTL, I know I have some action items to
update our project navigator status.
   Speaking on behalf of the Barbican community, I can say that we do
follow the rules of stable branches and deprecation.  I'll submit a patch
now to state this assertion.
   I also believe that we currently have the appropriate variety of
distributions available.  Our installation guide gives instructions on how
to install from each of these.  I don't know how to apply for this "star"
in project navigator.
   We have taken steps to qualify for vulnerability management, most
notably we completed a threat modeling exercise with the security project
team.  I'll reach out to that team to find out what remaining steps are
necessary to be tagged as vulnerability managed.
--Dave

On 1/16/17, 8:55 AM, "Ian Cordasco"  wrote:

>Hi barbicaneers (I don't actually know what y'all call yourselves :)),
>
>Related to the other thread I just started, I was looking at the
>project navigator [1] for Barbican and found some things that look
>wrong (to an outsider) and was hoping could be cleared up.
>
>First, "Is this project maintained following the common Stable branch
>policy?" appears to be "Yes" now. I notice you have stable branches
>that actually look stable. Are y'all working with the stable
>maintenance team on them?
>
>Second, "Does this project follows standard deprecation?" I'm not
>(yet) a user of Barbican, but are you still not following the standard
>deprecation policy?
>
>Third, "Existence and quality of packages for this project in popular
>distributions." it seems Fedora [2], Debian [3], Ubuntu [4], and
>OpenSUSE [5] all have packages (including in stable versions). I can't
>speak to the quality of the packages, but knowing the hard work most
>of our downstream redistributors put into those packages, I'm certain
>they're good quality. This should *definitely* be updated, in my
>opinion.
>
>Finally, "Are vulnerability issues managed by the OpenStack security
>team?". I know that the OpenStack Security Project worked with the
>Barbican team to come up with a vulnerability analysis a few midcycles
>ago. Is that roughly where you all stopped? Is there a reason you
>haven't attempted to work with the VMT on security issues?
>
>Hopefully my agenda is obvious - I'd like to see fewer projects
>attempting to implement their own secret storage and instead use
>Barbican. Keeping the navigator up-to-date seems (to me) to be a good
>way to improve Barbican's image. I would be happy to work with you all
>(with what little time I have) to update the navigator to better
>reflect Barbican's reality.
>
>[1]: 
>https://www.openstack.org/software/releases/newton/components/barbican
>[2]: https://apps.fedoraproject.org/packages/s/barbican
>[3]: 
>https://packages.debian.org/search?keywords=barbican=all=al
>l=all
>[4]: 
>http://packages.ubuntu.com/search?keywords=barbican=names=a
>ll=all
>[5]: 
>https://software.opensuse.org/search?utf8=✓=barbican_devel=false;
>search_unsupported=false=openSUSE:Leap:42.2
>
>Cheers,
>--
>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

__
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] [barbican] Nominating Arun Kant for barbican-core

[Dave McCowan (dmccowan)]

Arun has been a long-time terrific reviewer and contributor to Barbican.

100% +1


--Dave

On 11/7/16, 9:37 AM, "Ade Lee"  wrote:

>Hi everyone, 
>
>I'd like to nominate Arun Kant for the barbican-core team.
>
>Arun has been a very active contributor to the project over the past
>few years, implementing and seeing through major features like ACLs and
>multiple secret store back-ends.  This includes providing all the
>required API documentation.
>
>He's also been active squashing bugs, and providing helpful and
>insightful reviews.
>
>As a reminder to barbican-core members, we use the voting process
>outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
>members to our team.
>
>Thanks,
>Ade
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [reno][i18n][barbican] msgmerge error on release notes build

[Dave McCowan (dmccowan)]

Hello Translations and Reno Team,

I'm looking for help with a the Barbican release notes job.
In the last week, our release note gate job starting failing with the following 
error.

2016-10-28 10:07:21.972504 | + resname=index
2016-10-28 10:07:21.972567 | + msgmerge --silent -o 
releasenotes/source/locale/zh_CN/LC_MESSAGES/index.po 
releasenotes/source/locale/zh_CN/LC_MESSAGES/releasenotes.po 
releasenotes/source/locale/index.pot
2016-10-28 10:07:21.972767 | /tmp/05-2d8c279a3bef4697b4ba9774c79c6263.sh: line 
92: msgmerge: command not found

Here's an example patch: https://review.openstack.org/#/c/389875/

There has been no merged change to the Barbican repo lately that seems to be 
related to this.

Seven days ago, our release notes worked and included a Chinese translation.
Today, our gate is blocked for any patch that attempts to build release notes.

We're stumped. :-)

We'd appreciate any ideas on how to fix this.

Thanks!

--Dave

__
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] [nova][barbican][security] Ocata design summit session change

[Dave McCowan (dmccowan)]

Thanks Matt.
Cross-project CI testing is something the Barbican team is very interested
in.
I'll make sure we have representation.

On 10/13/16, 4:15 PM, "Matt Riedemann"  wrote:

>I've changed the nova design summit session on docs needed for newton to
>now be a session to cover the various security-related specs up for
>review:
>
>https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/169
>77/nova-security-specs-and-testing
>
>And to also talk about getting a CI job going which will test some of
>these features, like with barbican as the key manager and using signed
>images.
>
>I've tagged this session with 'barbican' although I see that the
>barbican team is having another session at the same time. There was one
>other slot that I could have moved for nova but barbican had a conflict
>then too, so I've just left this where it is and if anyone from barbican
>can show up all the better, but I don't think it's necessarily a
>requirement.
>
>-- 
>
>Thanks,
>
>Matt Riedemann
>
>
>__
>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] Pecan Version 1.2

[Dave McCowan (dmccowan)]

I don't know what triggered the update.  Our gates started breaking on 
September 23, but I can't find a commit around that time that would have caused 
this to happen.

From: Clay Gerrard <clay.gerr...@gmail.com<mailto:clay.gerr...@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, September 26, 2016 at 6:03 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] Pecan Version 1.2

I'm interested to hear how this works out.

I thought upper-constraints was somehow supposed to work to prevent this?  Like 
maybe don't install a brand new shiny upstream version on the gate 
infrastructure test jobs until it passes all our tests?  Prevent a fire drill?  
That bug was active back in July - but I guess 1.2 was released pretty 
recently?   maybe I don't understand the timeline.

-Clay

On Mon, Sep 26, 2016 at 2:21 PM, Dave McCowan (dmccowan) 
<dmcco...@cisco.com<mailto:dmcco...@cisco.com>> wrote:

The Barbican project uses Pecan as our web framework.

At some point recently, OpenStack started picking up their new version 1.2.  
This version [1] changed one of their APIs such that certain calls that used to 
return 200 now return 204.  This has caused immediate problems for Barbican 
(our gates for /master, stable/newton, and stable/mitaka all fail) and a 
potential larger impact (changing the return code of REST calls is not 
acceptable for a stable API).

Before I start hacking three releases of Barbican to work around Pecan's 
change, I'd like to ask:  are any other projects having trouble with
Pecan Version 1.2?  Would it be possible/appropriate to block this version as 
not working for OpenStack?

Thanks,
Dave McCowan


[1]
http://pecan.readthedocs.io/en/latest/changes.html
https://github.com/pecan/pecan/issues/72


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Pecan Version 1.2

[Dave McCowan (dmccowan)]

The Barbican project uses Pecan as our web framework.

At some point recently, OpenStack started picking up their new version 1.2.  
This version [1] changed one of their APIs such that certain calls that used to 
return 200 now return 204.  This has caused immediate problems for Barbican 
(our gates for /master, stable/newton, and stable/mitaka all fail) and a 
potential larger impact (changing the return code of REST calls is not 
acceptable for a stable API).

Before I start hacking three releases of Barbican to work around Pecan's 
change, I'd like to ask:  are any other projects having trouble with
Pecan Version 1.2?  Would it be possible/appropriate to block this version as 
not working for OpenStack?

Thanks,
Dave McCowan


[1]
http://pecan.readthedocs.io/en/latest/changes.html
https://github.com/pecan/pecan/issues/72

__
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] [barbican] PTL Candidacy

[Dave McCowan (dmccowan)]

Fellow Barbicaneers,


I'd like to nominate myself to serve as Barbican PTL for the Ocata cycle.


After talking it over with Doug (redrobot), I know I have a mentor in place.  
After talking it over with my employer, I know I will have the time and 
resources to dedicate to this position.


I first started working on Barbican in the Kilo release.  You were all 
welcoming and supportive to this stranger who wandered into your midcycle.  I 
was immediately impressed by your dedication to the project and your 
willingness to mentor me in all things OpenStack.


First and foremost, I want to maintain this culture in Barbican.


My goals for the Ocata cycle are:


1) Grow the Barbican team of contributors and core reviewers.

2) Collaborate with other OpenStack projects with joint blueprints, especially 
signing as a service (Designate) and container based install (Kolla).

3) Improve our project maturity index by addressing documentation and process 
items. [1]

4) Maintain our high standards for code reviews and unit and functional tests.

5) Be diligent with backporting bug fixes to stable releases.


Thank you in advance for this opportunity to serve.


Also, thanks to Doug Mendizábal for his leadership over the last four cycles 
and his offer to support me in this endeavor.


--Dave McCowan (dave-mccowan)


[1] https://www.openstack.org/software/releases/mitaka/components/barbican

__
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] [kolla] OSIC scale testing

[Dave McCowan (dmccowan)]

Steve and I just setup and kicked off Scenario #4.
The Rally test suite is running now.

This is "Fourth Deployment" from 
https://etherpad.openstack.org/p/kolla-N-midcycle-osic
This deployment is with two VIPs and TLS is configured on the external VIP.
Nodes: 3 control, 12 storage (with ceph), 100 compute.
Using OVS.

We changed:
   rally.git/rally_openstack.conf  (adding TLS)
   /etc/kolla/globals.yml  (adding TLS, changing internal VIP to .201, adding 
external VIP, changing to OVS)
   /etc/kolla/admin-openrc.sh (adding TLS)

So, whoever runs scenario #5 should double check those files match what you 
need.

--Dave McCowan

From: "Steven Dake (stdake)" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, August 26, 2016 at 9:43 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [kolla] OSIC scale testing

Hey folks,

We have nearly automated all of the OSIC testing and there are instructions to 
follow in NEXTSTEPS.  They take about 1 hour to execute (to setup a test0 and 
then all done.  We have the cluster until the 30th.  I need folks that have 
access to help out as much as possible between now and the 30th so we can 
finish our data gathering.

Also as people go through the scenarios, can you give an update on the mailing 
list that you put in your hour on the NEXTSTEPS execution?  Thanks.

Regards
-steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] High Availability

[Dave McCowan (dmccowan)]

The most basic requirement here for Magnum is that it needs a safe place to 
store credentials.  A safe place can not be provided by just a library or even 
by just a daemon.  Secure storage is provided by either hardware solution (an 
HSM) or a software solution (SoftHSM, DogTag, IPA, IdM).  A project should give 
a variety of secure storage options to the user.

On this, we have competing requirements.  Devs need a turnkey option for easy 
testing locally or in the gate.  Users kicking the tires want a realistic 
solution they try out easily with DevStack.  Operators who already have secure 
storage deployed for their cloud want an option that plugs into their existing 
HSMs.

Any roll-your-own option is not going to meet all of these requirements.

A good example, that does meet all of these requirements, is the key manager 
implementation in Nova and Cinder. [1] [2]

Nova and Cinder work together to provide volume encryption, and like Magnum, 
have a need to store and share keys securely.  Using a plugin architecture, and 
the Barbican API, they implement a variety of key storage options:
- Fixed key allows for insecure stand alone operation, running only Nova and 
Cinder
- Barbican with static key, allows for easy deployment that can be started 
within DevStack by few lines of config.
- Barbican with a secure backend, allows for production grade secure storage of 
keys that has been tested on a variety of HSMs and software options.

Barbican's adoption is growing.  Nova, Cinder, Neutron LBaaS, Sahara, and 
Magnum all have implementations using Barbican.  Swift and DNSSec also have use 
cases.  There are both RPM and Debian packages available for Barbican.  There 
are (at least tech preview)  versions of puppet modules, Ansible playbooks, and 
DevStack plugins to deploy Barbican.

In summary, I think using Barbican absorbs the complexity of doing secure 
storage correctly.  It gives operators production grade secure storage options, 
while giving devs easier options.

--Dave McCowan

[1] https://github.com/openstack/nova/tree/master/nova/keymgr
[2] https://github.com/openstack/cinder/tree/master/cinder/keymgr

From: Hongbin Lu >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, March 18, 2016 at 10:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [magnum] High Availability

OK. If using Keystone is not acceptable, I am going to propose a new approach:

· Store data in Magnum DB

· Encrypt data before writing it to DB

· Decrypt data after loading it from DB

· Have the encryption/decryption key stored in config file

· Use encryption/decryption algorithm provided by a library

The approach above is the exact approach used by Heat to protect hidden 
parameters [1]. Compared to the Barbican option, this approach is much lighter 
and simpler, and provides a basic level of data protection. This option is a 
good supplement to the Barbican option, which is heavy but provides advanced 
level of protection. It will fit into the use cases that users don't want to 
install Barbican but want a basic protection.

If you disagree, I would request you to justify why this approach works for 
Heat but not for Magnum. Also, I also wonder if Heat has a plan to set a hard 
dependency on Barbican for just protecting the hidden parameters.

If you don't like code duplication between Magnum and Heat, I would suggest to 
move the implementation to a oslo library to make it DRY. Thoughts?

[1] 
https://specs.openstack.org/openstack/heat-specs/specs/juno/encrypt-hidden-parameters.html

Best regards,
Hongbin

From: David Stanek [mailto:dsta...@dstanek.com]
Sent: March-18-16 4:12 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] High Availability


On Fri, Mar 18, 2016 at 4:03 PM Douglas Mendizábal 
> 
wrote:
[snip]
>
> Regarding the Keystone solution, I'd like to hear the Keystone team's 
> feadback on that.  It definitely sounds to me like you're trying to put a 
> square peg in a round hole.
>

I believe that using Keystone for this is a mistake. As mentioned in the 
blueprint, Keystone is not encrypting the data so magnum would be on the hook 
to do it. So that means that if security is a requirement you'd have to 
duplicate more than just code. magnum would start having a larger security 
burden. Since we have a system designed to securely store data I think that's 
the best place for data that needs to be secure.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [barbican] Nominating Fernando Diaz for Barbican Core

[Dave McCowan (dmccowan)]

+1

On 2/15/16, 12:45 PM, "Douglas Mendizábal"
 wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>Hi All,
>
>I would like to nominate Fernando Diaz for the Barbican Core team.
>Fernando has been an enthusiastic contributor since joining the
>Barbican team.  He is currently the most active non-core reviewer on
>Barbican projects for the last 90 days. [1]  He¹s got an excellent eye
>for review and I think he would make an excellent addition to the team.
>
>As a reminder to our current core reviewers, our Core Team policy is
>documented in the wiki. [2]  So please reply to this thread with your
>votes.
>
>Thanks,
>- - Douglas Mendizábal
>
>[1] http://stackalytics.com/report/contribution/barbican-group/90
>[2] https://wiki.openstack.org/wiki/Barbican/CoreTeam
>-BEGIN PGP SIGNATURE-
>
>iQIcBAEBCgAGBQJWwg7GAAoJEB7Z2EQgmLX7mEUP/RFZCAZ9ZbDAB48lgek1dAPo
>0KoK8IjkQhwKE7VYYhHwoZIlIdG0Eb9t8Y8ia9+k3SDzo0Q3upXckqEZbiZUZWQT
>gv0BwpMkfUJ8zQeEQouomN8p/ZeRayZuAi3rz5rfte/JDr6IA1eFmPFRAQG+UO1H
>hN6Al7nGm1Ixu/t969fqzslI6FwUu6CHGMDAcoXxL1mlCptC82mRzZZ26m0ObPFQ
>GcnVka7CPseMqHCM6ls9I8AIubAWRehth9oLp7MP6D1vmJagNkwsWnHw5iB1rfBu
>5TU9litnvei89kZ0uoIiOVruo9zh8R/hXn7CT3s3+9sQdwURrmoTHpEWlPlFQ8c7
>ZRqRB7xt4L6jBt3lhoxCDftbmLIDMjBDPsfZjQKG44c+Tr0XuvaWTBVu/giJhvYW
>RnKbQNhB/cByVooVc9itRC8QxZfI+3Ee1X+YEJrALDxjinAl7cHbi1T3DhmFyhRn
>RbnF/9OVqy4+EqLsZFqEWdVZtyn29NWBOmiTyYtufufI41Yu+L6KU/hKj/a5HcSh
>P63Bwp2cpyu+bJsCvMJWfXwW2odUte9RBKsmozFz2Q1ge2FMsr1nR7U0/+DVLoYI
>GLHB3uvnKi2PgWAdbJCS21J6bGlhVX/MoIP/4gWmVuG5LflAfbyg3n5STgnRr7vQ
>iBe0oW8NcTsETUVCYkwA
>=09Wx
>-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


__
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] [Barbican] Enabling GET of secrets to work irrespective of Tenant name in login

[Dave McCowan (dmccowan)]

Hi Vijay--
The recommended way for supporting that use case is to use Barbican's
ACLs.  It allows user's from another project/tenant to access specific
secrets 

If the "demo admin" owns a secret and wants to give read access to
"admin admin", the "demo admin" should create a ACL for the secret.
If an LBaaS user needs access to a tenant secret, the tenant admin can
create an ACL granting read access to the LBaaS user.

http://docs.openstack.org/developer/barbican/api/quickstart/acls.html

--Dave



On 11/10/15, 3:41 AM, "Vijay Venkatachalam"
 wrote:

>Hi,
>
>Can we enable GET of secrets to work irrespective of Tenant name in the
>login?
>
>Consider there is an "admin" with "admin" role in "demo" tenant. I tried
>to query the "demo" tenant's secret using  a login token which was
>generated from "admin" user  & "admin" tenant. And I am getting a
>Forbidden error. Could we make this scenario work?
>
>UseCase:
> 
>LBaaS extension has admin credentials and generates a token and uses it
>to contact services like nova, barbican etc. It is currently using  the
>same token to get the tenant's secret/certificates with the href and it
>is not working.
>
>Thanks,
>Vijay V.
>
>__
>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] openstack-barbican-authenticate-keystone-barbican-command

[Dave McCowan (dmccowan)]

Hi Arif--
Maybe using the OpenStack client would be easier for you.  It will take 
care of authenticating with Keystone, setting the HTTP headers, and providing 
reasonable defaults.
It looks like you have installed OpenStack with DevStack.  If this is the 
case:

$ cd ~/devstack
$ source openrc admin admin
$ openstack secret store -p "super secret data"
# An HREF is returned in the response when the secret has been stored
$ openstack secret get   -p
# Your secret is returned

   Drop by our IRC channel at #openstack-barbican on freenode if you have more 
questions, or if this suggestion doesn't work with your deployment.
--Dave

From: OpenStack Mailing List Archive >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Monday, October 26, 2015 at 1:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] 
openstack-barbican-authenticate-keystone-barbican-command

Link: https://openstack.nimeyo.com/62868/?show=63238#c63238
From: marif82 >


Hi Dave,

Thanks for your response.
I am the beginner in OpenStack so I don't know how to get Keystone token so I 
searched and found "admintoken = a682f596-76f3-11e3-b3b2-e716f9080d50" in 
keystone.conf file. As you suggested i have removed the projectid from curl 
command and X-Auth-Token in curl command as per your suggestion and I am still 
getting the same error, please see below:

bash-4.2$ curl -X POST -H 'content-type:application/json' -H 
'X-Auth-Token:a682f59676f311e3b3b2e716f9080d50' -H 'X-Project-Id:12345' -d 
'{"payload": "my-secret-here", "payloadcontenttype": "text/plain"}' 
http://localhost:9311/v1/secrets -v
* About to connect() to localhost port 9311 
(#0)
* Trying ::1...
* Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9311 
(#0)

POST /v1/secrets HTTP/1.1
User-Agent: curl/7.29.0
Host: localhost:9311
Accept: /
content-type:application/json
X-Auth-Token:a682f59676f311e3b3b2e716f9080d50
X-Project-Id:12345
Content-Length: 67

* upload completely sent off: 67 out of 67 bytes
< HTTP/1.1 401 Unauthorized
< Content-Type: text/html; charset=UTF-8
< Content-Length: 23
< WWW-Authenticate: Keystone uri='http://localhost:35357'
< Connection: close
<
* Closing connection 0
Authentication requiredbash-4.2$

Please help me.

Regards,
Arif
__
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] openstack-barbican-authenticate-keystone-barbican-command

[Dave McCowan (dmccowan)]

Hi Arif--
Are you using Keystone for authentication?
If so, you need to get an authentication token from Keystone and add it as 
a header to your curl command: -H "X-Auth-Token:$TOKEN".
You do not need to specify the project ID (-H 'X-Project-Id:12345').  The 
project ID will be based on your Keystone user's project ID.
--Dave

From: OpenStack Mailing List Archive >
Reply-To: 
"openstack-dev@lists.openstack.org" 
>
Date: Wednesday, October 21, 2015 at 3:11 AM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: [openstack-dev] 
openstack-barbican-authenticate-keystone-barbican-command

Link: https://openstack.nimeyo.com/62868/?show=62868#q62868
From: marif82 >


Hi Asha,

I am also getting the same error when I am executing the curl command to create 
secret.

bash-4.2$ curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id:12345' -d '{"payload": "my-secret-here","payloadcontenttype": 
"text/plain"}' http://localhost:9311/v1/secrets
Authentication requiredbash-4.2$

Can you please help me how you have solved this problem. I am using the safenet 
HSM for MKEK and HMAC and it generated successfully on HSM partition.

Please help me to resolve this issue.

Thanks & Regards,
Arif
__
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] [release] opening stable/liberty

[Dave McCowan (dmccowan)]

Hi Doug--
   I will fix the Barbican branch.
   https://review.openstack.org/#/c/235157/
--Dave

On 10/15/15, 2:30 PM, "Doug Hellmann"  wrote:

>One of the first steps for opening stable/liberty is to update the
>version settings in the branches to no longer use pre-versioning.
>Thierry submitted a bunch of patches to projects [0], and some are
>merging now.
>
>Others are running into test failures, though, and need attention from
>project teams. We need release liaisons to look at them, or find someone
>to look at them, and take over the patches to add whatever fixes are
>needed so we can land them.
>
>Please respond to this thread if you're taking over the patch for your
>project so we know who is working on each.
>
>Doug
>
>[0] 
>https://review.openstack.org/#/q/branch:stable/liberty+topic:next-liberty-
>stable,n,z
>
>__
>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] [Barbican] Providing service user read access to all tenant's certificates

[Dave McCowan (dmccowan)]

The tenant admin from Step 1, should also do Step 2.

From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, September 16, 2015 at 9:57 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates


How does lbaas do step 2?
It does not have the privilege for that secret/container using the service user.
Should it use the keystone token through which user created LB config and 
assign read access for the secret/container to the LBaaS service user?

Thanks,
Vijay V.

From: Fox, Kevin M [mailto:kevin@pnnl.gov]
Sent: 16 September 2015 19:24
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Barbican] Providing service user read access to 
all tenant's certificates

Why not have lbaas do step 2? Even better would be to help with the instance 
user spec and combined with lbaas doing step 2, you could restrict secret 
access to just the amphora that need the secret?

Thanks,
Kevin


From: Vijay Venkatachalam
Sent: Tuesday, September 15, 2015 7:06:39 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates
Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
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] [Barbican] Providing service user read access to all tenant's certificates

[Dave McCowan (dmccowan)]

A user with the role "observer" in a project will have read access to all 
secrets and containers for that project, using the default settings in the 
policy.json file.

--Dave McCowan

From: Vijay Venkatachalam 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Tuesday, September 15, 2015 at 10:06 PM
To: "OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)" 
>
Subject: [openstack-dev] [Barbican] Providing service user read access to all 
tenant's certificates

Hi,
   Is there a way to provide read access to a certain user to all 
secrets/containers of all project/tenant’s certificates?
   This user with universal “read” privilege’s will be used as a 
service user by LBaaS plugin to read tenant’s certificates during LB 
configuration implementation.

   Today’s LBaaS users are following the below mentioned process

1.  tenant’s creator/admin user uploads a certificate info as secrets and 
container

2.  User then have to create ACLs for the LBaaS service user to access the 
containers and secrets

3.  User creates LB config with the container reference

4.  LBaaS plugin using the service user will then access container 
reference provided in LB config and proceeds to implement.

Ideally we would want to avoid step 2 in the process. Instead add a step 5 
where the lbaas plugin’s service user checks if the user configuring the LB has 
read access to the container reference provided.

Thanks,
Vijay V.
__
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][tests] Fix it friday! [mock failure in CI]

[Dave McCowan (dmccowan)]

Has anyone else seen this error with the new mock?

'self' parameter lacking default value


My function under test runs correctly, but then Mock throws this TypeError
when comparing the parameters in assert_calls_with().

I'm seeing this in Barbican.  More info below [1][2].

--Dave

[1] Complete backtrace
==
FAIL: 
barbican.tests.plugin.test_kmip.WhenTestingKMIPSecretStore.test_store_passp
hrase_secret_assert_called
--
_StringException: Traceback (most recent call last):
  File /Users/dmccowan/barbican/barbican/tests/plugin/test_kmip.py, line
432, in test_store_passphrase_secret_assert_called
credential=self.credential)
  File 
/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
ock.py, line 941, in assert_called_once_with
return self.assert_called_with(*args, **kwargs)
  File 
/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m
ock.py, line 930, in assert_called_with
six.raise_from(AssertionError(_error_message(cause)), cause)
  File 
/Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/six.py
, line 692, in raise_from
raise value
AssertionError: Expected call: mock(credential=Struct(),
object_type=ObjectType.SECRET_DATA: 7, secret=ANY,
template_attribute=ANY)
Actual call: mock(credential=Struct(),
object_type=ObjectType.SECRET_DATA: 7, secret=Struct(),
template_attribute=Struct())
'self' parameter lacking default value


[2] A CR (containing other unit test fixes) that is failing with this
https://review.openstack.org/200824




On 7/10/15, 3:45 AM, Robert Collins robe...@robertcollins.net wrote:

Good news everybody, mock 1.1.0 is now out. This backports all the
improvements over the last couple of years, making it fully
synchronised with cPython master. Yay.

Bad news. Lots of unit tests jobs have suffered falled from this.

But - none of the things I've looked into so far are bugs in mock 1.1.0.

One of the improvements in mock is to fail when a bad method is called.

Consider this: 
https://review.openstack.org/#/c/200384/1/taskflow/tests/unit/test_engine_
helpers.py

Note the old method: mock_import.assert_called_onec_with(name)

That method never existed. onec is a typo :).

mock 1.0.1 silently accepts that - thats part of its job. But, its a
very fragile API.

1.1.0 makes that an error, for methods with assert prefixes - unless
unsafe is specifically requested. So a big chunk of the failing tests
are tests that were not testing anything *at all*.
One common exampled of that is 'assert_called' - another method that
never ever existed. All our tests using that were testing nothing at
all.


Neutron is failing on a bunch of tests that accessed a private
function inside mock. I'm surprised reviewers didn't spot this, but
_patch isn't part of the public API, and never was.

Tempest seems to be failing due to a different object being returned -
I haven't dug deep enough to describe the cause in more detail.

We can probably pin mock back to 1.0.1 locally within projects to gain
breathing room, but given the API improvements in 1.1.0 (see below[1]
as readthedocs is failing to build it due to having an old pip in
their virtualenvs :/) - I think we'll be much better off adopting it
as quickly as we can. NB: with this release we don't need to use
'unittest.mock' for Python3.4 - we can just standardise on using
'mock' across the board, which is much simpler and easier to reason
about (same codebase everywhere[2])

[2]: Python 2.6 support was dropped in 1.1.0, so we need to use
markers to select 1.0.1 for the remaining 2.6 gate jobs. (We should
kill those of asap).
[1]:
- Issue #23310: Fix MagicMock's initializer to work with __methods__, just
  like configure_mock().  Patch by Kasia Jachim.

- Issue #23568: Add rdivmod support to MagicMock() objects.
  Patch by Håkan Lövdahl.

- Issue #23581: Add matmul support to MagicMock. Patch by Håkan Lövdahl.

- Issue #23326: Removed __ne__ implementations.  Since fixing default
__ne__
  implementation in issue #21408 they are redundant. *** NOT BACKPORTED
***

- Issue #21270: We now override tuple methods in mock.call objects so that
  they can be used as normal call attributes.

- Issue #21256: Printout of keyword args should be in deterministic order
in
  a mock function call. This will help to write better doctests.

- Issue #21262: New method assert_not_called for Mock.
  It raises AssertionError if the mock has been called.

- Issue #21238: New keyword argument `unsafe` to Mock. It raises
  `AttributeError` incase of an attribute startswith assert or assret.

- Issue #21239: patch.stopall() didn't work deterministically when the
same
  name was patched more than once.

- Issue #21222: Passing name keyword argument to mock.create_autospec now
  works.

- Issue #17826: setting an iterable side_effect on a mock function
created by
  create_autospec