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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

- - Douglas

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

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

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

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

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

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

- - Douglas

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

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

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

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

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

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

- - Douglas

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

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

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

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

[openstack-dev] [barbican] Deprecating Certificate Issuance

[Douglas Mendizábal]

Hello Openstack-dev,

The Barbican team will be deprecating the Ceritficate Issuance feature
in Barbican for the Newton release.  This is something that the
community has been discussing since before the Tokyo summit, and we feel
now is the right time to begin the deprecation process.  I'll try to
answer some common questions about this decision below:

* Why are we deprecating Certificate Issuance?

There are a few reasons that were considered for this decision.  First,
there does not seem to be a lot of interest in the community to fully
develop the Certificate Authority integration with Barbican.  We have a
few outstanding blueprints that are needed to make Certificate Issuance
fully functional, but so far no one has committed to getting the work
done.  Additionally, we've had very little buy-in from public
Certificate Authorities.  Both Symantec and Digicert were interested in
integration in the past, but that interest didn't materialize into
robust CA plugins like we hoped it would.

Secondly, there have been new developments in the space of Certificate
Authorities since we started Barbican.  The most significant of these
was the launch of the Let's Encrypt public CA along with the definition
of the ACME protocol for certificate issuance.  We believe that future
certificate authority services would do good to implement the ACME
standard, which is quite different than the API the Barbican team had
developed.

Lastly, deprecating Certificate Issuance within Barbican will simplify
both the architecture and deployment of Barbican.  This will allow us to
focus on the features that Barbican does well: the secure storage of
secret material.

* Will Barbican still be able to store Certificates?

Yes, absolutely!  The only thing we're deprecating is the the plugin
interface that talks to Certificate Authorites and associated APIs.
While you will not be able to use Barbican to issue a new certificate,
you will always be able to securely store any certificates in Barbican,
including those issued by public CAs or internal CAs.

* When will the APIs be removed?

The Barbican team will follow the standard deprecation policy for this
feature.  All APIs will still ship as part of the Newton release, and
we'll begin the deprecation work in the Ocata cycle.

Feel free to ask any other questions you may have.

Thanks,
Douglas Mendizábal
Barbican PTL



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

Re: [openstack-dev] [barbican] Secure Setup & HSM-plugin

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Manuel,

Historically all of our contributors working with the PKCS#11 crypto
plugin have been using Safenet HSMs, which is why the Safenet
mechanism is the default.

The "CKR_MECHANISM_PARAM_INVALID" error appears to be a bug.  You may
file a bug report in our Launchpad page. [1]

The "CryptoPluginNotFound" may mean that the PKCS#11 plugin is failing
to instantiate.  I think it may mean that we don't currently support
those algorithms.  I would have to do some debugging to get to the
root of this issue, but it sounds like we may need some more work to
support the different algorithms you're trying to use.

In theory, the PKCS#11 plugin should be able to work with any PKCS#11
device.  I suspect that fixing the "CKR_MECHANISM_PARAM_INVALID" bug
may be all we need to get the Utimaco HSM working.

You're more than welcome to contribute patches to get your HSM
working.  You can take a look at our development guide if contributing
is something you're interested in. [2]

Thanks,
- - Doug

[1] https://bugs.launchpad.net/barbican
[2] http://docs.openstack.org/developer/barbican/#barbican-for-developer
s

On 8/16/16 8:22 AM, Praktikant HSM wrote:
> Hi Douglas,
> 
> Thank you very much for your response.
> 
> When testing the usage of the generated MKEK, we ran into some
> problems. For clarification: we are testing the PKCS#11-based
> crypto plugin with a Utimaco HSM. The error messages are from
> Barbican's and Utimaco's log files.
> 
> When storing a secret, we get the following error:
> CKM_MECHANISM_INVALID (Mechanism 0x811c is invalid). Since this
> is a vendor specific AES-GCM mechanism by SafeNet[1], it is not
> supported by our HSMs.
> 
> In the p11_crypto.py file, the default algorithm is set to
> "VENDOR_SAFENET_CKM_AES_GCM"[2]. Thus, we specified "CKM_AES_GCM"
> in the barbican.conf file in the [p11_crypto_plugin] section to be
> used instead of the default mechanism. However, this gave us a
> "CKR_MECHANISM_PARAM_INVALID" error: mechanism length invalid
> (expected 40, provided 48).
> 
> Additionally, when trying other AES modes, e.g. CBC, there is an
> CryptoPluginNotFound error.
> 
> Is there currently a workaround which would allow us to use a
> Utimaco HSM? Also, are there any plans to natively support HSMs
> from other vendors in the near future?
> 
> Again, thank you for your support.
> 
> Best regards,
> 
> Manuel Roth
> 
> [1]:
> https://github.com/openstack/barbican/blob/306b2ac592c059c59be42c0420a
08af0a9e34f6e/barbican/plugin/crypto/pkcs11.py#L131
>
>  [2]:
> https://github.com/openstack/barbican/blob/c2a7f426455232ed04d2ccef6b3
5c87a2a223977/barbican/plugin/crypto/p11_crypto.py#L63
>
>  --- System Engineering HSM
> 
> Utimaco IS GmbH Germanusstr. 4 52080 Aachen Germany
> 
> 
> 
> -Original Message- From: Douglas Mendizábal
> [mailto:douglas.mendiza...@rackspace.com] Sent: Freitag, 12. August
> 2016 18:24 To: OpenStack Development Mailing List (not for usage
> questions) <openstack-dev@lists.openstack.org> Cc: Ariano-Tim Donda
> <ariano-tim.do...@utimaco.com>; Jiannis Papadakis
> <jiannis.papada...@utimaco.com> Subject: Re: [openstack-dev]
> Barbican: Secure Setup & HSM-plugin
> 
> Hi Manuel,
> 
> I'm happy to hear about your interest in Barbican.  I assume your
> HSM has a PKCS#11 interface since the admin commands to generate
> the MKEK and HMAC keys worked for you.
> 
> The labels for the generated keys should be specified in the config
> file for the API process. [1]  The API process uses the MKEK and
> HMAC keys to encrypt and sign the secrets (keys) that are stored in
> Barbican by clients.
> 
> The PKCS#11 plugin was designed to use the SQL Database to store
> client keys (secrets) in the SQL database, so your API process must
> be configured to use "store_crypto" as the
> enabled_secretstore_plugins [2] in addition to specifing
> "p11_crypto" as the enabled_crypto_plguins [3].
> 
> When configured this way, Barbican uses the HSM to encrypt the
> client data (keys/secrets) before storing it in the DB.
> 
> The API itself does not currently support using keys stored by
> clients to do server-side encryption, but it's a feature that has
> been discussed in previous summits with some interest.  We've also
> had some discussions with the Designate team to add server-side
> signing that they could use to implement DNSSEC, but we don't yet
> have a blueprint for it.
> 
> Let me know if you have any more questions.
> 
> - Douglas Mendizábal
> 
> [1] 
> http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/bar
bi
>
> 
can.conf

Re: [openstack-dev] Barbican: Secure Setup & HSM-plugin

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Manuel,

I'm happy to hear about your interest in Barbican.  I assume your HSM
has a PKCS#11 interface since the admin commands to generate the MKEK
and HMAC keys worked for you.

The labels for the generated keys should be specified in the config
file for the API process. [1]  The API process uses the MKEK and HMAC
keys to encrypt and sign the secrets (keys) that are stored in
Barbican by clients.

The PKCS#11 plugin was designed to use the SQL Database to store
client keys (secrets) in the SQL database, so your API process must be
configured to use "store_crypto" as the enabled_secretstore_plugins
[2] in addition to specifing "p11_crypto" as the
enabled_crypto_plguins [3].

When configured this way, Barbican uses the HSM to encrypt the client
data (keys/secrets) before storing it in the DB.

The API itself does not currently support using keys stored by clients
to do server-side encryption, but it's a feature that has been
discussed in previous summits with some interest.  We've also had some
discussions with the Designate team to add server-side signing that
they could use to implement DNSSEC, but we don't yet have a blueprint
for it.

Let me know if you have any more questions.

- - Douglas Mendizábal

[1]
http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/barbi
can.conf#n278
[2]
http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/barbi
can.conf#n255
[3]
http://git.openstack.org/cgit/openstack/barbican/tree/etc/barbican/barbi
can.conf#n260


On 8/12/16 7:51 AM, Praktikant HSM wrote:
> Hi all,
> 
> As a member of Utimaco's pre-sales team I am currently testing an 
> integration of Barbican with one of our HSMs.
> 
> 
> 
> We were able to generate MKEKs and HMAC keys on the HSM with the 
> 'pkcs11-key-generation' as well as 'barbican-manage hsm' commands. 
> However, it is not fully clear to us how to use these keys to
> encrypt or sign data.
> 
> 
> 
> Additionally, we would appreciate further information concerning
> the secure setup of Barbican with an HSM-plugin.
> 
> 
> 
> Thank you in advance for your support.
> 
> 
> 
> Best regards,
> 
> 
> 
> 
> 
> Manuel Roth
> 
> 
> 
> ---
> 
> System Engineering HSM
> 
> 
> 
> Utimaco IS GmbH
> 
> Germanusstr. 4
> 
> 52080 Aachen
> 
> Germany
> 
> 
> 
> www.utimaco.com <http://www.utimaco.com>
> 
> 
> --
- --
>
>  Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel:
> +49-241-1696-0, www.utimaco.com Seat: Aachen – Registergericht
> Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Malte
> Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO
> 
> This communication is confidential. We only send and receive email
> on the basis of the terms set out at 
> https://www.utimaco.com/en/e-mail-disclaimer/
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXrfg0AAoJEB7Z2EQgmLX7A08QAIpZqMKNDdT8MwM/iLmlDrMz
s/3wh+BErcQ8DHRHfwFijS6R+dm3/lZxzwTFszcRGgnXS90cKkZ0MGfuabne3Ul1
ZaFi7HvN64H34ujWTWBz5aD36yDOQB3bvv/gakI5CAxziQzL+3lAJqZmc7uQBlPA
p1/85zGYCi414ub62Je+DSJe0zW7p8UqfrCWXdTjEC23e00hguSFPuVDgLafkHIa
0HC059Cw4vC1RFyasOa96a5YlPtqGkuHzqJlZmeU14NZX0sSRxqSy4zqE210t8PT
FKp99xbIqWvlvHfcvjbvUN56SCIZUg1NeUAtlD2GP0RhO6/RBb4dMAQ61xy2OmuL
gKtWCJNOzjhqU0VB/pxip5yS/hXFtars1N/T3bmz91GoQXPisR3YF7xQHSoSVpdd
6lrIsQxZwiIP0IHMRKPxhrTgpSWzI9cZ9pquYpYX8YLuGkqYmQMGccD6aa1iaBC+
BMIYOpaS5a6sIIHFzvOeLi/9KpWDcRMIU5y5NG9Yt4jgNzVC5wfLKexmfIzzPztV
4ePECVHr+d5S2KcsP0upNW1dO8RTcFB0yKmGio3+VFJAdCMW7i5GP6+qi8rmYG3t
ZCbNTnU4KIPKb7aWV83m9L2gK2V2BHsznIQX19yQbAe4u3HtTHvrCxvl8mVNaD11
ejBi0uxDrn4zwEWeEVr1
=9c/C
-END PGP SIGNATURE-

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

Re: [openstack-dev] Barbican and Security Midcycle confirmed

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Many thanks to Fernando and IBM for setting this up!

- - Doug Mendizábal

On 7/19/16 1:49 PM, Fernando J Diaz wrote:
> Dear Barbican and Security Contributors,
> 
> It is my pleasure to announce that the Barbican and Security
> Mid-cycle meetups will be held at IBM Austin from August 15 - 19.
> 
> For more information please see
> https://etherpad.openstack.org/p/barbican-security-midcycle-N. We 
> look forward to seeing you!
> 
> Sincerely, Fernando Diaz
> 
> 
> 
> __

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

iQIcBAEBCgAGBQJXjnt5AAoJEB7Z2EQgmLX7Xy8P/iLSCKohU5g9WROg9gOUtDz4
KaVDBpSim2gxTwTw7yyqNkRk6mNODAuOp/O3AhXjcaoEp287FMyoSH4yNkxCiYa7
WMZlJ9ZoKFTCnLgSeOQF0u0xO+ZNxXfZHLc1HRHKXcq7N3hVyLOGdbvX+afYzm2m
tE93YNwyTqhM6J+yob31VKJIwclGjaAPekV6z6x92sTMP84a/s4zl0QQTrRlEAFi
eY4K8m3QP1H+n96nzfr+wJOhDs5a73eGQ/irXk1/7htgAmr9UWLwPGL3t00vk7At
unTE/l5546GaZhA8BozKpAAFWFPVz432wGLejWe9OaKEkcuRfOZGbGbi9mG8Ikam
ZXzSSU5vp92R4fXzpwLOPhqLk6KUcSJuYkRDMRMxUDcRzhubtHoQt+rU8R2its3B
bIP7v35RVAZLVEFpdTEMDpNzaS3GQexPTuxXT+xZayEhttdwd03i4wUWUGbiEJPo
zIW5LL8ltHNgn9dU1P9uqJjsCvMBsSePkUkT8M4q5Seys/IjTZ7j7Kthg0F/inje
E+wdQpOzRyDc4z151lrLqbx1W+zTQwHvjN+nnTxuW2Z9lp1kRgqX42xG//voDOVy
wHn/zcMR7lmgZ/oOw3/I5BFVhp4FeR2zJ5hxid6HwY4tJDoF1dlO9kcBP9ErfQmK
/E4nicK6GA5K4DtSri/y
=FLtR
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Security][Barbican][all] Bring your own key fishbowl sessions

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

No conflicts with your cross-project session as far as I can tell.

In a nutshell BYOK-Push is a model where the customer retains full
control of their cryptographic keys.  The customer is expected to
provide the necessary keys each and every time a request is made that
requires some cryptographic operation.  Amazon S3's SSE-C encryption
[1] would be a good example of this model.

In a BYOK-Pull model, the customer would grant access to their cloud
provider for some key management system inside their private
infrastructure.  For example this model could be used in a hybrid
cloud where the customer has an on-premise barbican that can provide
keys on-demand to the public cloud provider.

+1 to not spending a lot of time talking about a model that no one is
interested in implementing.  My impression at the last joint
Barbican/OSSP mid-cycle was that most people were interested in the
push model.

[1]
http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerSideEncryptionCusto
merKeys.html

On 4/22/16 4:03 PM, Fox, Kevin M wrote:
> Can you please give a little more detail on what its about?
> 
> Does this have any overlap with the instance user session: 
> https://www.openstack.org/summit/austin-2016/summit-schedule/events/94
85
>
>  Thanks, Kevin
> 
> --
- --
>
> 
*From:* Rob C [hyaku...@gmail.com]
> *Sent:* Friday, April 22, 2016 1:44 PM *To:* OpenStack Development
> Mailing List (not for usage questions) *Subject:* Re:
> [openstack-dev] [Security][Barbican][all] Bring your own key
> fishbowl sessions
> 
> So that's one vote for option A and one vote for another vote :)
> 
> On 22 Apr 2016 4:25 p.m., "Nathan Reller"
> >
> wrote:
> 
>> Thoughts?
> 
> Is anyone interested in the pull model or actually implementing it?
> I say if the answer to that is no then only discuss the push
> model.
> 
> Note that I am having a talk on BYOK on Tuesday at 11:15. My talk
> will go over provider key management, the push model, and the pull
> model. There are some aspects of design in it that will likely
> interest people. You might want to take the poll after session
> because I'm not sure how many people know what the differences
> are.
> 
> -Nate
> 
> __

>
> 
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
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXGpu3AAoJEB7Z2EQgmLX7eaAQAKArxp+Pw6jl+4Xz5t9zrOZb
ENSOq049jOrymUolD/VyiicT2llG08LxHlLjfnVthJ7j5+unB6XQLRKLIDAGUCrM
IyTw9SRSjElvQVN6mct/NnePlhipjWf6inqCxpRKE0Bbv2jgOHiYOqZ04yQAxZ/1
aWevqSc2piJhlZmOjTlYbls0O0oTPGw0zkyS0Damja5OIiu45niSQvrnwlbfVTJg
R9ORk0FSNrpvgOBIAFCqLYXhmvrhHkV0+M6aQ4NHy9m05ywe7jq4J2qhcUqY3kqp
b/qNCKlJ25mSlnCcVLYR8iDkLxfLwa7dToCViacnLg2dd7T1l0OhLgbBY1ENHIuw
jvwE3vVz4HPHhk8ArybWvaOepP+cPdPB4fcX5DkatEfI2raCr18yebZ+AfI7/e/v
WtlwLUcG/GxOIQe/PpTF6Y5cRimV62u/Fk3FXZYJnFt2dk+zw9OTzrasZg/RrTVT
UEaMPZXt8AfAVEUNRh2KA1NgFhyvuLIkexSPmmuJ5dxgJ2JmB2OoLF+pNNT5xH4L
bTYuIGt39nuLT8wv9vyovoMuDG6mP8JF0b4LW/2XEfBTPq9LfDlEtmZUqlDhYG2I
FlqP1iN0O1B0X9hG6+fnD+aEga8nx060wNxsioUD2bNmJ6lqYeq8Jj0hIdsjYTAU
xwrWP8UdUfC7GU9oun1Y
=PeQa
-END PGP SIGNATURE-

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

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Answers inline.

On 4/14/16 10:05 AM, Hongbin Lu wrote:
> Castellan is another alternative under consideration [1].
> 
> Would I ask some clarifying questions: * I saw Castellan is using
> release:independent model. What are the rationales of choosing this
> release model over release:cycle-with-intermediary?

release:independent is the default release model for new libs.  AFAIK
nobody has previously asked about having a different release model, so
we haven't had the need to consider other models.

> * If Magnum depends on this library and contributes a Castellan
> backend, who will maintain the backend? Who can review and approve
> bug fixes? Who will release a new package? How fast the whole
> process will be (patch critical fixes -> review -> approve ->
> release)?

If you want to add a new backend that is included as part of Castellan
we would appreciate contributions from your team to help fix bugs,
etc. especially since you would be the main user of a new backend.
That said the barbican-core team is commited to maintaining Castellan
and we are responsible for reviews and releases.  Since Castellan is
released independently the release turnaround is much faster than
waiting for patch reviews from the release management team.

> * I wonder why this library is not managed by Oslo (currently
> managed by barbican-core).

When the Castellan project was concieved we asked the Oslo team to
maintain it.  The oslo team PTL at that time recommended that the
barbican-core team keep ownership of the new repo based on concerns
about domain knowledge. [1]

[1] https://review.openstack.org/#/c/138875/

> 
> In general, I saw the advantages of leveraging Castellan. My major
> concern is the development speed: contributing on external repo
> might slow down the development process. Personally, I lean to
> start everything in our own repo, and push them to a common library
> later.
> 

There is no technical requirement that mandates that implementations
of Castellan be included as part of the Castellan library.  You could
develop an implementation of the Castellan interface in your own
source tree or its own separate repo or wherever you'd like as long as
your implementation conforms to the Castellan interface.  The only
drawback is that your implementation would not be usable outside of
your project.

Just to be clear, the reason I would like for you to use Castellan is
so that deployers can easily use the Barbican implementation when our
service is available in the deployer's cloud.  It would also be
helpful for small-cloud deployments where Castellan could interface
directly with a Hardware Security Module, etc.

I don't particularly care for the Shared DEK+DB model I described
earlier.  My argument was that using that model would be no less
secure than pre-encrypting things to be stored in Keystone, but it
does not provide the security assurances that Barbican provides.  I
doesn't provide the level of auditability that Barbican provides
either.  And implementing a Castellan backend that does all those
things securely definitely sounds like you'd be re-writing Barbican.

At the end of the day, it will be up to the deployer to consider their
threat models and decide how much risk they're willing to accept.  So
if implementing a low-security key management backend is what your
early adopters want, then please do so in a manner that lets deployers
with high security requirements easily use Barbican or other Hardware
solutions.

- - Douglas Mendizábal

> [1] https://etherpad.openstack.org/p/magnum-barbican-alternative
> 
> Best regards, Hongbin
> 
>> -Original Message- From: Nathan Reller
>> [mailto:nathan.s.rel...@gmail.com] Sent: April-14-16 9:22 AM To:
>> OpenStack Development Mailing List (not for usage questions) 
>> Subject: Re: [openstack-dev] [magnum][keystone][all] Using
>> Keystone /v3/credentials to store TLS certificates
>> 
>> I agree with Doug's comments. Castellan is a generic key manager 
>> library that allows symmetric keys, private keys, public keys, 
>> certificates, passphrases, and opaque secret data to be stored in
>> a key manager. There is a Barbican implementation that is
>> complete, and a KMIP (Key Management Interoperability Protocol
>> (an OASIS standard)) implementation is under development.
>> 
>> The precursor to castellan was the KeyManager interface
>> integrated into Nova and Cinder. We are in the process of making
>> the easy switch from that to Castellan. Glance and Sahara have
>> both already integrated with Castellan. Swift is currently
>> integrating with Castellan and will swap between Barbican and
>> KMIP.
>> 
>> -Nate
>> 
>> 
>> 
>> On Wed, Apr 13, 2016 at 3:04 PM, Douglas Mendizábal 
>&

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Hongbin,

I have to admit that it's a bit disappointing that the Magnum team
chose to decouple from Barbican, although I do understand that our
team needs to do a better job of documenting detailed how-tos for
deploying Barbican.

I'm not sure that I understand the Threat Model you're trying to
protect against, and I have not spent a whole lot of time researching
Magnum architecture so please forgive me if my assumptions are wrong.

So that we're all on the same page, I'm going to summarize the TLS
use-case as I understand it:

The magnum-conductor is a single process that may be scalable at some
point in the future. [1]

When the magnum-conductor is asked to provision a new bay the
following things happen:
1. A new self-signed root CA is created.  This results in a Root CA
Certificate and its associated key
2. N number of nodes are created to be part of the new bay.  For each
node, a new x509 certificate is provisioned and signed by the Root CA
created in 1.  This results in a certificate and key pair for each node.
3. The conductor then needs to store all generated keys in a secure
location.
4. The conductor would also like to store all generated Certificates
in a secure location, although this is not strictly necessary since
Certificates contain no secret information as pointed out by Adam
Young elsewhere in this thread.

Currently the conductor is using python-barbicanclient to store the
Root CA and Key in Barbican and associates those secrets via a
Certificate Container and then stores the container URI in the
conductor database.

Since most users of Magnum are unwilling or unable to deploy Barbican
the Magnum team would like an alternative mechanism for storing all
keys as well as the Certificates.

Additionally, since magnum-conductor may be more than one process in
the future, the alternative storage must be available to many
magnum-conductors.

Now, in the proposed Keystone alternative the magnum-conductor will
have a (symmetric?) encryption key.  Let's call this key the DEK
(short for data-encryption-key).  How the DEK is stored and replicated
to other magnum-conductors is outside of the scope of the proposed
alternative solution.
The magnum-conductor will use the DEK to encrypt all Certificates and
Keys and then store the resulting ciphertexts using the Keystone
credentials endpoint.

This begs the question: If you're pre-encrypting all this data with
the DEK, why do you need to store it in an external system?  I see no
security benefit of using Keystone credentials over just storing these
ciphertexts in a table in the database that all magnum-conductors will
already have access to.

I think a better alternative would be to integrate with Castellan and
develop a new Castellan implementation where the DEK is specified in a
config file, and the ciphertexts are stored in a database.  Let's call
this new implementation LocalDEKAndDBKeyManager.

With this approach the deployer could specify the
LocalDEKAndDBKeyManager class as the implementation of Castellan to be
used for their deployment, and then the DEK and db connection string
could be specified in the config as well.

By introducing the Castellan abstraction you would lose the ability to
group secrets into containers, so you'd have to store separate
references for each cert and key instead of just one barbican
reference for both.  Also, you would probably have to write the
Castellan integration in a way that always uses a context that is
generated from the config file which will result in all keys being
owned by the Magnum service tenant instead of the user's tenant when
using Barbican as a backend.

The upshot is that a deployer could choose the existing Barbican
implementation instead, and other projects may be able to make use of
the LocalDEKAndDBKeyManager.

- - Douglas Mendizábal

[1] http://docs.openstack.org/developer/magnum/#architecture

On 4/13/16 10:14 AM, Hongbin Lu wrote:
> I think there are two questions here:
> 
> 1.   Should Magnum decouple from Barbican?
> 
> 2.   Which options Magnum should use to achieve #1 (leverage 
> Keystone credential store, or other alternatives [1])?
> 
> For question #1, Magnum team has thoughtfully discussed it. I think
> we all agreed that Magnum should decouple from Barbican for now (I
> didn’t hear any disagreement from any of our team members). What we
> are currently debating is question #2. That is which approach we
> should use to achieve the goal. The first option is to store TLS
> credentials in Keystone. The second option is to store the
> credentials in Magnum DB. The third option is to eliminate the need
> to store TLS credentials (e.g. switch to another non-TLS
> authentication mechanism). What we want to know is if Keystone team
> allows us to pursue the first option. If it is disallowed, I will
> suggest Magnum team to pursue other options.
> 
> So, for the origina

Re: [openstack-dev] [Security][Barbican] BYOK

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Rob,

The Barbican team is dedicating a Fishbowl session to BYOK for the summi
t:

https://www.openstack.org/summit/austin-2016/summit-schedule/events/9155

- - Doug


On 4/6/16 5:12 AM, Clark, Robert Graham wrote:
> Hi All,
> 
> We’ve had lots of discussion about BYOK and most of it has lead to
> “lets discuss it at the summit”.
> 
> I’ve got some time for this in the security schedule, I’m checking
> – is there some other place where this is already tabled to be
> discussed?
> 
> -Rob 
> __

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

iQIcBAEBCgAGBQJXBYAvAAoJEB7Z2EQgmLX7qIQQAJ1lQfLuL9vbbAwRMf4JFwWg
nD4aJfMfa029YLf9ub0gqFNOozmNuAtr2k8umZl7Z+RewEUlo6pzL17T0zh01cIU
uhImGWF6XPO+DTO/yrRlEprxqQCjRnyn56ucxTQ3Jh2r78omhFnnwq1N8atHcj0V
Sf5SV8DwrHVQeODQsJA7G2+lkiTEhg6S/p7lx4sOPaSIFjJ5Qar/O8JnTWRgGWk1
U4xU9r5ZE7hGAnQeU8NMIEZ7wEQBNnYEwU9hVK4zbCjt1sHgQJo0H5PEeOu+YG7z
MGjaGvUfrtwzVQyVH8B28YvwzIX3G0uAsMM3+e1scPbiy8G98SB6llqKdeX2qgb0
A/wHpfJdtF3I4m2SXn92Gtor5UxqddJznwJjVOZIMaJ6RSyVMvUeVvat/qcI0/kC
JURem11m/OyzdRtG5ckNl84c4Y/g90vIbbdOcgabtq/JPeMtGyFg7G0hFPDkaqLW
n8sBBN7iy5ioGdQEoXvDeURyd/PbVRL9KIsBDzTDRVpx8gO5WeMsw9HlD/sEgHvs
KWNI41cKasGLHFMP0uP418WvsAbqz+KmNZk+bh7jxIM3I8eQ9U3AFpYciHcCXhOd
M6y0WTpWFSXX0iS4KBHE6VUyEZ9Pidx2ZHy/VpLJxpZURvrQY6cS5u2ZOqexROQw
1LV2GT2D+XU5flUK4RtG
=lyPG
-END PGP SIGNATURE-

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

Re: [openstack-dev] [kite] Seeking core reviewers

[Douglas Mendizábal]

Thanks for the patches, Ronald.  Adam Young is right, Kite is pretty
much dead.

I'll add to my list of spring cleaning to-dos to remove Kite from
governance and infra.

Thanks,
Douglas Mendizábal (redrobot)

On 3/25/16 10:08 AM, Ronald Bradford wrote:
> Thanks all for feedback.
> 
> I have proposed a non maintained patch [1] based on comments here.
> I will speak with the Barbican team.
> 
> Ronald
> 
> [1] https://review.openstack.org/#/c/297719/
> 
> 
> Ronald Bradford
> 
> Web Site: http://ronaldbradford.com <http://ronaldbradford.com/>
> LinkedIn:  http://www.linkedin.com/in/ronaldbradford
> Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
> Skype: RonaldBradford
> GTalk: Ronald.Bradford
> IRC: rbradfor
> 
> 
> On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez <thie...@openstack.org
> <mailto:thie...@openstack.org>> wrote:
> 
> Ian Cordasco wrote:
> 
> I believe Kite is no longer actively developed or maintained and
> was started by the Barbican folks. You should find them in
> #openstack-barbican.
> 
> 
> Yeah. It's still technically a repository under the Barbican team.
> Someone from Barbican should propose a governance change to get rid
> of it (or approve someone else's change getting rid of it).
> 
> Keeping abandoned repositories in your official list does not
> reflect well on your project team (or OpenStack in general).
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> 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
> 



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

Re: [openstack-dev] [magnum] Streamline adoption of Magnum

[Douglas Mendizábal]

Comments inline.

- Douglas Mendizábal

On 3/23/16 5:15 PM, Fox, Kevin M wrote:
> So, this is where things start getting a little ugly and undefined... This is 
> what I've been able to gather so far, so please someone correct me if I'm 
> wrong.
> 
> Barbican is the OpenStack secret manager. It provides a standard OpenStack 
> api for users to be able store/retrieve secrets... Its plugable and in 
> theory, you could add a vault plugin to it. Barbican is then your abstraction 
> layer.
> 

This is absolutely correct, and it's a point that I'm starting to think
is not very well understood outside of the Barbican and Security teams.
 Barbican is not in-and-of-itself a key management solution.  It
requires some backend to be used where the actual secret storage is
done.  This could be a PKCS#11 Hardware Security Module like we use at
Rackspace, or it could be a KMIP HSM, or DogTag, or Hashicorp Vault.

In a similar way in which Keystone can use a deployers existing identity
system, Barbican should be able to use an existing key management
system.   So I agree that integrations with other key managers belong in
Barbican as a SecretStore plugin.

> Separate from that, is Castellan. Which is a plugable abstraction library at 
> the client side. So a Vault plugin could be create for it instead.
> 

I think Castellan is attractive to projects looking for secure
storage/retrieval of secrets because it superficially avoids a hard
dependency on Barbican.  The problem with using Castellan is that
because it's a common-lowest-denominator secret storage it cannot
provide the features that Barbican provides.

One of the features that Barbican provides that Castellan cannot is that
of multi-tenancy.  So projects that choose to use Castellan are limited
to a single account on the key manager backend that is chosen at
deployment time.  This results in all secrets being "owned" by the
service itself instead of the users they're associated with.

Another feature that Barbican provides that Castellan cannot is that of
Scalability.  The PKCS#11 Plugin in Barbican can provide virtually
unlimited storage capacity while still providing the security assurances
of the HSM backend.  But when you choose Castellan, you will be limited
by the capacity of the service used in the backend.

And while there is a Castellan->Barbican implementation, it only
provides scalability, but it loses the multi-tenancy.


> My personal preference is to have a standard rest api over having a standard 
> python client api in a cloud. Its more the OpenStack way. I'll leave it up to 
> other sources to get into why a rest api's better.
> 
> That being said, there's still the elephant in the room I think of:
> 
> How do you securely get a secret to the vm, to allow you to get secrets from 
> the secret store? I've been working on that use case for over a year now with 
> little traction. :/ 
> 
> Either Castellan, Barbican, or talking directly to Vault will have that 
> issue. How do you validate your vm with that service.
> 
> The current endeavor to address the situation is located here: 
> https://review.openstack.org/#/c/93/
> 

Thanks for fighting the good fight, Kevin.  I'm still hopeful that we
can solve this problem.

> We really need to get all the OpenStack projects together and address this 
> issue as a whole. Everyone's now trying or has already worked around it in 
> some not so nice ways. Amazon has had a solution for years now. Why can't we 
> address it?
> 
> Thanks,
> Kevin
> 
> 
> 
> 
> From: Ian Cordasco [sigmaviru...@gmail.com]
> Sent: Wednesday, March 23, 2016 2:45 PM
> To: Monty Taylor; OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [magnum] Streamline adoption of Magnum
> 
> -Original Message-
> From: Monty Taylor <mord...@inaugust.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 22, 2016 at 18:49:41
> To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [magnum] Streamline adoption of Magnum
> 
>> On 03/22/2016 06:27 PM, Kevin Carter wrote:
>>> /me wearing my deployer hat now: Many of my customers and product folks
>>> want Magnum but they also want magnum to be as secure and stable as
>>> possible. If Barbican is the best long term solution for the project it
>>> would make sense to me that Magnum remain on course with Barbican as the
>>> defacto way of deploying in production. IMHO building alternative means
>>> for certificate management is a distraction and will only confuse folks
>>> looking to deploy Magnum into production.
>>
>&g

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

[Douglas Mendizábal]

test suite to make sure everything is still good.  If the
tests all pass the new blue set is promoted to green, and the
previously-green set is slowly demoted to blue.

We keep the now-blue nodes around in case something breaks and we need
to quickly roll back to the previous version.  If all goes well in
staging we do it all over again in prod.  The whole thing is driven
through Jenkins using ansible for configuration management.  It's not
fully automated in the sense that someone still has to push the button
in Jenkins to get things going, but once we mature our pipeline a bit
more we plan to set it on cruise control.

Next steps for us after we sort out PCKS#11 performance will be to
deploy an HA RabbitMQ, and N api-workers.  I don't think we'll be
setting up the keystone-listeners any time soon.

I hope that gives you a good starting point for planning your
HA-Barbican delpoyment.  Let me know if you have any more questions.

Regards,
Douglas Mendizábal


[1] http://www.haproxy.org/
[2] http://www.keepalived.org/
[3] http://martinfowler.com/bliki/BlueGreenDeployment.html
[4] http://www.openrepose.org/
[5] https://github.com/rackerlabs/plight
[6] https://downloads.mariadb.org/mariadb-galera/
[7]
http://www.safenet-inc.com/data-encryption/hardware-security-modules-hsms/luna-hsms-key-management/luna-sa-network-hsm/

On 3/21/16 1:23 PM, Daneyon Hansen (danehans) wrote:
> All,
> 
> Does anyone have experience deploying Barbican in a highly-available
> fashion? If so, I'm interested in learning from your experience. Any
> insight you can provide is greatly appreciated.
> 
> Regards,
> Daneyon Hansen
> 
> 
> __
> 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
> 




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

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

[Douglas Mendizábal]

Hongbin,

I'm looking forward to discussing this further at the Austin summit.
I'm very interested in learning more about the negative feedback you're
getting regarding Barbican, so that our team can help alleviate those
concerns where possible.

Thanks,
- Douglas

On 3/18/16 10:18 AM, Hongbin Lu wrote:
> Douglas,
> 
> I am not opposed to adopt Barbican in Magnum (In fact, we already adopted 
> Barbican). What I am opposed to is a Barbican lock-in, which already has a 
> negative impact on Magnum adoption based on our feedback. I also want to see 
> an increase of Barbican adoption in the future, and all our users have 
> Barbican installed in their clouds. If that happens, I have no problem to 
> have a hard dependency on Barbican.
> 
> Best regards,
> Hongbin
> 
> -----Original Message-
> From: Douglas Mendizábal [mailto:douglas.mendiza...@rackspace.com] 
> Sent: March-18-16 9:45 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [magnum] High Availability
> 
> Hongbin,
> 
> I think Adrian makes some excellent points regarding the adoption of 
> Barbican.  As the PTL for Barbican, it's frustrating to me to constantly hear 
> from other projects that securing their sensitive data is a requirement but 
> then turn around and say that deploying Barbican is a problem.
> 
> I guess I'm having a hard time understanding the operator persona that is 
> willing to deploy new services with security features but unwilling to also 
> deploy the service that is meant to secure sensitive data across all of 
> OpenStack.
> 
> I understand one barrier to entry for Barbican is the high cost of Hardware 
> Security Modules, which we recommend as the best option for the Storage and 
> Crypto backends for Barbican.  But there are also other options for securing 
> Barbican using open source software like DogTag or SoftHSM.
> 
> I also expect Barbican adoption to increase in the future, and I was hoping 
> that Magnum would help drive that adoption.  There are also other projects 
> that are actively developing security features like Swift Encryption, and 
> DNSSEC support in Desginate.  Eventually these features will also require 
> Barbican, so I agree with Adrian that we as a community should be encouraging 
> deployers to adopt the best security practices.
> 
> 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.
> 
> - Doug
> 
> On 3/17/16 8:45 PM, Hongbin Lu wrote:
>> Thanks Adrian,
>>
>>  
>>
>> I think the Keystone approach will work. For others, please speak up 
>> if it doesn't work for you.
>>
>>  
>>
>> Best regards,
>>
>> Hongbin
>>
>>  
>>
>> *From:*Adrian Otto [mailto:adrian.o...@rackspace.com]
>> *Sent:* March-17-16 9:28 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* Re: [openstack-dev] [magnum] High Availability
>>
>>  
>>
>> Hongbin,
>>
>>  
>>
>> I tweaked the blueprint in accordance with this approach, and approved 
>> it for Newton:
>>
>> https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-sto
>> re
>>
>>  
>>
>> I think this is something we can all agree on as a middle ground, If 
>> not, I'm open to revisiting the discussion.
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Adrian
>>
>>  
>>
>> On Mar 17, 2016, at 6:13 PM, Adrian Otto <adrian.o...@rackspace.com
>> <mailto:adrian.o...@rackspace.com>> wrote:
>>
>>  
>>
>> Hongbin,
>>
>> One alternative we could discuss as an option for operators that
>> have a good reason not to use Barbican, is to use Keystone.
>>
>> Keystone credentials store:
>> 
>> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-ap
>> i-v3.html#credentials-v3-credentials
>>
>> The contents are stored in plain text in the Keystone DB, so we
>> would want to generate an encryption key per bay, encrypt the
>> certificate and store it in keystone. We would then use the same key
>> to decrypt it upon reading the key back. This might be an acceptable
>> middle ground for clouds that will not or can not run Barbican. This
>> should work for any OpenStack cloud since Grizzly. The total amount
>> of code in Magnum would be small, as the API already exists. We
>> would need a library function to encrypt and decrypt the data, and
>> ide

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

[Douglas Mendizábal]

Hongbin,

I think Adrian makes some excellent points regarding the adoption of
Barbican.  As the PTL for Barbican, it's frustrating to me to constantly
hear from other projects that securing their sensitive data is a
requirement but then turn around and say that deploying Barbican is a
problem.

I guess I'm having a hard time understanding the operator persona that
is willing to deploy new services with security features but unwilling
to also deploy the service that is meant to secure sensitive data across
all of OpenStack.

I understand one barrier to entry for Barbican is the high cost of
Hardware Security Modules, which we recommend as the best option for the
Storage and Crypto backends for Barbican.  But there are also other
options for securing Barbican using open source software like DogTag or
SoftHSM.

I also expect Barbican adoption to increase in the future, and I was
hoping that Magnum would help drive that adoption.  There are also other
projects that are actively developing security features like Swift
Encryption, and DNSSEC support in Desginate.  Eventually these features
will also require Barbican, so I agree with Adrian that we as a
community should be encouraging deployers to adopt the best security
practices.

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.

- Doug

On 3/17/16 8:45 PM, Hongbin Lu wrote:
> Thanks Adrian,
> 
>  
> 
> I think the Keystone approach will work. For others, please speak up if
> it doesn’t work for you.
> 
>  
> 
> Best regards,
> 
> Hongbin
> 
>  
> 
> *From:*Adrian Otto [mailto:adrian.o...@rackspace.com]
> *Sent:* March-17-16 9:28 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [magnum] High Availability
> 
>  
> 
> Hongbin,
> 
>  
> 
> I tweaked the blueprint in accordance with this approach, and approved
> it for Newton:
> 
> https://blueprints.launchpad.net/magnum/+spec/barbican-alternative-store
> 
>  
> 
> I think this is something we can all agree on as a middle ground, If
> not, I’m open to revisiting the discussion.
> 
>  
> 
> Thanks,
> 
>  
> 
> Adrian
> 
>  
> 
> On Mar 17, 2016, at 6:13 PM, Adrian Otto  > wrote:
> 
>  
> 
> Hongbin,
> 
> One alternative we could discuss as an option for operators that
> have a good reason not to use Barbican, is to use Keystone.
> 
> Keystone credentials store:
> 
> http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#credentials-v3-credentials
> 
> The contents are stored in plain text in the Keystone DB, so we
> would want to generate an encryption key per bay, encrypt the
> certificate and store it in keystone. We would then use the same key
> to decrypt it upon reading the key back. This might be an acceptable
> middle ground for clouds that will not or can not run Barbican. This
> should work for any OpenStack cloud since Grizzly. The total amount
> of code in Magnum would be small, as the API already exists. We
> would need a library function to encrypt and decrypt the data, and
> ideally a way to select different encryption algorithms in case one
> is judged weak at some point in the future, justifying the use of an
> alternate.
> 
> Adrian
> 
> 
> On Mar 17, 2016, at 4:55 PM, Adrian Otto  > wrote:
> 
> Hongbin,
> 
> 
> On Mar 17, 2016, at 2:25 PM, Hongbin Lu  > wrote:
> 
> Adrian,
> 
> I think we need a boarder set of inputs in this matter, so I moved
> the discussion from whiteboard back to here. Please check my replies
> inline.
> 
> 
> I would like to get a clear problem statement written for this.
> As I see it, the problem is that there is no safe place to put
> certificates in clouds that do not run Barbican.
> It seems the solution is to make it easy to add Barbican such that
> it's included in the setup for Magnum.
> 
> No, the solution is to explore an non-Barbican solution to store
> certificates securely.
> 
> 
> I am seeking more clarity about why a non-Barbican solution is
> desired. Why is there resistance to adopting both Magnum and
> Barbican together? I think the answer is that people think they can
> make Magnum work with really old clouds that were set up before
> Barbican was introduced. That expectation is simply not reasonable.
> If there were a way to easily add Barbican to older clouds, perhaps
> this reluctance would melt away.
> 
> 
> Magnum should not be in the business of credential storage when
> there is an existing service focused on that need.
> 
> Is there an issue with running Barbican on older clouds?
> 

Re: [openstack-dev] [release][all][ptl] preparing to create stable/mitaka branches for libraries

[Douglas Mendizábal]

python-barbicanclient 4.0.0 is ready to be branched.

- Douglas Mendizábal

On 3/9/16 11:26 AM, Doug Hellmann wrote:
> It's time to start opening the stable branches for libraries. I've
> prepared a list of repositories and the proposed versions from which
> we will create stable/mitaka branches, and need each team to sign off on
> the versions. If you know you intend to release a bug fix version in
> the next couple of days, we can wait to avoid having to backport
> patches, but otherwise we should go ahead and create the branches.
> 
> I will process each repository as I hear from the owning team.
> 
> openstack/ceilometermiddleware 0.4.0
> openstack/django_openstack_auth 2.2.0
> openstack/glance_store 0.13.0
> openstack/ironic-lib 1.1.0
> openstack/keystoneauth 2.3.0
> openstack/keystonemiddleware 4.3.0
> openstack/os-brick 1.1.0
> openstack/os-client-config 1.16.0
> openstack/pycadf 2.1.0
> openstack/python-barbicanclient 4.0.0
> openstack/python-brick-cinderclient-ext 0.1.0
> openstack/python-ceilometerclient 2.3.0
> openstack/python-cinderclient 1.6.0
> openstack/cliff 2.0.0
> openstack/python-designateclient 2.0.0
> openstack/python-glanceclient 2.0.0
> openstack/python-heatclient 1.0.0
> openstack/python-ironic-inspector-client 1.5.0
> openstack/python-ironicclient 1.2.0
> openstack/python-keystoneclient 2.3.1
> openstack/python-manilaclient 1.8.0
> openstack/python-neutronclient 4.1.1
> openstack/python-novaclient 3.3.0
> openstack/python-saharaclient 0.13.0
> openstack/python-swiftclient 3.0.0
> openstack/python-troveclient 2.1.0
> openstack/python-zaqarclient 1.0.0
> 
> __
> 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
> 



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

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

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Thanks for the +1s everyone.  Since there have been no objections, I'd
like to welcome Fernando to the Barbican Core team.

Thanks,
- - Douglas Mendizábal

On 2/17/16 11:33 AM, John Wood wrote:
> +1
> 
> On 2/16/16, 12:52 PM, "Ade Lee" <a...@redhat.com> wrote:
> 
>> +1
>> 
>> On Mon, 2016-02-15 at 11:45 -0600, Douglas Mendizábal wrote:
>>> 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 
>>> 
_
>>>
>>> 
_
>>> OpenStack Development Mailing List (not for usage questions) 
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubs cribe 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>> 

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

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

iQIcBAEBCgAGBQJWyyK9AAoJEB7Z2EQgmLX7ROgP/jNKnLb+e6hOq8849PPoPLgb
NcmCiJvwDaalOMxlaRir4e7eVcvgzqazptwXZjWK2Pd40z5xoRQ+P6YogVl9XJiv
Crxvq7Dv7I0R0qE1bsOaxXuje/z7EcXBJIPMOxahk1UI9SPFvZk688CKXqTiQlER
nfRRT43lIac5qvtsVUiCioy4OkaHjCXp1rJ/sjWd5HTKPO1iHFCVHzVoh7VTcbLi
mLce0jKxpHQKTr9XniUiCTPd7yO9j1m6iBLKZ31RpZz4alhCxzf2P6MaDA1Q36qC
JxMG67CD3bfPtTCS9bZreL/MhHs/vGlYrVUB3k61N5lX2oi0W1ka3R3baocoBJpZ
kRnjpkTAUw81Y0e9GvY5mRkTXv3Mt2ltXvJ4aKgmU/1EQ7T5xJg7uC1yTFlLDxM4
O5b/9ZmuV+rqdK95r5U4UcJhh7yAfjSJHoNMGNXirD7/E9xo3F0WeIy3TyqdeW7R
0RpNGEIBvWdmYJ8fhd4mWborFtSEuVjGUw2DHov6K8xpoer6P1MX5Ye++w+4P+e9
qXvgudalqS9ervb3ZeCs3geGwBvYP6sS3pFDOUzToGT/4HojTRQ73nTufn4+VRlI
/XUPrI+D+Zdilv5fcNLz/z8i7PAooRRZpWYmBDZ8KxObSffO/g3cNwyT3FFNpvfA
SkMnK5qXjBf4FfcjI6Qo
=GSYU
-END PGP SIGNATURE-

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

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One more thing: I forgot to point out that pyca/cryptography is
already part of global-requirements. [1]

- - Douglas Mendizábal

[1]
http://git.openstack.org/cgit/openstack/requirements/tree/global-require
ments.txt#n25

On 2/15/16 12:24 PM, Douglas Mendizábal wrote:
> I had not previously heard of pycryptodome. Is this supposed to be 
> a drop-in replacement for pycrypto?  If so then it sounds like 
> they're doing a terrible job of it.
> 
> The plan for Barbican has been to wait for pyca/cryptography [1] to
> add support for the apis we needed to be able to drop our pycrypto
> dependency.  I'll have to double check the latest pyca/cryptography
> notes, but I do believe it's at a point now where it can be used in
> Barbican to replace pycrypto. This would be the preferred fix for
> us.
> 
> AFAIK the paramiko folks were going to adopt pyca/cryptography as 
> well, so it appears that pycryptodome support will not be merged 
> there either. [2]
> 
> Additionaly, bespoke pure-python cryptography gives me the heebie 
> jeebies, so I would strongly recommend to move all cryptographic 
> work to use pyca/cryptography instead of pycryptodome.
> 
> - Douglas Mendizábal
> 
> [1] https://cryptography.io/en/latest/ [2] 
> https://github.com/paramiko/paramiko/pull/646
> 
> On 2/15/16 6:44 AM, Haïkel wrote:
>> 2016-02-14 23:16 GMT+01:00 Davanum Srinivas <dava...@gmail.com>:
>>> Hi,
>>> 
>>> Short Story: pycryptodome if installed inadvertently will
>>> break several projects: Example : 
>>> https://review.openstack.org/#/c/279926/
>>> 
>>> Long Story: There's a new kid in town pycryptodome: 
>>> https://github.com/Legrandin/pycryptodome
>>> 
>>> Because pycrypto itself has not been maintained for a while: 
>>> https://github.com/dlitz/pycrypto
>>> 
>>> So folks like pysaml2 and paramiko are trying to switch over: 
>>> https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbf
b
>
>>>
>>> 
de6b41ac63
>>> 
>>> 
>>> 
>>> 
> https://github.com/paramiko/paramiko/issues/637
>>> 
>>> In fact pysaml2===4.0.3 has already switched over. So the 
>>> requirements bot/script has been trying to alert us to this
>>> new dependency, you can see Nova fail. 
>>> https://review.openstack.org/#/c/279926/
>>> 
>>> Why does it fail? For example, the new library is strict about 
>>> getting bytes for keys and has dropped some parameters in 
>>> methods. for example: 
>>> https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/Pub
l
>
>>>
>>> 
icKey/RSA.py#L405
>>> 
>>> 
>>> 
>>> 
> https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA
.p
>
>
> 
y#L499
>>> 
>>> Another problem, if pycrypto gets installed last then things 
>>> will work, if it pycryptodome gets installed last, things will
>>>  fail. So we definitely cannot allow both in our 
>>> global-requirements and upper-constraints. We can always try to
>>> pin stuff, but things will fail as there are a lot of jobs that
>>> do not honor upper-constraints. And things will fail in the
>>> field for Mitaka.
>>> 
>>> Action: So what can we do? One possibility is to pin 
>>> requirements and hope for the best. Another is to tolerate the 
>>> install of either pycrypto or pycryptodome and test both 
>>> combinations so we don't have to fight this battle.
>>> 
>>> Example for Nova : https://review.openstack.org/#/c/279909/ 
>>> Example for Glance : https://review.openstack.org/#/c/280008/ 
>>> Example for Barbican : 
>>> https://review.openstack.org/#/c/280014/
>>> 
>>> What do you think?
>>> 
>>> Thanks, Dims
>>> 
> 
>> This is annoying from a packaging PoV.
> 
>> We have dependencies relying on pycrypto (e.g oauthlib used by 
>> keystone, paramiko by even more projects), and we can't control 
>> the order of installation. My 2 cts will be to favor the latter 
>> solution and test both combinations until N or O releases (and 
>> then get rid of pycrypto definitively), so we can handle this 
>> gracefully.
> 
> 
>> Regards, H.
> 
>> _
_
>
>>
>> 

> 
> 
> 
> 
> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subje

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I had not previously heard of pycryptodome. Is this supposed to be a
drop-in replacement for pycrypto?  If so then it sounds like they're
doing a terrible job of it.

The plan for Barbican has been to wait for pyca/cryptography [1] to
add support for the apis we needed to be able to drop our pycrypto
dependency.  I'll have to double check the latest pyca/cryptography
notes, but I do believe it's at a point now where it can be used in
Barbican to replace pycrypto. This would be the preferred fix for us.

AFAIK the paramiko folks were going to adopt pyca/cryptography as
well, so it appears that pycryptodome support will not be merged
there either. [2]

Additionaly, bespoke pure-python cryptography gives me the heebie
jeebies, so I would strongly recommend to move all cryptographic work
to use pyca/cryptography instead of pycryptodome.

- - Douglas Mendizábal

[1] https://cryptography.io/en/latest/
[2] https://github.com/paramiko/paramiko/pull/646

On 2/15/16 6:44 AM, Haïkel wrote:
> 2016-02-14 23:16 GMT+01:00 Davanum Srinivas <dava...@gmail.com>:
>> Hi,
>> 
>> Short Story: pycryptodome if installed inadvertently will break 
>> several projects: Example : 
>> https://review.openstack.org/#/c/279926/
>> 
>> Long Story: There's a new kid in town pycryptodome: 
>> https://github.com/Legrandin/pycryptodome
>> 
>> Because pycrypto itself has not been maintained for a while: 
>> https://github.com/dlitz/pycrypto
>> 
>> So folks like pysaml2 and paramiko are trying to switch over: 
>> https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbfb
de6b41ac63
>>
>>
>>
>> 
https://github.com/paramiko/paramiko/issues/637
>> 
>> In fact pysaml2===4.0.3 has already switched over. So the 
>> requirements bot/script has been trying to alert us to this new 
>> dependency, you can see Nova fail. 
>> https://review.openstack.org/#/c/279926/
>> 
>> Why does it fail? For example, the new library is strict about 
>> getting bytes for keys and has dropped some parameters in 
>> methods. for example: 
>> https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/Publ
icKey/RSA.py#L405
>>
>>
>>
>> 
https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA.p
y#L499
>> 
>> Another problem, if pycrypto gets installed last then things
>> will work, if it pycryptodome gets installed last, things will
>> fail. So we definitely cannot allow both in our
>> global-requirements and upper-constraints. We can always try to
>> pin stuff, but things will fail as there are a lot of jobs that
>> do not honor upper-constraints. And things will fail in the field
>> for Mitaka.
>> 
>> Action: So what can we do? One possibility is to pin requirements
>> and hope for the best. Another is to tolerate the install of
>> either pycrypto or pycryptodome and test both combinations so we
>> don't have to fight this battle.
>> 
>> Example for Nova : https://review.openstack.org/#/c/279909/ 
>> Example for Glance : https://review.openstack.org/#/c/280008/ 
>> Example for Barbican : https://review.openstack.org/#/c/280014/
>> 
>> What do you think?
>> 
>> Thanks, Dims
>> 
> 
> This is annoying from a packaging PoV.
> 
> We have dependencies relying on pycrypto (e.g oauthlib used by 
> keystone, paramiko by even more projects), and we can't control
> the order of installation. My 2 cts will be to favor the latter 
> solution and test both combinations until N or O releases (and then
> get rid of pycrypto definitively), so we can handle this 
> gracefully.
> 
> 
> Regards, H.
> 
> __

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

iQIcBAEBCgAGBQJWwhehAAoJEB7Z2EQgmLX7ZvwP/1a4vWgVeryvJGXNP/O5aoml
hvlvJCcJrW0vyRfycQBN4nNSVZLrhjxy+5XIW86/OjfDVnSci2hdI+zKwoGpSrDM
NEi80j6ll31QLBQMDVlNvwv/5DGukJ1fjN35IhHMwWYCBBOU7VGFUuBhdwi47vW4
qHI99Rkf1P6wpVygPTRMye0Z9T249XiYtDckverqEGT7jsYu0SBbK3ti/zbcSmXw
upSAQRYa9GIklVe3GMd0CiD933YsxpCOqGtuhtwslPlbCh0Pd23FbRLFf+Sufojl
9hky7dbl/gKFjf2tHaenYdFun+mlP7bKpYzJ+Hghszw3BACpXeK+U+dcdg9wJTgy
POejML3Kuo5jYnCmWahWuNCuSHepace2E36nm0hsAcC5ntePrKHI31fo9nmiyz/4
1XmUQ96HEl2CUVWFpcYbencf+412o3RGpETita26gUOK+iiBemEA4WWmfAI+9uo0
v3b014Jpyth25CV6uB4vSotbk5p191EBPaUVR7kMhMfx2YJZFWMXD+Hifi72vWjs
oSpoojTiDCj6ctEocTGGnnqMSaO8bNjLOk5fvO0IyLcEjkLrMZEeXS8UsCsyMuQ5
XNncop2G6ABWbrrkpwkAJMoOoHqjQ48DDlPd4qHAJueYh6ENJr/WOVftG7htESo/
BTUtLmCOHdtR05xVf3Hn
=t6oe
-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-dev] [barbican] Nominating Fernando Diaz for Barbican Core

[Douglas Mendizábal]

-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

Re: [openstack-dev] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Why would we not want to include a fixed-key backend in Castellan?  As
long as we make it clear that the fixed-key implementation is insecure
and should not be used in production systems I see no harm in
including it as part of the Castellan package.

In fact, I think it would ease the ramp up time for potential
Castellan adopters.  If we included a fixed-key impl, then someone
could just pip install castellan and start kicking tires in the repl.
 Otherwise someone who is merely evaluating Castellan would have to go
down the path of standing up a Barbican instance.

- - Douglas Mendizábal

On 1/5/16 3:58 PM, Farr, Kaitlin M. wrote:
>>> Aiming toward tests that mirror real-world deployment is
>>> certainly a good thing, but I don't think we should remove
>>> ConfKeyManager.
>>> 
>>> We will want to maintain the ability to test these Cinder/Nova
>>> code paths in development environments or in some automated
>>> environments without requiring additional services to be
>>> configured.
>>> 
>>> We can address this by having ConfKeyManager emit warning
>>> messages indicating that it isn't for production environments.
>> 
>> Right, effectively the fixed key manager was a Testing Fixture
>> for us. That's really important because it reduces the number of
>> moving parts when testing this stuff as a full stack.
>> 
>> -Sean
> 
> Ok, I am looking into a way to keep a fixed-key back end, but it
> will not live in Castellan.
> 
> Even if we keep the fixed-key back end, what about adding a gate
> that tests the encryption features using Barbican? Would the
> community be supportive if I added that gate?
> 
> 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
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWjE8zAAoJEB7Z2EQgmLX7kq4QAIrWs0SlX7ELbrA8XDH3Dfzd
X3Omc32/4b7WbQhF9qu7hmZeGDLBwAg9mSpqEATz7YQJdfEu9DN3WdPnWwsx8JiJ
N0FQUPxo5QcsZGnVMnLZezTPJ7cB+NNpDDb7VWU5gKwwNVgRvCJRv6XZ5lXo9SEP
sg6pE7xwBmT3pwIunWh6WIBpDSzmr/87bPUgkLHb30+grv9GlnHiGvaIc9VOF7Nc
wISFIryn1uqJAfHd0j268KpueM9JLs0fP3raWthJ/xqT7iUKgpp0iIeM0HsEj6D5
UHZqcBAtbhMED/8NuMfIJlXK0i8lTjp6omrBJQM81NeukCeLRZRqoJM1NuvjoaiY
eRUyk3W2tMJcfoowFxWkWFBU7/cxWkXhZmbDAUrJ55KdkewBs6Uuz/lJmUGe4sCI
pn8ROv7jAnTyZdVnRn5ybggTjAEl7Ug8DAu7RRxm06BWtbHgtmBhBQZTDDfRDIUl
KSX1JnP0Js7+GDm/inA/FrYSvQwB+m/bbR86evP8izVGXNF6GhjgBkmtL5GABGqr
sa8UbG8EtMZ+3mPpXlNoFvkptKbay0mpECW86srbXTrDS8W7Licrv6mZ4mn3NjOr
HYgcPp/KoHVn1hmiFcNqH+5Y9N6Wh9Vs+hXwgsBG754WpsTc+qi/FjTSjr8RSZyA
ZS2CXxni08/U5xQ/tNqE
=hy9D
-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-dev] [barbican] Weekly meetings cancelled for Summit

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Barbicaneers,

Since a lot of us are going to be traveling to Tokyo for the Summit
next week, I figured we should probably cancel the next couple of
weekly meetings.  The next weekly meeting will be on Nov 9 @ 2000 UTC.

Thanks,
Douglas Mendizábal
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWKmDgAAoJEB7Z2EQgmLX7ApMP/inPg02zYeAPg7eBifkyRCR2
YOdlTQUO8aUjk1rF5ZrFuuqvutXe7HPfU1ZsWDHX/8F4nYJQhfUgprv0iTEG3fY2
KC0A0oFbMex8CHuCyLNOQtJAkIQRXdVWZwP8ynz/Yl5l5jzSc5UaN1AwcnRuf4eV
7srcFny/vsb4ZAhdq3LgqsJibijggUt6o3DKOypFt5G8eyjjkGZajtlg3VHBrnly
EG0hPNIRbrzxuI9OtsfICHUotOqou1iaN+6toFkGYE+aYRhua5O0BjRewyWhrLg+
333A09I1Fd8q8XrO3kAvo1Pm6Ax/x/TzH1YouJWCcEb45m9C8FOSLMnkte5ZunYM
foj9iv+wexZxQTBybWBRyOKVeIQxRr30QLwIq4O/h81LNw/BO+XjIoeMaaLD33Xk
iPYkt0c6DWgXE3IM+rhwDDf4ikv/M8jFu6MyLeJnncKSdeB4yBV9v75ihhQZC7R3
oHrnhoTz4WibWDOxU2kM7EU+px1WtjJNySDvTVDLNZaDVTsXhMeJIKo8p1VwT56U
N8RMjuobP96Id6GN1m/wszKYgosN32F9Npptx4z/hfEAnr/aqqj4VsRCoM5pZcJU
9x2m+JJkFse7aLaVCiBJPefqx99yNl6vn1cwcKc45FCWqOjP5V6+eDSFIaBLnGpE
gaqDbG7K6I4iNpeaPTTE
=4d7P
-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-dev] Optional Dependencies

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi openstack-dev,

I was wondering what the correct way of handling optional dependencies
is? I'm specifically talking about libraries that are only required
for a specific driver for example, so they're not technically a hard
requirement and the project is expected to function without them when
using a driver that does not require the lib.

I read through the README in openstack/requirements [1] but I didn't
see anything about it.


Thanks,
Douglas Mendizábal

[1]
https://git.openstack.org/cgit/openstack/requirements/tree/README.rst
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCqJlAAoJEB7Z2EQgmLX72D8P/RROP9qT7DRY1jDnbK0Aj/TZ
lYujurHS70nXCj/Pw6uqsq41TttmwMdAx85yXwoLv/XBASaFYZ6eT6i0scfHBKAu
z5f0IomaJMQDGJ27By/amcE5eMiST5sEW/OCwHyZxdM8zgo3mzX1jIslmFEyPJ0z
wSah5DoZZh3J0RfQuBg8MOQgJVZo74KiNRou1uKE82cbVXJzVKjlfn+r7yO9TUtx
9hB/77a8sDFBWI4nXluTP+Dfpy6NSW1kqwwUoDtsZACtrhTDNCDWxUUIjfyBlIKT
LdY+oVrhqWSUI/WwCop4+Aim64obaAq5yWPR6fjTlcQ3+iCYbBzzgP/9VOm/+0Nr
AGzVbIW7ah2yEDhM0yTymaay8+G1mc+jxhvwAtTxJVIJLcJXdC3XK6b00OFkO2Kt
0dkjx/i8/riP56sb62P2a3heS3gOFqzqzwlh9SD8Omvhot3NkOr2e1QR7Cvjh1le
W5U/61vGKxmtv+iIaFXd86CRO46+4UiD1V+T0lKz083J9XuC49nkhyfuMP3ev6lc
/qD6uOnbJfyVWKRdf2PkTEe9C8YsXlxEWZ72GFC+u1jvL5K/NATUkLLWmGuv/JH+
tPyAOPISKHh44mhJqM/K37NvJO/TloOhz0a2fW2FV8kOX1V5wVAZiQBSEWtCAI8u
29up4yIgvi13ZkrRb94n
=fj9z
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Barbican][Security] Automatic Certificate Management Environment

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Rob,

I agree that the ACME standard is very interesting, but I'm also
pretty new to it.  And by pretty new I mean I just started reading it
after I saw your email. :)

There has been interest in adding support for Let's Encrypt as a
Barbican back end since it was first announced, but I don't think
anyone has looked into it recently.

Being able to deploy Barbican and issue free certificates via Let's
Encrypt is a very compelling feature, but it's definitely going to
take some effort to figure out the best way to do it.  The first issue
that I can see is sorting out auth.  The Public CA plugins we're
developing all work under the assumption that Barbican itself is a
client to the CA and has a set of credentials that can be used to
interact with it.

The Let's Encrypt model is different in that Barbican itself probably
does not want to have a set of credentials to to talk to Let's
Encrypt, or we would end up owning all of our client's certs.  So
we'll have to figure out a way for clients to be able to provide their
Let's Encrypt credentials to Barbican.

Another challenge is going to be sorting out the automated domain
verification.  We could possibly just proxy the challenges to the
client and then wait for the client to let us know which verification
challenges have been completed.

As far as supporting ACME on the front end, I'm not sure it would be
possible.  There is a lot of overlap between ACME and the current
Barbican CMS API.  Adding support for ACME would basically mean
supporting two competing APIs in a single product, which is sure to
cause confusion and a ton of overhead in development.

Additionally, there are features in ACME that I think would prove
almost impossible to support with existing public CAs.  Namely the
automated challenge feature.  Currently Barbican CMS defers the Domain
Validation to some out-of-band process between the CA and the client.
 So you could, for example, order a Symantec Cert using the Barbican
API.  Barbican would begin the Cert workflow in an automated fashion,
but at some point someone from Symantec is going to email the domain
owner and they're going to have to respond to the challenges the good
old fashioned way.

I think that a prerequisite for ACME support on the front end is going
to be Public CA support of the ACME standard.  At that point we could
probably phase out the Barbican CMS API, and just support ACME on the
front end.

- - Douglas Mendizábal

On 9/24/15 10:12 AM, Clark, Robert Graham wrote:
> Hi All,
> 
> So I did a bit of tyre kicking with Letsencrypt today, one of the
> things I thought was interesting was the adherence to the
> burgeoning Automatic Certificate Management Environment (ACME)
> standard.
> 
> https://letsencrypt.github.io/acme-spec/
> 
> It’s one of the more readable crypto related standards drafts out
> there, reading it has me wondering how this might be useful for
> Anchor, or indeed for Barbican where things get quite interesting,
> both at the front end (enabling ACME clients to engage with
> Barbican) or at the back end (enabling Barbican to talk to any
> number of ACME enabled CA endpoints.
> 
> I was wondering if there’s been any discussion/review here, I’m new
> to ACME but I’m not sure if I’m late to the party…
> 
> Cheers -Rob
> 
> __

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWCVvsAAoJEB7Z2EQgmLX7eMUP/1qRXJJfmmQgI/z4rj13ug8q
IAG+iENDhhXojZyvf0F87zhj6DnQSTOzGwKIotP0FxUpLGSiNOYsKix4+OIShWqH
7HPdMLZnl6cROf/n11QgSQouvhRpUTW/UKtGaPGCO2Lw53LXHQqNOXCQdq12mdhT
CB9+55PpG7dr3bY9vX9PeB61QP410+c68ICcHhpOAFEm5TnmV0NL2JQ0zkjwENM3
s3kwIyZE3awZg3fp9zdxzuI87OEqQ+f4PN55q7GMJjwAdU72SU7crFjrpJxlPCCr
LuEb6J1rz9I5eThp2woaLOS1w4irBwrk5kp+0Af8Z2VZqWo2/mX6VlQJ5cgIMQdp
je3Ku500bQSjWAfv8/CJBIQ4bkBnOwaBWxzsXEzYDlHofQQHHubpsUlV202BOtIZ
F9BN0P/siwSQ+GOmCYd64AfAsBwjiY7uhOong50GFjThDkLxgRuOXjtt7u7ZBfvF
PbLRfo9teJju6zQHrE+G4WUURdBIP9NEDr7kkT7uDcVXNrPLY/8Op4tdws5yk49w
BFlWrjCZ8uuhDGm6gyaLzjcY/UU3Zwf8G4E4CL7YpWYLhVuaqs7ig/qbTUEK/xdt
+C6yU6JJGYT9j+H18sZOCMlvXRNG3W9CO/6fKiZ1PprsYXDN2UYfYHIyBNROeVkj
au8DQsYCyQBpkJStuJwt
=8g77
-END PGP SIGNATURE-

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

Re: [openstack-dev] [neutron][lbaas] Barbican container lookup fron lbaas

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm not familiar with the low level details of the lbass
implementation, so hopefully someone from the lbass team will be able
to answer this.

The URL I sent last week for the API docs has been updated though.
Here's the current URL:

http://docs.openstack.org/developer/barbican/api/index.html

- - Douglas

On 9/21/15 11:41 AM, Varun Lodaya wrote:
> Hey Douglas,
> 
> Thanks for the reply. Will look into barbican ACLs and test it out.
> Also, had 1 more follow up questionŠ 1) Currently the HAProxy LBaaS
> instance sits on the controller. The certificate download happens
> on the controller too. 2) Once we move to service-vm model, where
> service-vms could reside on compute hypervisors, where will the
> cert download happen? Still on controller in the flow?
> 
> Thanks, Varun
> 
> On 9/18/15, 10:53 PM, "Douglas Mendizábal" 
> <douglas.mendiza...@rackspace.com> wrote:
> 
>> * PGP Signed by an unknown key
>> 
>> Hi Varun,
>> 
>> I believe the expected workflow for this use case is:
>> 
>> 1. User uploads cert + key to Barbican 2. User grants lbass
>> access to the barbican certificate container using the ACL API
>> [1] 3. User requests tls container by providing Barbican
>> container reference
>> 
>> Since the user grants the lbass user access in step 2, the token 
>> generated using the conf file credentials will be accepted by
>> Barbican and the certificate will be made available to lbass.
>> 
>> - Douglas Mendizábal
>> 
>> [1]
>> http://docs.openstack.org/developer/barbican/api/quickstart/acls.htm
>>
>> 
l
>> 
>> On 9/19/15 12:13 AM, Varun Lodaya wrote:
>>> Hi Guys,
>>> 
>>> With lbaasv2, I noticed that when we try to associate tls 
>>> containers with lbaas listeners, lbaas tries to validate the 
>>> container and while doing so, tries to get keystone token based
>>> on tenant/user credentials in neutron.conf file. However, the
>>> barbican containers could belong to different users in
>>> different tenants, in that case, container look up would always
>>> fail? Am I missing something?
>>> 
>>> Thanks, Varun
>>> 
>>> 
>>> 
__
>>
>>> 

>>> 
>>> 
>> 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
>>>
>>
>>
>>> 
* Unknown Key
>> * 0x2098B5FB(L)
>> 
>> _
_
>>
>> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWADcHAAoJEB7Z2EQgmLX7Me8QAJ1gTTMecCoWZBReLe+k5t98
8YIdoMjWgcavVTB+v08r5UYlsyLb5CkUQdWVagb+af9fQFThGvrEZKycffI078cb
KoNW/ow0MQTTBEhrVDr2x800NuG3uitUAFKdNfPkhiB+4NWXrRnlIYD+XVMAJQ0L
2n7PFIC/F2VckSdUofhTJwAYBVGTRS/OL1G6dsxKh1LD3DEswKxyXb7TgVKaI2AO
os5z0BRCiP4Y1Dl+vLN9C4Hj5/juFF9aVe8wmNTCwUUb/auXhjhNiy75BKmNwu1r
kL2iPBCjjFFhx4JItZ/WJFhdGkceG+F5C4TeqJM7SUPM7SNXlXbhi2sTeb+WxvQE
SjrdjEiRlzM/JCzsj1s634TwgJvLPmmRhxVnOgVm1mlXwgPaAk7b8PMXDik1Wkrq
JzIorRb83XnV14yoJAh7kOrxxOlnB1UjnYh7YPr0KwYACkP8QQFkXxuzcePGUkOa
cLDmu3kfofASOQEpLsbbn2Eu9/FIzwvJDXVbdr/nDYtzDUJiBi6AitMVal0H7kJs
0IdXZcaR7vt73Ln9RPCr6+3nMC57odB06cgDalLeG1Kn5pPY/MWkYZol7d+v2H7y
c+nN7tAGaCsLzyhnhUffvns/ogSjTTW+JH2tfVDwf2pSTQhPvppcXBGXi8w95Ood
KFZ5W9p/tAP4BEsWGNtS
=6fJ9
-END PGP SIGNATURE-

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

Re: [openstack-dev] [neutron][lbaas] Barbican container lookup fron lbaas

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Varun,

I believe the expected workflow for this use case is:

1. User uploads cert + key to Barbican
2. User grants lbass access to the barbican certificate container
using the ACL API [1]
3. User requests tls container by providing Barbican container reference

Since the user grants the lbass user access in step 2, the token
generated using the conf file credentials will be accepted by Barbican
and the certificate will be made available to lbass.

- - Douglas Mendizábal

[1] http://docs.openstack.org/developer/barbican/api/quickstart/acls.htm
l

On 9/19/15 12:13 AM, Varun Lodaya wrote:
> Hi Guys,
> 
> With lbaasv2, I noticed that when we try to associate tls
> containers with lbaas listeners, lbaas tries to validate the
> container and while doing so, tries to get keystone token based on
> tenant/user credentials in neutron.conf file. However, the barbican
> containers could belong to different users in different tenants, in
> that case, container look up would always fail? Am I missing
> something?
> 
> Thanks, Varun
> 
> 
> __

>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV/PhsAAoJEB7Z2EQgmLX7yYQQAJLI+njJaIyDhG8uyJZiq9Rp
KIHFppR0HT10muGxAcUGcDlAFpH6+Ww62fxs6WIbPnGXutK0iwmNOvef3S3+HKLj
0jE4RHcrDQK8dCZ+FRslC3RuF8oxppTOUVHq/IcD9g6JAsFPvmFaPNf5+XLE5z+P
a7T+ycfrtoG8ZKDFIv8XJcb4knDKNUT3JLGtLZ8UuEBoQiSZcpm33UUQcUsZgdSE
EZPi4GSC9pwfDe3ujxOlPoAgEjKUApMMA+WtdMINLleJrw7FH9YWFXzHGv93Uwrl
BBNpZ5QDMCKXd/q2n1IMVj0ejC8EoOL9Wv5ZTvkRFZjDfA2x7P3U24gKGaERj+Lu
t4Llsn4PHIaZ+DFchI4SjPblApYQ4CGDYDzh6xqvOFAv3Gfi8strNzSdu4aHOQZM
TeaRd6A06nI/J/lA9YzEgZFaOhLlU8iWPfYEAqAHVZTZQrbaTTMwVxbttD++qK/q
VJ4jcUfxPyoPuY78sNiJ7W8HuZgaPVxMi/s5rfjcR8NREjOrSkJSQ4eG5OMR3LmA
Tem2/pF50a0Awb+RbSIDzDO2nBJzarKYONih+dCF/fgk66BKQC7D8vyujKYRhk5z
dHDUhFNnuLg9pmS0rtS9Rthc4bpz2gTph35ZFsjMNm55DfsGcsUoHge1w9HQHjXL
edqEMWH4eAZvO5cmioeH
=O44k
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think someone jumped the gun on this thread.  According to the wiki
[1] the cutoff time is not until 5:59 UTC, which
doesn't happen for another few hours. [2]

Am I missing something?

[1] https://wiki.openstack.org/wiki/PTL_Elections_September_2015
[2] http://time.is/UTC

Douglas Mendizábal

On 9/17/15 9:50 AM, Anita Kuno wrote:
> On 09/17/2015 08:22 AM, Matt Riedemann wrote:
>> 
>> 
>> On 9/17/2015 8:25 AM, Tristan Cacqueray wrote:
>>> PTL Nomination is now over. The official candidate list is 
>>> available on the wiki[0].
>>> 
>>> There are 5 projects without candidates, so according to this 
>>> resolution[1], the TC we'll have to appoint a new PTL for 
>>> Barbican, MagnetoDB, Magnum, Murano and Security
>> 
>> This is devil's advocate, but why does a project technically
>> need a PTL? Just so that there can be a contact point for 
>> cross-project things, i.e. a lightning rod?  There are projects 
>> that do a lot of group leadership/delegation/etc, so it doesn't 
>> seem that a PTL is technically required in all cases.
> 
> I think that is a great question for the TC to consider when they 
> evaluate options for action with these projects.
> 
> The election officials are fulfilling their obligation according
> to the resolution: 
> http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20
141128-elections-process-for-leaderless-programs.rst
>
>
> 
If you read the verb there the verb is "can" not "must", I choose
> the verb "can" on purpose for the resolution when I wrote it. The 
> TC has the option to select an appointee. The TC can do other 
> things as well, should the TC choose.
> 
> Thanks, Anita.
> 
>> 
>>> 
>>> There are 7 projects that will have an election: Cinder, 
>>> Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The 
>>> details for those will be posted tomorrow after Tony and I 
>>> setup the CIVS system.
>>> 
>>> Thank you, Tristan
>>> 
>>> 
>>> [0]: 
>>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirm
ed_Candidates
>>>
>>>
>>>
>>> 
[1]:
>>> http://governance.openstack.org/resolutions/20141128-elections-proce
ss-for-leaderless-programs.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
>>>
>>
>
>>>
>>> 
> 
> __

>
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+tawAAoJEB7Z2EQgmLX7WKIP/RUdGYOkA5dHuNnWKdX8QhaD
VzZSyTOjIebNZshiMIz8FhKGrFUn8wqEScbtUIFHIJj8tKVjZQ19m2Gg6zh42X6V
kpogxGDBwE5a/vuBA1z9eiTocA4KYEypxY+SIh18ho84dj5hDooI9N7ZsCJaaF3+
yKTLvUw7YxMM2iPxjZgQTH1vE1pMUh2fcylv3T3NhpHzIRgeB9dfnfr938rnwUTj
NUTK3DmWJAraAgHcKnwIN+JwOYF1SexXFK1eO2TX0yNYSEzFI3Xina0Hq3bHAON9
KbWlgr4pN19PsqqQnQrPjJbBmBs8TCkXNhTAojHtlA1oIbUiK8c3h32PHEt2AyCx
5g3btXOAqsCqvKtmFH1sj5EACeMUCW4J98u8e212iQPizgG9SD4LZ8FPPHOqWMwV
4haWpWLczZyXf7w7/deP4gndoW7njU/uiwCUNBrgdjI5AeaP5vckHQZ9iQmETsRa
bwwu5Yq7K92rAupVRFx4bofTyG4I8bw+Lg2muYMnwuqvgf++xqsMVs0x97jFYja5
M2qGMgihYDytDoYvdL71WykuN39SzZmPHzxKXKmiOcTXWhAXp10pBwFUFzFJmt+V
/tNjHfzvqt6qvnDEtt65vuwGBEQyiQFqmKmyPFCONCibn8nwoqjwP9hWmG4y1vVa
geegYxrikuEQ3KnPFQWr
=jON5
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is quite unfortunate, as I was intending to submit my candidacy
for the Barbican project today, but I did not realize the cutoff time
would be in the morning in CDT.

I'd like to apologize to the OpenStack community and the Barbican team
in particular for missing this deadline.

Thanks,

Douglas Mendizábal

On 9/17/15 8:49 AM, Flavio Percoco wrote:
> On 17/09/15 13:44 +, Tristan Cacqueray wrote:
>> On 09/17/2015 01:32 PM, Flavio Percoco wrote:
>>> On 17/09/15 13:25 +, Tristan Cacqueray wrote:
>>>> PTL Nomination is now over. The official candidate list is
>>>> available on the wiki[0].
>>>> 
>>>> There are 5 projects without candidates, so according to
>>>> this resolution[1], the TC we'll have to appoint a new PTL
>>>> for Barbican, MagnetoDB, Magnum, Murano and Security
>>> 
>>> Magnum had a candidacy on the mailing list. I'd assume this is
>>> because it wasn't proposed to openstack/election. Right?
>> 
>> That is correct, but the candidacy was submitted after the
>> deadlines so we can't validate this candidate.
> 
> Awesome, thanks for the confirmation. Flavio
> 
>> 
>>> 
>>> Thanks for the hard work here, Flavio
>>> 
>>>> 
>>>> There are 7 projects that will have an election: Cinder,
>>>> Glance, Ironic, Keystone, Mistral, Neutron and Oslo. The
>>>> details for those will be posted tomorrow after Tony and I
>>>> setup the CIVS system.
>>>> 
>>>> Thank you, Tristan
>>>> 
>>>> 
>>>> [0]: 
>>>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confir
med_Candidates
>>>>
>>>>
>>>>
>>>> 
[1]:
>>>> http://governance.openstack.org/resolutions/20141128-elections-proc
ess-for-leaderless-programs.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
>>> 
>>> 
>>> 
>>> 
>>> 
__
>>>
>>>
>>> 
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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV+saCAAoJEB7Z2EQgmLX7XG0P/AqOTGDDbVJrJSTPnCGwtqYd
275uDQgWqvbsGMKOrfKO7GBgI/5n/j8hCyiipq6niCfW5eWWH7rYgU1pLKLjiZmR
12Ui4PwkqvoJEa0J5NIiM8GOrt2TEDTu7vOQAWMzGEn+8fbs7Z9MRPIAg7bEXuk0
eQNs5LK6j/INXvuuKm4ZV2MjAxJRbtsSZYVn59U4IxM0GSJIC4MLu8dGaRzf+G8B
881hflBskg1Sa5UjEcj/yMUDrtBLOyNkM67dv8M9ojNB0bX3o+US8zmJnsbk6whD
ox3GrgoxT8he6iMNd/YYycFtBlBZ4fqNN8Uv5Vr/+k8s2umJf7Y3IbM2oQuhM1oJ
mWuwFbyc440ep9WkBeXeZTm0S0FYwR3MS40nW2D04eHEcTbCHchKIoLp/tO0AKYP
op116JlzTyWZatywL8rIOner4UJQX6yUqmGRdonACNQ6OAzTLTTaARtwqHacxL81
UqzOLEQ8nW9p5xCTPWhbPbR7t1T7ngwf5bJAuDKVx9JDUsM+mYjZ7smWdg+PV1yS
SwW94TzImOV4ujiT7AwzUBz6SZ0jHFt5yXVWscggpj5k7l8lPqFhd4xQVvidqLcZ
VsHfKwfdfWX22z+97n4/GjEd6B0seZqcxoP4qVsXXgpuFJETVLEifDM9DTOLccxy
xQR6UpOxTZxl5EdiOpxX
=nraX
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Barbican] Nominating Dave Mccowan for Barbican core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


As described in the Barbican Core Team wiki [1] Dave has gotten the
requierd +1s and no objections, so I'm happy to welcome him to the
Barbican Core reviewer team.

Douglas Mendizábal

On 9/9/15 11:33 AM, John Wood wrote:
> AgreedŠ+1
> 
> On 9/9/15, 11:17 AM, "michael mccune" <m...@redhat.com> wrote:
> 
>> i'm not a core, but +1 from me. Dave has made solid contributions
>> and would be a great addition to the core team.
>> 
>> mike
>> 
>> On 09/08/2015 12:05 PM, Juan Antonio Osorio wrote:
>>> I'd like to nominate Dave Mccowan for the Barbican core review
>>> team.
>>> 
>>> He has been an active contributor both in doing relevant code
>>> pieces and making useful and thorough reviews; And so I think
>>> he would make a great addition to the team.
>>> 
>>> Please bring the +1's :D
>>> 
>>> Cheers!
>>> 
>>> -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
>>> <mailto:jaosor...@gmail.com>
>>> 
>>> 
>>> 
>>> 
>>> 
_
>>>
>>> 
_
>>> 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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV9zZxAAoJEB7Z2EQgmLX7HYwP/ikOJ33bfi5kE2U+T+X5tpm0
XoKdUaFtpUukzCVwnCsBTam4r8SOj+1IYdmjfbExO9MfQ2iNlE6PGaxC+rjGNezA
PO368yuAXPtC0rd+MEtYHduV4iBpDQyRRHM/KIehUmMRS+gOmYfpXdPfkKh55nxi
VQVA6KAAUIMp/tqLbKMUOqsxa4VN4j2ITaI1KouRueRgdnko7bgIIGcG7ruHBQdq
xPFJFy/X2+Gpw3vKXaEYqFvAX8EphHzMd09yz4wjDRzJUuG2Qt7/qD3GEPvV9t9Z
MnbjsOY1/1m76NoFYByaGYHdfLVw7ZlvnM6JUiLdOCSLiDPSk21ps0iKOiT+vJg5
H8n70nzIs6zTOK6xENpgV24U8p3PsT24s84LP5Tp6JFIwIpSHuM/UJceFAr6IqhB
YBsbmkhUK7xi8rJjoDLDWjtAtm9ra763p2tJbRhr0wnFqYys/inAPpy3CsKFNR2/
9SDObwphkuHMSU5dkGXdPiEIMozySE9yPBJanVvESS1gkabMCVZZeAUfA0nxC265
lOJEYKgqf3KLe4sFXMeco48o2DHH5TRSqDdYiEkOYLM5QC2FBDhsgZL/u5ym1/yw
HH6XId2AT6GDSKZ4OAhSJ7+J9cjwbrv4evzvzL2HIeIS+Y2LJqGdlfTaduH19Q0U
wl0PII+/2qydH03kY2wZ
=sW/Y
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Barbican] Nominating Dave Mccowan for Barbican core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+1

Dave has been a great asset to the team, and I think he would make an
excellent core reviewer.

- - Douglas Mendizábal

On 9/8/15 11:05 AM, Juan Antonio Osorio wrote:
> I'd like to nominate Dave Mccowan for the Barbican core review 
> team.
> 
> He has been an active contributor both in doing relevant code 
> pieces and making useful and thorough reviews; And so I think he 
> would make a great addition to the team.
> 
> Please bring the +1's :D
> 
> Cheers!
> 
> -- Juan Antonio Osorio R. e-mail: jaosor...@gmail.com 
> <mailto:jaosor...@gmail.com>
> 
> 
> 
> __

>
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV7wkfAAoJEB7Z2EQgmLX7X+IP/AtYTxcx0u+O6MMLDU1VcGZg
5ksCdn1bosfuqJ/X/QWplHBSG8BzllwciHm7YJxIY94MaAlThk3Zw6UDKKkBMqIt
Qag09Z868LPl9/pll0whR5fVa052zSMq/QYWTnpgwpAgQduKNe4KaR1ZKhtBBbAJ
BvjyKEa2dJLA6LIMXxcxpoCAKSeORM5lce19kHHhWyqq9v5A89U6GHMgwRAa2fGN
7RyYmlOrmxh6TyJQX9Xl+w9y5WPAbxaUqC0MYEkLMpa7VnGf2pEangkN0LUAJO2x
NxwHa73b2LA8K1+4hwTvZO28sRnyMHwjSpqvpGt60FXkgi4dLyyy8gR6gsO49EDB
QOSwpwyFHzA//iuMl72pAD6uMzK0SCECtEu2000l0p3WEXS1i0z7p9VTfw4FySqb
V0S/IeSFfkt09TK2DoOSzXAvBZjsLz9gjRbRIv2dx0QTTmN5JpihOeoUojn24aDV
86AshlhoImJGOX16MwRL+T6LCindkczGe4Faz7WzmBomEJ7SOY6pzDbyEBLYcqzu
crvrLt2D1HmaygFGS37lVCqxlIegwsnZHGIe+Jtr8pDIDSW37ig4LZIDVra2/lj9
E7/fWYCDqbSIUWYG2jMr0/3eQQwZCj4kNvtWaTlNFmTPJZAEYpSN3rBhkfWBgsLv
mqBOM4IeR4EqaqaC2og7
=jL8d
-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-dev] [barbican] No IRC meeting tomorrow September 7

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Barbicaneers,

We'll be skipping the weekly IRC meeting tomorrow since I expect most
folks will be out due to the US holiday.

Thanks,

Douglas Mendizábal
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJV7N2vAAoJEB7Z2EQgmLX7uGIP/1mpkl9rtJchktROwhMkO/Kk
OI3oMkVyOLOQwje7lwYjF8DR55cV/wrE+kYUyJlNnkELH5+CUskBWERN+fFOjyJ7
oCbUK3ISg9QIJf+wyov3Wbzyp+vFwLFDzHucz6rfb2MJCwNQxUH9lujBCQjdGrJC
MBV0IWQ9A8KE6yNj5Sk0S8T1ZnkPTGKojKNv8rY2NQE9O1RdPIH7IxeYPfA6Z4xY
9Z/5KEb1BpbLPnlAKxF3gLb1H+FcjF+QiSdaek3t+6QOVJ1dTjA53bbxETrWlrcU
mjDGm99bixZxlON1Pce4fg/EtshAI+LPKK9epWh2yQ5M73JfXQnm6/eFVDecmGPI
kgYnUCUb8k05ag8qN3Zrgd51SyhrSsQg2IvV6I7/mfbChFuQlg/pPLmlCATSr4Kj
zPSylNocoT5kqXAAdqjYMsXmIgyCAMEo7q5xH7ZbIC3SWdDDoQVOWrEgbo6mHfIW
aemFB2nS+ybwk4UvcYJTsrLXU8xEGAYYLJaWWHjzbd5Lt1C502rQGED2T6YkwSJY
+7Udct8gTCTxWuQykBbXgGBh2RjrcAj+ArQhUJpluzgyolNmYILOpRTGo/HhwKk9
CqTlm/R+EcDEsxpp3JmhxwwpxCc9gMcU5oUWpHcWKkyqAW0XpE3iS3nXm2YNeCXw
XI2iForVuqYIZYb6XHXT
=T39J
-END PGP SIGNATURE-

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

Re: [openstack-dev] [magnum] Difference between certs stored in keystone and certs stored in barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Added a few comments inline.

- - Douglas Mendizábal

On 9/1/15 12:03 PM, John Dennis wrote:
> On 09/01/2015 10:57 AM, Clark, Robert Graham wrote:
>> 
>>> The reason that is compelling is that you can have Barbican 
>>> generate, sign, and store a keypair without transmitting the 
>>> private key over the network to the client that originates the
>>>  signing request. It can be directly stored, and made available
>>>  only to the clients that need access to it.
>> 
>> This is absolutely _not_ how PKI for TLS is supposed to work,
>> yes Barbican can create keypairs etc because sometimes that¹s
>> useful but in the public-private PKI model that TLS expects this
>> is completely wrong. Magnum nodes should be creating their own 
>> private key and CSR and submitting them to some CA for signing.
>> 

Barbican provides a lot of options for provisioning certificates. We
do support provisioning certs by only passing a CSR so that clients
can keep ownership of their keys, if that's what the client prefers.

Of course, when you're provisioning keys for every node in a cluster
for many clusters then key management becomes an issue, and if these
are not throwaway keys, then storing them in Barbican makes sense.

We can also provision the keys, and create CSRs on the Barbican side,
so we make it very easy for clients who don't want to do any of this
locally.

>> Now this gets messy because you probably don¹t want to push 
>> keystone credentials onto each node (that they would use to 
>> communicate with Barbican).
>> 

Kevin Fox is working on a Nova spec to provide identity to VMs. I'm
really hoping this spec gains some traction because it's a problem
that not only Barbican, but all other user-facing projects can benefit
from.

See: https://blueprints.launchpad.net/nova/+spec/instance-users

>> I¹m a bit conflicted writing this next bit because I¹m not 
>> particularly familiar with the Kubernetes/Magnum architectures 
>> and also because I¹m one of the core developers for Anchor but 
>> here goesŠ.
>> 
>> Have you considered using Anchor for this? It¹s a pretty 
>> lightweight ephemeral CA that is built to work well in small PKI
>>  communities (like a Kubernetes cluster) you can configure 
>> multiple methods for authentication and build pretty simple 
>> validation rules for deciding if a host should be given a 
>> certificate. Anchor is built to provide short-lifetime 
>> certificates where each node re-requests a certificate typically
>>  every 12-24 hours, this has some really nice properties like 
>> ³passive revocation² (Think revocation that actually works) and 
>> strong ways to enforce issuing logic on a per host basis.
>> 

Someone from the Magnum team can correct me if I'm wrong, but I do
believe they considered Anchor for certificate provisioning.

As I understand the Magnum use case, they will be provisioning many
clusters across different tenants. While Anchor would work well for a
single cluster, they need the ability to provision new CA roots for
each and every cluster, and then provision certs off that root for
every node in the cluster. This way node certs are only valid in the
context of the cluster.

A new feature for Barbican Liberty will be the ability to add new CA
roots scoped to a tenant via API, which will address the Magnum
requirements of separating the certificate roots per cluster.

>> Anchor or not, I¹d like to talk to you more about how you¹re 
>> attempting to secure Magnum - I think it¹s an extremely 
>> interesting project that I¹d like to help out with.
>> 
>> -Rob (Security Project PTL / Anchor flunkie)
> 
> Let's not reinvent the wheel. I can't comment on what Magnum is 
> doing but I do know the members of the Barbican project are PKI 
> experts and understand CSR's, key escrow, revocation, etc. Some of
>  the design work is being done by engineers who currently
> contribute to products in use by the Dept. of Defense, an agency
> that takes their PKI infrastructure very seriously. They also have
> been involved with Keystone. I work with these engineers on a
> regular basis.
> 
> The Barbican blueprint states:
> 
> Barbican supports full lifecycle management including
> provisioning, expiration, reporting, etc. A plugin system allows
> for multiple certificate authority support (including public and
> private CAs).
> 
> Perhaps Anchor would be a great candidate for a Barbican plugin.
> 

We've talked about this before with the Security team, and I agree
that adding a CA plugin to Barbican to support Anchor would be awesome.

> What I don't want to see is spinning our wheels, going backward,
> or inventing one-off solution

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Asha,

The blueprint you linked for Tempest is over a year old.  I think it
pre-dates the Tempest team's decision to stop putting all project
tests in the same repo.  I believe the spec is obsolete, but someone
from the Tempest team can correct me if I'm wrong.

The automated tests that validate the API are the Functional Tests I
linked in my earlier email.

- - Douglas Mendizábal

On 7/1/15 3:22 PM, Asha Seshagiri wrote:
 Hi Douglas ,
 
 Are there any Automated Test cases created for validating the
 Barbican APIs.
 
 Thanks and Regards, Asha Seshagiri
 
 On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri
 asha.seshag...@gmail.com mailto:asha.seshag...@gmail.com
 wrote:
 
 Thanks Douglas for your response and appreciate for pointing me to 
 the right link
 
 I was talking about the tempest tests to validate the Barbican
 APIs Please find the spec[1] and blue print link [2] for the same
 .
 
 [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-te
sts.html

 
[2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-ba
rbican
 
 Are above specs and blueprint have become void for Barbican? Now I
 could use the  link sent by you for validating the APIs
 
 Thanks and Regards, Asha Seshagiri
 
 
 
 
 On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal 
 douglas.mendiza...@rackspace.com 
 mailto:douglas.mendiza...@rackspace.com wrote:
 
 Hi Asha,
 
 I'm not sure what you mean by tempest tests.  If you're looking
 for Functional Tests for Barbican, then you can find them in the 
 functionaltests directory [1] inside the Barbican repo.
 
 We have no intentions of adding Barbican specific tests to the 
 Tempest repo.  It's my understanding that Tempest is moving away
 from one monolithic repository into a modular approach using
 tempest-lib.
 
 - Douglas Mendizábal
 
 [1] 
 http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest

 
s
 
 
 On 7/1/15 2:12 PM, Asha Seshagiri wrote:
 Hi All ,
 
 Has anyone done the Tempest tests for Barbican API Any help
 would be highly appreciated.
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 
 __

 

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

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __


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

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 __


 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVlE3/AAoJEB7Z2EQgmLX70vcP/imbbk9quMlxpX0IbGTOuoAH
+cpiUU0g9dQFawjQQpVXQhalR1JNOIhZlFICP1VHama6mh/HChuM4EUS/Ic/w4Dd
eRGamkwG2l/OWWdNaE7l4y6kCgvT6QQQFKwJNG6HgJtChs4u9aL6WgQS85ACaw70
I6ZK0QBXXe/VQFMmxWqYflHmDF6G5UP+4BzGcwIO41tWKKYf9V0rFh5JBDDFW7yC
A6YuWNGHfR3OqJuS5hw0if2q94LXzw2qKI6eMMmiV9OAT0U/mLufTPpNkH37DJ0w
CCQudKlqZQN0FELhr1oxM88KVoOD0N1S/yOfjNA4TdvvpB/2EIt+t8GZZKoXeLtx
YfzPsa1cBO/zpgoiPO6zCqF7HvUMwSnPEBnRAQl15mXUfSKJJJzh0GaCEQ5bjTIb
2s+xQIyBAXuUtTPYJMzHlw2nEeov77U+OvR90lswSuppO/du3YTYfJX799pqTLg5
QY4bsuxQpdVlHV+nu4mC2cImU0ZUVTzNDCMKgWbw30Ni+yc9TDTlZs301/odHrjy
WuiKkXId/Fp5hYh7dSvt4wMKO0XdiMUiSNP1KybO0smCvCxa5AhcsiL1nZ05f+cG
eylLvYheaEGemnsTy1SVOQ0UowA7sDAaaOTl9KBhvAYZS+dWHwaC5ZJzDB/rRdnG
WELJUjLwg2V2MSGFRiIk
=G1kZ
-END PGP SIGNATURE-

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

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Asha,

I'm not sure what you mean by tempest tests.  If you're looking for
Functional Tests for Barbican, then you can find them in the
functionaltests directory [1] inside the Barbican repo.

We have no intentions of adding Barbican specific tests to the Tempest
repo.  It's my understanding that Tempest is moving away from one
monolithic repository into a modular approach using tempest-lib.

- - Douglas Mendizábal

[1] http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest
s


On 7/1/15 2:12 PM, Asha Seshagiri wrote:
 Hi All ,
 
 Has anyone done the Tempest tests for Barbican API Any help would
 be highly appreciated.
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 __


 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVlEAyAAoJEB7Z2EQgmLX7NBYQAJB/ArYrW0LDitmlaTcupf8I
B+LjBD6uMLI0nsFx4dOFu/FROSe37XkNvWumkj96wPZcmZNx1wuOntuyYu7STMBH
Z+3JHxLwEdW5A3j0437IuNf14y8JZhio1+txMa0MWEEWIkfk/15Ppz3vhkKgfKsc
ldMxQ0RboH5xXOWpIpCa8S022I+N2Erhp7Rn1xKA0rICKzvhpa87lB2aFZdZ3NMw
pgM3W1Nzongl+zG0NHxqtxBX2y41nvzWSX7slvcjE1LIjPcBuc12Ja9WM6piZj/L
+CxLHf8hAfZDxUDEm1Uwm9yvaWFtQFw684+CksRB4uq6KMGpF1EYOvnfoHtC71X9
GokjNYZoz8vqkRdtXHvMwUTPH1V+G3y0mBL2eAZspfxjcfqkDudilkMdmEAhPWLy
ihsH/S5g4SCgozYb9sZ9RJxNN/lGJodjyg3ODdFUwjPQtryejryVp2EOryA0T5Pd
7M7Zlhmm/NlZzwQBqQxDmVFHNU3baYizLTinPiYtURNmy6CqDs8WAWR/Br0oGJUI
5vL/y5hjPBR+WJV9IXfT0EuNqFTck1r0+vm/isez4hM2T7wFJcpFSPXS7l1GKxsx
HTOqvujAOREcGfLYBBwwCoKCmDWoTqBjxUfY182sjYoUx1SnL5Ws01AdRcU3oNIl
dEpBJSS6YgwvUZkjUJD2
=FKK1
-END PGP SIGNATURE-

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

Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Asha,

Information for running the Functional tests can be found in our
official documentation. [1]

- - Douglas Mendizábal

[1]
http://docs.openstack.org/developer/barbican/testing.html#functional-tes
ts

On 7/1/15 5:08 PM, Asha Seshagiri wrote:
 Thanks a lot Douglas for your response :) I would like to know the
 steps required to configure and run automated functional test cases
 for  validating Barbican APIs.
 
 Thanks and Regards, Asha Seshagiri
 
 On Wed, Jul 1, 2015 at 3:30 PM, Douglas Mendizábal 
 douglas.mendiza...@rackspace.com 
 mailto:douglas.mendiza...@rackspace.com wrote:
 
 Hi Asha,
 
 The blueprint you linked for Tempest is over a year old.  I think
 it pre-dates the Tempest team's decision to stop putting all
 project tests in the same repo.  I believe the spec is obsolete,
 but someone from the Tempest team can correct me if I'm wrong.
 
 The automated tests that validate the API are the Functional Tests
 I linked in my earlier email.
 
 - Douglas Mendizábal
 
 On 7/1/15 3:22 PM, Asha Seshagiri wrote:
 Hi Douglas ,
 
 Are there any Automated Test cases created for validating the 
 Barbican APIs.
 
 Thanks and Regards, Asha Seshagiri
 
 On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri 
 asha.seshag...@gmail.com mailto:asha.seshag...@gmail.com
 mailto:asha.seshag...@gmail.com
 mailto:asha.seshag...@gmail.com
 wrote:
 
 Thanks Douglas for your response and appreciate for pointing me
 to the right link
 
 I was talking about the tempest tests to validate the Barbican 
 APIs Please find the spec[1] and blue print link [2] for the
 same .
 
 [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-t
e

 
sts.html
 http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-te

 
sts.html
 
 
 [2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-
ba

 
rbican
 
 Are above specs and blueprint have become void for Barbican? Now
 I could use the  link sent by you for validating the APIs
 
 Thanks and Regards, Asha Seshagiri
 
 
 
 
 On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendizábal 
 douglas.mendiza...@rackspace.com
 mailto:douglas.mendiza...@rackspace.com
 mailto:douglas.mendiza...@rackspace.com
 mailto:douglas.mendiza...@rackspace.com wrote:
 
 Hi Asha,
 
 I'm not sure what you mean by tempest tests.  If you're
 looking for Functional Tests for Barbican, then you can find them
 in the functionaltests directory [1] inside the Barbican repo.
 
 We have no intentions of adding Barbican specific tests to the 
 Tempest repo.  It's my understanding that Tempest is moving away 
 from one monolithic repository into a modular approach using 
 tempest-lib.
 
 - Douglas Mendizábal
 
 [1] 
 http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest

 
 
 s
 
 
 On 7/1/15 2:12 PM, Asha Seshagiri wrote:
 Hi All ,
 
 Has anyone done the Tempest tests for Barbican API Any help 
 would be highly appreciated.
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 
 _
_

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

 

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

 
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 
 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 _
_

 

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

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 __


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

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 -- /Thanks and Regards,/ /Asha Seshagiri/
 
 
 __


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

Re: [openstack-dev] [all] [stable] No longer doing stable point releases

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I tend to agree with Thomas that plan D is not ideal.  For one, it
prevents changes to the stable branch that span multiple CRs, since a
two patch change would generate two tags and there would be no clear
indication that the first patch should not be released on its own.

My preference would be for Plan C where the PTL would push a new
2015.1.XXX tag when an important fix (or fixes) lands in a stable branch
.

I also disagree with Morgan that packagers are better informed to make
the determination of when to release.  PTLs should be aware of all
changes landing in the stable branches, and should be able to push a
tag immediately after an important fix lands.  Asking the packagers to
make the determination means that they would have to be aware of every
patch landing in every project, which I think is a lot to ask.

- - Douglas Mendizábal

On 6/17/15 9:55 AM, Morgan Fainberg wrote:
 
 On Jun 16, 2015, at 14:56, Thomas Goirand z...@debian.org
 wrote:
 
 On 06/16/2015 12:06 PM, Thierry Carrez wrote:
 It also removes the stupid encouragement to use all
 components from the same date. With everything tagged at
 the same date, you kinda send the message that those
 various things should be used together. With everything
 tagged separately, you send te message that you can mix
 and match components from stable/* as you see fit. I mean,
 it's totally valid to use stable branch components from
 various points in time together, since they are all
 supposed to work.
 
 Though there's now zero guidance at what should be the speed
 of releasing server packages to our users.
 
 I really think it should be a distribution decision. You could
 release all commits, release every 2 months, release after each
 CVE, release as-needed when a bug in Debian BTS is fixed. I
 don't see what guidance upstream should give, apart from
 enabling all models. Currently we make most models more
 difficult than they should be, to promote an arbitrary 
 time-based model. With plan D, we enable all models.
 
 Let me put this in another way: with the plan D, I'll be lost,
 and wont ever know when to release a new stable version in
 Debian. I don't know better than anyone else. If we had each
 upstream project saying individually: Ok, now we gathered enough
 bugfixes so that it's important to get it in downstream
 distributions, I'd happily follow this kind of guidance. But the
 plan is to just commit bugfixes, and hope that downstream distros
 (ie: me in this case) just catch when a new release worse the
 effort.
 
 As pointed elsewhere, plan D assumes we move to generating
 release notes for each commit. So you won't lose track of what
 is fixed in each version. If anything, that will give you
 proper release notes for CVE-fix commits, something you didn't
 have before, since we wouldn't cut a proper point release after
 a CVE fix but on a pre-determined time-based schedule.
 
 Overall, I think even your process stands to benefit from the
 proposed evolution.
 
 I just hope so. If any core / PTL is reading me in this thread, I
 would strongly encourage you guys to get in touch and ping me
 when you think some commits in the stable release should be
 uploaded to Debian. A quick message on IRC can be enough.
 
 
 For what it is worth, I trust the downstream distributions to make
 this call. I expect that any/all stable patches accepted in a model
 where release notes are generated per-commit (Plan D) this ends up
 looking like the Redhat model where patches are bundled in.
 
 In general we should have care in accepting a stable patch. But as
 the PTL (and more generally as a core) asking me to determine when
 there is enough patches to generate a release is far too
 distribution/packager specific and subjective. I do not expect to
 be reaching out to each and every one to say hey did you release?
 This, in my opinion is not a reasonable ask. I do not know what
 justifies time for a release for Debian or Redhat or Suse or
 Gentoo ... Etc. Please do not expect the PTLs and Cores to become
 experts on each and every one of these. I expect the packager to be
 making the subjective call in the non-time-based model outlined.
 
 --Morgan 
 __


 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVgZTgAAoJEB7Z2EQgmLX7qhkP/RwB4sJU2nXeAe4M27VXT/9t
tPD3j0njOMuL6T5g41D/aXIcEvvk1RqjJOg+VdXq7Os3t0AAHNkKng85qGKp+Our
xMOSGBtFjqQycDDVEFrltYCkhmDdmsVw4SWd0zmJ2MHzn+R014lZL5SdsHjhWmRr
c3NfZH0Cxm9ujfMbdjsZoF3i6noZsotUZLy5Tu5iW/Kp46syNDfA47Fxya15T54a
LyA3Qqw/C/1Nov89IyS0AA4nv5BzmWGh8+t6rZnC2NQUPVGVnvnpr5KOIadbwqEh
BtLQWaeXDlbJPovCpHnZ9CUwtIZRdYUXoXgdYJVFcBMmDM0NrIWX4+YlJ5rCgdeC
lVkH9HhUfrBSpgh59sh

Re: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since there are no objections, Chelsea Winfree is now part of
barbican-core.  Congratulations!

- - Douglas Mendizábal

On 5/21/15 6:58 PM, Nathan Reller wrote:
 +1
 
 On Thu, May 21, 2015 at 4:53 PM, Juan Antonio Osorio 
 jaosor...@gmail.com wrote:
 +1
 
 On Thu, May 21, 2015 at 11:05 PM, John Wood
 john.w...@rackspace.com wrote:
 
 +1
 
  From: Chad Lung
 chad.l...@gmail.com Sent: Sunday, May 17, 2015 6:34 PM To:
 openstack-dev@lists.openstack.org Subject: [openstack-dev]
 [Barbican] Nominating Chelsea Winfree for Barbican core
 
 Hi all,
 
 I'd like to nominate Chelsea Winfree for the Barbican core
 review team.
 
 Chelsea has been active in Barbican as a regular contributor of
 code and helping always needed documentation. 
 http://stackalytics.com/?user_id=chelsea-winfreerelease=all
 
 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,
 
 Chad Lung EMC Cloud Services
 
 
 
 
__

 
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





 
- --
 Juan Antonio Osorio R. e-mail: jaosor...@gmail.com
 
 
 _
_

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

iQIcBAEBCgAGBQJVY2CyAAoJEB7Z2EQgmLX7a8wP+gJPQywz3hJwiE51kupcIi6W
z0Uy7QrC41CF91IyEMlGclp1oXPCGFdYb0XFNGGJbu9VoLxdUM5E48EbkjQHRcV/
WNSYiXapfzWx2P23zP33FPvsf2z+Lg8mSlbNeCrV9KCOgDb6vXR37wq1mho5vYyA
RS0mqi6CTQht2o24qhB0HnHqDXHTCfzpSTE3ljrtzLtjSJj1B/f7Dwof3Ek3cLnq
eA88WFiXftQSpKGw/XDvFn7jzHMuXkRWN8MhXV3/gqvNUOmtRaogeO2xg+vGIW1s
8E8iyUKwKjZhj03DTvSKzdLd7RSujXPblzIpulXA2kl9lXurmtRnBDOBqvO7wlyJ
7POB627vMs5ci/T8yYIaBMqxxaXgPNJuH/Kiz4MbcpqzmVtgnAHbNqZvTwCdNwMz
ArFJxvKwxMBL8rQdjEwSaXRrUACYKSwkTT08lcYQZ/g2+yi6oz5EkREztdwIZBkF
ZeSP2kKvpssEbZ0E4B8u16wo/xA1/MFdftzg8YfjK7/aZ/Zx6aFPkKSYxB2R7gNO
f2Ep0SEImswe+cACqoeFv8ba8pNIruBGv34amNsYyp6c91a/6FyvRy0hP0E73iXp
7MMoLoJN37lUM0/bAUaTT6PB1RNw6WOUsc/Bvc3HFW6aR4w+7XrrymuJnctJgny0
0uS/xOd3JdTfcmxVhQK1
=9U0h
-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-dev] [barbican] Weekly meeting cancelled today

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi All,

The Barbican weekly meeting is cancelled today because of the US
holiday.  Meetings will resume next week at the regularly scheduled time
.

Thanks,

- - Douglas Mendizábal
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY16nAAoJEB7Z2EQgmLX7UMUP/0AEVdM+EVmWw8OKDPx3L5Vi
2cV4MOgfdnDv+y+yZAWG0HZwi4Bu/2UJTDzACC9DqcmSk3WJ71ULdoIqerWj0Emn
F/4ozEyb/NRoIJWrDgVPAmlnx8Wr8igcDt/tJD8jbjGvU2xGUPAW1FsB5NSsax7d
2CgSED0md1jJxdSBi6Y6+onPzGCMfjFH90eGie/Cz5Z1qn5mRfP9/TPBhQYvqsbO
isV+BADjLmJSvW2c9jkTpIhpnhUTbFauIk/bEZxlEQG1U70NHujs8+/yoVm6IHSt
bWdr1IunNiUt2RY7cU4Ys/Xpkk0KGc3dnEZkI/FJAVLR+8noGJUArrX9XBB9ffAz
4bbj5I9WWJnK4TXT1THMnUwUQ00XFtLSo4AFt+B5ZZm3JoiIxmfgnEJwIC804RNB
VtoULCPx0PaM1LZNE8ZfnZvM+tk6h0U1BP2c6B/7hdKD4vni4jKb2DoFMhzIyLEB
NLjL+eA9J5vkb9+Jx8kkAKMONT5W6JAitgq4Oopj3/Jo/LaKT0CoIpILT6BLTkNk
73AmvqRpEoZPSGUJKvPZ5YHycDamPkl/H8jQUzPTSRFsX+mApZsg04hrdKteMeYi
6wo6zyEyUa5EIJoeixTCTbJlDxNN+NYuclIH3rtXZ0KhAvt1cXO5Ns4hDAjfClU6
BSNFVfKfVIy0WTgrpPdb
=F9+H
-END PGP SIGNATURE-

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

Re: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since there are no objections, Kaitlin Farr is now part of
barbican-core.  Congratulations!

- - Douglas Mendizábal

On 5/24/15 12:19 PM, Chad Lung wrote:
 
 +1
 
 Chad Lung EMC Cloud Services
 
 
 / I would like to nominate Kaitlin Farr for barbican-core.
 // // Kaitlin has been contributing to the project for a long
 time, both by // contributing code to Barbican,
 python-barbicanclient and Castellan, // and also by providing
 valuable reviews. [1] // // As a reminder to the rest of the core
 team, we use the process // outlined in
 https://wiki.openstack.org/wiki/Barbican/CoreTeam to add //
 members to the barbican-core team. // // Thanks, // Douglas
 Mendizábal/
 
 
 
 
 __


 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVY2GYAAoJEB7Z2EQgmLX7ByQP/AvBG2GRW25gtyxL+MFY/AHz
hlZyqS3Hy+c++G/AjwAlVc8p2Ik7t50cqJ0kEaPva5E77JBhLT9yppD1W58gAvjj
jS8e0m+PhZU+3rHLl1UqHFLye1q/tHo4XAmibAAybgxMb42EcwjpPx8vQFXueBmg
7WJyU9tCFatB9fU7F+zHWn0PrAA28FCWMgPwv4dgBpx0z2Ud1xPYmYp/TN4kKAVs
T2jIqc0qYdG9/vBG81rQ+r68mAGrr2896fu1MQiztUYwixeih08VDdl/itAU3piD
kKAo9QGFjUnPWL53J+Bx9TEWZjxB98DcKl57eE9XA0BphG2JeaIvgbMO9A0BArvt
gi+ELScO/Ih5GQ6A9MzzxMltv2GFyxmcVi7yQtKDGkdsOSiD3AnArVPyC7bb+7FV
V9eVuXg0enU7qbSSIErKc5BQQwAYMwoeA5y5tplqE6xv3vpsc57pIgxcOxUbSrYd
FneGNxqqwBM6Si/1SoB7bAQQUs94tJkW+TAfjJ88wKdglDnmz/9DRvJBsL9/1vcH
RHWreMmC5VRobzInzRVL2EBaGluqQglHx88EdSlrlD4cgxkPoPUAEa8c07iWewXn
g6qLFPqUqduJ+Ga8k5u2HzvHKT2XYB/JAUaZ2vvY9aRbiFPCDuqm5frZwC4pkevy
i5GCV4iCcu0mc71R2VfG
=bO+O
-END PGP SIGNATURE-

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

Re: [openstack-dev] [Barbican] Nominating Chelsea Winfree for Barbican core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+1 from me as well.

- - Douglas Mendizábal

On 5/18/15 7:38 AM, John Vrbanac wrote:
 ?+1
 
 
 John Vrbanac 
 --
- --

 
*From:* Chad Lung chad.l...@gmail.com
 *Sent:* Sunday, May 17, 2015 6:34 PM *To:*
 openstack-dev@lists.openstack.org *Subject:* [openstack-dev]
 [Barbican] Nominating Chelsea Winfree for Barbican core
 
 Hi all,
 
 I'd like to nominate Chelsea Winfree for the Barbican core review
 team.
 
 Chelsea has been active in Barbican as a regular contributor of
 code and helping always needed documentation. 
 http://stackalytics.com/?user_id=chelsea-winfreerelease=all
 
 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,
 
 Chad Lung EMC Cloud Services
 
 
 
 
 __


 
OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVXBywAAoJEB7Z2EQgmLX7iYMQAJcWp3AnX/cls/Ln+QrTylNQ
Yj9OYSw1RNFI9+d0B+IP3M3RsaKEVmSZ+n2SeXX6NOFYs9HRJsyk6Icj/u/xi+t2
a+hslDHH8NQnG5ZiYqRzDupfpsxNzi474auVdZESldXP8orjuesDVRNcwMWcwsSv
DmxcYph73aU5pKeZ1E6Ami08xVauVvWnrvItlNpOd5QenH7nVEDxOioI5u6NxK5M
j5KApPfpx8RmpNSvfe3jcFD1qxOaA637mZaKdeUf71+sfFGRCCAoGGQR9xYIdEdZ
wG6okvZH/zDXY1dC+LWpR/btjrfHAYMUb01NYlHizcttHrZDeXpWone4TXDpEF7U
P8IUb1HDRKXrYCWPWY61kzxbgziUV+04WMEAUcdK/AcQRBCkVm7TbOhb3I2a80Uv
TuEGX/jwXxT9bmrtFRIsPZhyyH8tG+VKQV8vZ4cUh9pCKI5maPBN/NzSXPjYR91L
uYH2lofx5cdBnamnJNGhPFlGKbiQg/xjAA+1U3Wfu3GlWBu5AO2c8XHM82eENLzt
35ozZEXjp1bJL3UZCzl/ZeFJseJJ4WN75EAiKcg2jMg2sRXJ4x3i1Ko9fkEhCkDF
pI7sLls2BMl320cectIXSULjMx1nWEPGZsjs4XJfUkaG8o9fpFVEilQ+5PnlcqYD
Sag66Hm2mGpN+Tyh+ieg
=Qaep
-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-dev] [keystone][nova][barbican] VM-spec discussion

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi All,

Kevin Fox and I were wondering if there's a good time today where we
could get together with someone from Keystone and Nova to talk through
the vm-integration spec. [1]

This is the spec to be able to have credentials which are unique to
each new vm so that the vm is able to access a secret in Barbican.

Thanks,

Douglas Mendizábal

[1] https://review.openstack.org/#/c/159571/
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVXLnnAAoJEB7Z2EQgmLX73nIQAIBJNosFdyYIjhfOg5v51B82
ADZa0PCoTPW9/LWceYw2iqWCgF5CjXcUkj1t//dtjUCIRlGHFQzLAji8nlYl7KqH
lnCTjsoFmEZxbNXp+XaJkm8k20IekbOUWz+voQI8tBn4K4f5QxZqQOkmnHpjoJhE
VQOI2Gf/3F/bpR3rzLDqgxOts5c97GXJJP5oigg1lUavgnVEnWKwrGjF8RQPB54I
SQPWEuY2iHqXCIWPkbBT6+Z9ehETnRzP42ja9I3h88ye2f8OxJCh5ICKjHP2EnQv
lFbW5GVtX/NH+edoOsxeCPCZjq20bxe0im+5WIjZqAbzvcC5k0/wJvATasGSKEuf
UbypM7Lv5cSfTWEEEvZEniDC6TGEnpBzr7ummG6YANlYnC6piM6/Q9GytHPZR3f3
JBWM24vextpOb73H3HltWNxfNkeQ8FtAMlANuN1E38/Mzt59g2WtNpyTCXKURqwn
HxxvXFkejXBBFpsT4mNYk5UaJ//XVIcVUxTeTssqk+2Ci/6jl7h+WctHV9kUkm3k
z+yyw8TVFI7VtdaVETBexwgJ1e04Z+LTkqauq8xqOMNjdxrz7oZALDWDJrDMN1HW
OoYf+J/mk4Xdx2GGhkw+UJMFbcBER/EqWyA7jd/6g+hEUTFMRn0b1/bN9g26Xjw1
+YI3dIpxfd9cFOvrdVMM
=Hn3b
-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-dev] [barbican] Nominating Kaitlin Farr for barbican-core

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi All,

I would like to nominate Kaitlin Farr for barbican-core.

Kaitlin has been contributing to the project for a long time, both by
contributing code to Barbican, python-barbicanclient and Castellan,
and also by providing valuable reviews. [1]

As a reminder to the rest of the core team, we use the process
outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
members to the barbican-core team.

Thanks,
Douglas Mendizábal

[1] http://stackalytics.com/report/contribution/barbican-group/90
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
/Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
/XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
WaeQpFjA1SdFHj5uPNZk
=1OIW
-END PGP SIGNATURE-

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

Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm very much interested in talking with some Keystone folks about
this auth issue.  I would be willing to dedicate a Barbican Working
Session to this discussion if there is a time slot that works for all
the interested parties.

- - Douglas Mendizabal

On 5/14/15 3:13 PM, Fox, Kevin M wrote:
 If there's a free session, can we dedicate a session specifically
 to the zaqar, barbican, sahara, heat, trove, guestagent, keystone
 auth thingy so everyone's all together?
 
 Thanks, Kevin  From: Flavio
 Percoco [fla...@redhat.com] Sent: Thursday, May 14, 2015 12:15 PM 
 To: Sergey Lukjanov Cc: OpenStack Development Mailing List (not for
 usage questions) Subject: Re: [openstack-dev] [trove][zaqar] Trove
 and Zaqar integration. Summit working session
 
 On 14/05/15 10:07 -0700, Sergey Lukjanov wrote:
 Hey,
 
 in Sahara we're looking on using Zaqar as a transport for agent
 some day as well. Unfortunately this section overlaps with Sahara
 sessions.
 
 Sergey,
 
 We still have some free sessions, we'd be happy to dedicate one to 
 Sahara. Any slot that looks good for you?
 
 http://libertydesignsummit.sched.org/overview/type/design+summit/Zaqar
#.VVT0CvYU9hE

  Thanks, Flavio
 
 
 On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco
 fla...@redhat.com wrote:
 
 On 13/05/15 18:06 +, Fox, Kevin M wrote:
 
 Sahara also has the same problem, but worse, since they currently
 only support ssh with their agent, so its either assign floating
 ip's to all nodes, or your sahara controller must be on your one
 and only network node so it can tunnel. :/
 
 Should we have a chat with them too?
 
 
 We've scheduled a discussion with Trove's team on Thursday at
 5pm. It'd be great to have this discussion once and together to
 know what the common issues are and what things need to be done.
 
 I'll ping folks from both teams to invite them to this session.
 If they can't make it, I'm happy to use another working session
 slot.
 
 Cheers, Flavio
 
 http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b679
2e1cef

 
#.VVRL0PYU9hE
 
 
 
 
 Thanks, Kevin  From: Zane
 Bitter [zbit...@redhat.com] Sent: Wednesday, May 13, 2015 10:26
 AM To: openstack-dev@lists.openstack.org Subject: Re:
 [openstack-dev] [trove][zaqar] Trove and Zaqar integration.
 Summit working session
 
 On 11/05/15 05:49, Flavio Percoco wrote:
 
 On 08/05/15 00:45 -0700, Nikhil Manchanda wrote:
 
 3)  The trove-guest-agent is in vm. it is connected by 
 taskmanager by rabbitmq. We designed it. But is there some
 prectise to do this? how to make the vm be connected in
 vm-network and management network?
 
 
 Most deployments of Trove that I am familiar with set up a 
 separate RabbitMQ server in cloud that is used by Trove. It is
 not recommended to use the same infrastructure RabbitMQ server
 for Trove for security reasons. Also most deployments of Trove
 set up a private (neutron) network that the RabbitMQ server and
 guests are connected to, and all RPC messages are sent over this
 network.
 
 
 We've discussed trove+zaqar in the past and I believe some folks 
 from the Trove team have been in contact with Fei Long lately
 about this. Since one of the projects goal's for this cycle is to
 provide support to other projects and contribute to the adoption,
 I'm wondering if any of the members of the trove team would be
 willing to participate in a Zaqar working session completely
 dedicated to this integration?
 
 
 +1
 
 I learned from a concurrent thread ([Murano] [Mistral] SSH
 workflow action) that Murano are doing exactly the same thing
 with a separate RabbitMQ server to communicate with guest agents.
 It's a real waste of energy when multiple OpenStack projects all
 have to solve the same problem from scratch, so a single answer
 to this would be great.
 
 In that thread I suggested (and Murano developers agreed with)
 making the transport pluggable so that operators could choose
 Zaqar instead. I would strongly support doing the same here.
 
 
 +1 :)
 
 Flavio
 
 
 
 
 cheers, Zane.
 
 
 It'd be a great opportunity to figure out what's really needed, 
 edge cases and get some work done on this specific case.
 
 Thanks, Flavio
 
 
 
 _
_

 
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 

Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+1 to a Keystone and Oslo solution for this problem.  One of my
objections to Kevin's spec for Barbican is the copying of Keystone
code into the Barbican tree.  It seems to me like a code smell that
we're trying to solve a problem that Keystone should be solving.

Like I mentioned in the other thread [1]  I would be willing to
schedule this discussion during one of the Barbican Working Sessions.

I'm also very interested in learning more about the Policy work being
done, since we recently did a lot of work to provide additional
policies for some of our contributors who find the current Keystone
models burdensome. [2]

- - Douglas Mendizábal

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-May/064196.html

[2]
http://specs.openstack.org/openstack/barbican-specs/specs/kilo/add-creat
or-only-option.html

On 5/12/15 8:43 PM, Zane Bitter wrote:
 On 12/05/15 13:06, Georgy Okrokvertskhov wrote:
 There is one thing which still bothers me. It is authentication.
 Right now with separate RabbitMQ instance we keep VMs
 authentication isolated from OpenStack infra. This is still a
 problem if you want to use webhooks (Heat autoscaling, Murano
 actions) via our own authentication models. If we plan to use 
 Zaqar it will be interesting to know how Zaqar solves this
 issue.
 
 Aha, if you'd read my blog post you would know the answer ;)
 
 There's no specific provision for this in Zaqar at the moment
 AFAIK. The problem is really Keystone: it was never designed for
 authenticating applications to the cloud, only real live users.
 
 We need to fix this, in Keystone  Oslo, for the benefit of all 
 application-facing services. Some work has already started:
 
 - Keystone can now support separate backends for separate domains,
 so even if you are backed by read-only LDAP you can create service
 users in a separate DB-backed domain: 
 http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/

  - Work is planned on Dynamic Policy to make the authorisation
 model more powerful: 
 http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
 
 I'm not sure that this goes far enough though (although I don't 
 completely grok the implications of Dynamic Policy). We really
 want users to be able to define their own policy for application
 accounts that they create, and at an even more fine-grained level,
 so a common library for this sort of authorisation would be
 helpful.
 
 Frankly, I don't think that this is a good idea to use Keystone 
 credentials or tokens for MQ clients on VMs. This topic,
 probably, deserves its own e-mail thread.
 
 Keystone credentials _are_ the answer, but they must not be the
 *user's* Keystone credentials.
 
 I can tell you how Heat does this right now for authenticating 
 application callbacks for WaitConditions. It's not exactly pretty,
 but it works. Basically we create the application users in a
 separate domain and then do extra authorisation checks ourselves.
 Steve Hardy wrote a comprehensive summary on his blog: 
 http://hardysteven.blogspot.com/2014/04/heat-auth-model-updates-part-2
- -stack.html

 
 
 So the mechanisms are there. In the short term we'd need some 
 cross-project co-operation to define a system through which we can
 do this across projects (i.e. Murano or any other service can
 create a user and have Zaqar authorise it for listening on a
 particular queue). Maybe this is an extra parameter when creating a
 queue in Zaqar to also create a user account in a separate domain
 (the way Heat does) with permission to send and/or receive only on
 that particular queue and return its credentials. That would be
 easier to secure and easier to implement than having other services
 create the user accounts themselves.
 
 In the medium term hopefully we'll be able to come up with a less
 hacky solution that uses Oslo libraries to manage all of the user
 creation and authorisation.
 
 It will be interesting to discuss this with Keystone team. What
 is it is possible to have a token which is restricted to be
 authenticated to specific API URL like  GET
 /v1/queues/queue-id/
 
 Yes, we should definitely discuss this with the Keystone team and
 make sure they're getting feedback from all of the many groups who
 need it so that they can prioritise the work appropriately :)
 
 cheers, Zane.
 
 
 Thanks Gosha
 
 
 
 On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M
 kevin@pnnl.gov mailto:kevin@pnnl.gov wrote:
 
 +1  From: Zane Bitter
 [zbit...@redhat.com mailto:zbit...@redhat.com] Sent: Monday,
 May 11, 2015 6:15 PM To: openstack-dev@lists.openstack.org 
 mailto:openstack-dev@lists.openstack.org Subject: Re:
 [openstack-dev] [Murano] [Mistral] SSH workflow action
 
 Hello!
 
 This looks like a perfect soapbox from which to talk about my 
 favourite issue ;)
 
 You're right about the ssh idea, for the reasons discussed
 related to networking and a few more that weren't (e.g

Re: [openstack-dev] Barbican : Unable to execute the curl command for uploading/retrieving the secrets with the latest Barbican code.

[Douglas Mendizábal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Asha,

The reason we support an Unauthenticated Context in Barbican is purely
for development purposes.  We recommend that all production Barbican
deployments use Keystone or an alternative AuthN/AuthZ service in
front of Barbican.

Setting up a working Keystone environment just to hack on Barbican is
a steep requirement, which is why we need the Unauthenticated Context
to work.

- - Douglas Mendizabal

On 5/14/15 6:07 PM, Asha Seshagiri wrote:
 Thanks a lot John for your response. But would like to know why do
 would we have to fix the issue for creating the secret for
 unauthenticated context for Barbican since it would be good to have
 access control mechanism  enforced to access secrets , orders and
 other entities from Barbican.
 
 This should be the expected behavior from security perspective .And
 also we are able to access secrets by providing the right token
 from the Identity service (Keystone ). Looking forward for your
 response.
 
 Thanks and Regards, Asha Seshagiri
 
 On Thu, May 14, 2015 at 4:43 PM, John Vrbanac 
 john.vrba...@rackspace.com mailto:john.vrba...@rackspace.com
 wrote:
 
 __ Asha, I spent some time looking into this, It looks to be a
 regression that occurred a few days ago when a CR was merged that
 moved us over to oslo_context. I have reported the issue here: 
 https://bugs.launchpad.net/barbican/+bug/1455247
 
 I have a couple ideas on how to fix it, so keep your eyes out for
 a CR to resolve the issue.
 
 John Vrbanac
 
 
 
 On Thu, 2015-05-14 at 12:26 -0500, Asha Seshagiri wrote:
 Hi all ,
 
 
 We are able to execute the curl commands on new barbican code 
 provided we integrated it with keystone . I ran into this issue
 because I was trying to configure localhost to actual IP on a
 plain barbican server so that I would get the response and
 request objects with the actual IP rather than the local host . 
 This configuration was required for seting up HA proxy for
 Barbican.
 
 And then I thought of integrating with the keystone and
 configure Babrican server to https.
 
 *Its a good learning to know that the latest code drop of
 Barbican enforces the authentication mechanism with the keystone
 which would not allow us to execute the curl command without
 providing the token of Identity service (Keystone ) in the
 request unlike the previous Barbican versions*
 
 Please find the curl command request and responses for 
 uploading/reteriving the secets on Barbican Server
 
 root@Clientfor-HAProxy barbican]# curl -X POST -H 
 'content-type:application/json' -H 'X-Project-Id:12345' \
 -H X-Auth-Token:c9ac81784e1e4e089fccbca19f862be2 -d
 '{payload: my-secret-here,payload_content_type:
 text/plain}' \
 -k https://localhost:9311/v1/secrets
 {secret_ref: 
 https://localhost:9311/v1/secrets/02336016-623b-4deb-bca5-caedc0bf0e
35}[root@Clientfor-HAProxy

 
barbican]#
 
 [root@Clientfor-HAProxy barbican]# curl -H 'Accept: 
 application/json' -H 'X-Project-Id:12345' \
 -H X-Auth-Token:c9ac81784e1e4e089fccbca19f862be2 -k
 https://localhost:9311/v1/secrets {secrets: [{status:
 ACTIVE, secret_type: opaque, updated:
 2015-05-14T16:35:44.109536, name: null, algorithm: null,
 created: 2015-05-14T16:35:44.103982, secret_ref: 
 https://localhost:9311/v1/secrets/02336016-623b-4deb-bca5-caedc0bf0e
35,

 
content_types: {default: text/plain}, creator_id:
 cedd848a8a9e410196793c601c03b99a, mode: null, bit_length: 
 null, expiration: null}], total: 1}[root@Clientfor-HAProxy 
 barbican]#
 
 Thanks and Regards, Asha Seshagiri
 
 On Wed, May 13, 2015 at 4:26 PM, Asha Seshagiri 
 asha.seshag...@gmail.com mailto:asha.seshag...@gmail.com
 wrote:
 
 Hi all ,
 
 
 
 When I started  debugging ,we find that default group  is not 
 used instead oslo_policy would be used
 
 Please find the logs below :
 
 
 *2015-05-13 15:59:34.393 13210 WARNING oslo_config.cfg [-] Option
 policy_default_rule from group DEFAULT is deprecated. Use
 option policy_default_rule from group oslo_policy.* 
 *2015-05-13 15:59:34.394 13210 WARNING oslo_config.cfg [-] Option
 policy_file from group DEFAULT is deprecated. Use option
 policy_file from group oslo_policy.* 2015-05-13 15:59:34.395
 13210 DEBUG oslo_policy.openstack.common.fileutils 
 [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] 
 Reloading cached file /etc/barbican/policy.json read_cached_file 
 /usr/lib/python2.7/site-packages/oslo_policy/openstack/common/fileuti
ls.py:64

 
2015-05-13 15:59:34.398 13210 DEBUG oslo_policy.policy
 [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] Reloaded
 policy file: /etc/barbican/policy.json _load_policy_file 
 /usr/lib/python2.7/site-packages/oslo_policy/policy.py:424 
 2015-05-13 15:59:34.399 13210 ERROR barbican.api.controllers 
 [req-0c6d2db4-bc15-4752-93ca-5203cf742d79 - 12345 - - -] Secret
 creation attempt not allowed - please review your user/project
 privileges 2015-05-13 15:59:34.399 13210 TRACE
 barbican.api.controllers Traceback (most recent call last):