Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core

[John Wood]

+1

From: Juan Antonio Osorio 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Monday, November 7, 2016 at 9:42 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [barbican] Nominating Arun Kant for barbican-core


+1

On 7 Nov 2016 17:18, "Dave McCowan (dmccowan)" 
mailto:dmcco...@cisco.com>> wrote:

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

100% +1


--Dave

On 11/7/16, 9:37 AM, "Ade Lee" mailto:a...@redhat.com>> wrote:

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


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

[John Wood]

+1

On 2/16/16, 12:52 PM, "Ade Lee"  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

Re: [openstack-dev] Barbican : Unable to run barbican CURL commands after starting/restarting barbican using the service file

[John Wood]

Hello Asha,

Please make sure you are using the latest barbican-api-paste.ini file in your 
/etc/barbican directory, and then try again.

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Wednesday, September 16, 2015 at 12:39 AM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Vrbanac 
mailto:john.vrba...@rackspace.com>>, Douglas 
Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
John Wood mailto:john.w...@rackspace.com>>, "Reller, 
Nathan S." mailto:nathan.rel...@jhuapl.edu>>
Subject: Barbican : Unable to run barbican CURL commands after 
starting/restarting barbican using the service file

Hi All,

I am Unable to run barbican CURL commands after starting/restarting barbican 
using the service file.

Used below command to run  barbican service file :
(wheel)[root@controller-01 service]# systemctl restart barbican-api.service

When I tried executing the command to create the secret , I did not get any 
response from the server .

(wheel)[root@controller-01 service]# ps -ef | grep barbican
barbican  1104 1  0 22:56 ?00:00:00 /opt/barbican/bin/uwsgi 
--master --emperor /etc/barbican/vassals
barbican  1105  1104  0 22:56 ?00:00:00 /opt/barbican/bin/uwsgi 
--master --emperor /etc/barbican/vassals
barbican  1106  1105  0 22:56 ?00:00:00 /opt/barbican/bin/uwsgi --ini 
barbican-api.ini
root  3195 28132  0 23:03 pts/000:00:00 grep --color=auto barbican

Checked the status of the barbican-api.service file and got the following 
response :

(wheel)[root@controller-01 service]# systemctl status  barbican-api.service -l
barbican-api.service - Barbican Key Management API server
   Loaded: loaded (/usr/lib/systemd/system/barbican-api.service; enabled)
   Active: active (running) since Tue 2015-09-15 22:56:12 UTC; 2min 17s ago
 Main PID: 1104 (uwsgi)
   Status: "The Emperor is governing 1 vassals"
   CGroup: /system.slice/barbican-api.service
   ├─1104 /opt/barbican/bin/uwsgi --master --emperor 
/etc/barbican/vassals
   ├─1105 /opt/barbican/bin/uwsgi --master --emperor 
/etc/barbican/vassals
   └─1106 /opt/barbican/bin/uwsgi --ini barbican-api.ini

Sep 15 22:58:30 controller-01 uwsgi[1104]: APP, pipeline[-1], global_conf)
Sep 15 22:58:30 controller-01 uwsgi[1104]: File 
"/opt/barbican/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 458, 
in get_context
Sep 15 22:58:30 controller-01 uwsgi[1104]: section)
Sep 15 22:58:30 controller-01 uwsgi[1104]: File 
"/opt/barbican/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 517, 
in _context_from_explicit
Sep 15 22:58:30 controller-01 uwsgi[1104]: value = import_string(found_expr)
Sep 15 22:58:30 controller-01 uwsgi[1104]: File 
"/opt/barbican/lib/python2.7/site-packages/paste/deploy/loadwsgi.py", line 22, 
in import_string
Sep 15 22:58:30 controller-01 uwsgi[1104]: return 
pkg_resources.EntryPoint.parse("x=" + s).load(False)
Sep 15 22:58:30 controller-01 uwsgi[1104]: File 
"/opt/barbican/lib/python2.7/site-packages/pkg_resources.py", line 2265, in load
Sep 15 22:58:30 controller-01 uwsgi[1104]: raise ImportError("%r has no %r 
attribute" % (entry,attr))
Sep 15 22:58:30 controller-01 uwsgi[1104]: ImportError:  has no 
'create_main_app_v1' attribute


Please find contents of  barbican-api. service file :

[Unit]
Description=Barbican Key Management API server
After=syslog.target network.target

[Service]
Type=simple
NotifyAccess=all
User=barbican
KillSignal=SIGINT
ExecStart={{ barbican_virtualenv_path }}/bin/uwsgi --master --emperor 
/etc/barbican/vassals
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Even though barbican is running successfully , we are unable to run the CURL 
command . Would like to know if the  "ImportError:  has no 
'create_main_app_v1' attribute" is the cause for not being able to execute the 
CURL commands.

How do we debug ImportError:  has no 
'create_main_app_v1' attribute"
And also I think that barbican restart is not successful.

Any help would highly be appreciated .

But I am able tor run the command  "/bin/uwsgi --master --emperor 
/etc/barbican/vassals" manually and was able to run the CURL commands .


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

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

[John Wood]

AgreedŠ+1

On 9/9/15, 11:17 AM, "michael mccune"  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 
>>
>>
>>
>> 
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

[John Wood]

Hello folks,

Thanks for the consideration of this feature. Does it seem realistic for a 
Liberty release of Keystone middleware to expose X-Group-Ids, or would this be 
an M and beyond sort of thing?

Thanks,
John


From: Henry Nash mailto:henryna...@mac.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, June 5, 2015 at 12:49 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation

The one proviso is that in single LDAP situations, the cloud provider can chose 
(for backward compatibility reasons) to allow the underlying LDAP user/group 
ID….so we might want to advise this to be disabled (there’s a config switch to 
use the Public ID mapping for even this case).

Henry
On 5 Jun 2015, at 18:19, Dolph Mathews 
mailto:dolph.math...@gmail.com>> wrote:


On Fri, Jun 5, 2015 at 11:50 AM, Henry Nash 
mailto:henry.n...@uk.ibm.com>> wrote:
So I think that GroupID's are actually unique and safesince in the multi 
LDAP case we provide an indirection already in Keystone and issue a "Public ID" 
(this is true for bother users and groups), that we map to the underlying local 
ID in the particular LDAP backend.

Oh, awesome! I didn't realize we did that for groups as well. So then, we're 
safe exposing X-Group-Ids to services via keystonemiddleware.auth_token but 
still not X-Group-Names (in any trivial form).



Henry


From:   Dolph Mathews mailto:dolph.math...@gmail.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
Henry Nash mailto:hen...@linux.vnet.ibm.com>>, Henry 
Nash/UK/IBM@IBMGB
Date:   05/06/2015 15:38
Subject:Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group-xxxx in token validation






On Thu, Jun 4, 2015 at 10:17 PM, John Wood 
mailto:john.w...@rackspace.com>> wrote:
Hello folks,

Regarding option C, if group IDs are unique within a given cloud/context, and 
these are discoverable by clients that can then set the ACL on a secret in 
Barbican, then that seems like a viable option to me. As it is now, the user 
information provided to the ACL is the user ID information as found in 
X-User-Ids now, not user names.

To Kevin’s point though, are these group IDs unique across domains now, or in 
the future? If not the more complex tuples suggested could be used, but seem 
more error prone to configure on an ACL.

Well, that's a good question, because that depends on the backend, and our 
backend architecture has recently gotten very complicated in this area.

If groups are backed by SQL, then they're going to be globally unique UUIDs, so 
the answer is always yes.

If they're backed by LDAP, then actually it depends on LDAP, but the answer 
should be yes.

But the nightmare scenario we now support is domain-specific identity drivers, 
where each domain can actually be configured to talk to a different LDAP 
server. In that case, I don't think you can make any guarantees about group ID 
uniqueness :( Instead, each domain could provide whatever IDs it wants, and 
those might conflict with those of other domains. We have a workaround for a 
similar issue with user IDs, but it hasn't been applied to groups, leaving them 
quite broken in this scenario. I'd consider this to be an issue we need to 
solve in Keystone, though, not something other projects need to worry about. 
I'm hoping Henry Nash can chime in and correct me!


Thanks,
John

From: , Kevin M mailto:kevin@pnnl.gov>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, June 4, 2015 at 6:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>

Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation

In Juno I tried adding a user in Domain A to group in Domain B. That currently 
is not supported. Would be very handy though.

We're getting a ways from the original part of the thread, so I may have lost 
some context, but I think the original question was, if barbarian can add group 
names to their resource acls.

Since two administrative domains can issue the same group name, its not safe I 
believe.

Simply ensuring the group name is associated with a user and the domain for the 
user matches the domain for the group wouldn't work because someone with 
control of their own domain can just make a
user and give them the group with the name they want and come take your 
credentials.

What may be safe is 

Re: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican

[John Wood]

Hello Chris,

I defer to Nate and Kaitlin for things KMIP.

>From a config perspective though, it seems that something needs to decide 
>which KMIP backend handles which secret. Where ever that decision-making logic 
>lives (in Barbican or in a proxy that Barbican talks to), it has to know what 
>KMIP backends are available. If this list of backends is known/static then it 
>seems that storing these in a config file (like barbican-api.conf) would be 
>acceptable. Keep in mind that more than one Barbican API node might be hitting 
>the same KMIP backends concurrently.

As for multiple plugins in Barbican, the current approach favors having an 
instance per plugin class, so IMHO it would be better to have a single 
multi-KMIP plugin class that handles the above decision logic. This would most 
likely be your 'active' secret store plugin.

Thanks,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, June 5, 2015 at 12:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican


Hey all.

I wanted to get people's opinion on allowing barbican to talk to multiple KMIP 
servers.
I got good advice from Nathan and John and it seems like it would be pretty 
easy keeping track of
which secret resides in which KMIP applicance. You would just store the url in 
the DTO.
However, in order for barbican to be aware of all KMIP servers wouldn't that 
mean that each
kmip server url would need to be in the barbican-api.conf file? Or somewhere 
for barbican
to know that multiple kmip servers are available? I noticed that there is a 
blueprint to introduce
the concept of a single active and multiple inactive secret store plugins so 
I'm trying to stray away from
making multiple active plugins.

Regards,

  Chris Solis
__
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 : Retrieval of the secret in text/plain format generated from Barbican order resource

[John Wood]

Hello Asha,

Barbican is not yet supporting the conversion of secrets of one format to 
another. If you have thoughts on desired conversions however, please mentioned 
them in this thread, or else consider mentioning them in our weekly IRC meeting 
(freenode #openstack-meeting-alt at 3pm CDT).

Thanks,
John



From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Monday, June 8, 2015 at 12:17 AM
To: John Wood mailto:john.w...@rackspace.com>>
Cc: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>, 
Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Adam Harwell 
mailto:adam.harw...@rackspace.com>>, Paul Kehrer 
mailto:paul.keh...@rackspace.com>>
Subject: Re: Barbican : Retrieval of the secret in text/plain format generated 
from Barbican order resource

Thanks John for your response.
I am aware that application/octet-stream works for the retrieval of secret .
We are utilizing the key generated from Barbican in our AES encryption 
algorithm . Hence we  wanted the response in text/plain format from Barbican 
since AES encryption algorithm would need the key of ASCII format which should 
be either 16,24 or 32 bytes.

The AES encyption algorithms would not accept the binary format and even if 
binary  is converted into ascii , encoding is failing for few of the keys 
because some characters exceeeds the range of ASCII and for some keys  after 
encoding length exceeds 32 bytes  which is the maximum length for doing AES 
encryption.

Would like to know the reason behind Barbican not supporting the retrieval of 
the secret in text/plain format generated from the order resource in plain/text 
format.

Thanks and Regards,
Asha Seshagiri

On Sun, Jun 7, 2015 at 11:43 PM, John Wood 
mailto:john.w...@rackspace.com>> wrote:
Hello Asha,

The AES type key should require an application/octet-stream Accept header to 
retrieve the secret as it is a binary type. Please replace ‘text/plain’ with 
‘application/octet-stream’ in your curl calls below.

Thanks,
John


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Friday, June 5, 2015 at 2:42 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
John Wood mailto:john.w...@rackspace.com>>, "Reller, 
Nathan S." mailto:nathan.rel...@jhuapl.edu>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>, Paul 
Kehrer mailto:paul.keh...@rackspace.com>>
Subject: Re: Barbican : Retrieval of the secret in text/plain format generated 
from Barbican order resource

Hi All ,

I am currently working on use cases for database and file Encryption.It is 
really important for us to know since my Encryption use case would be using the 
key generated by Barbican through order resource as the key.
The encyption algorithms would not accept the binary format and even if 
converted into ascii , encoding is failing for few of the keys because some 
characters exceeeds the range of ASCII and for some key  after encoding length 
exceeds 32 bytes  which is the maximum length for doing AES encryption.
It would be great if  someone could respond to the query ,since it would block 
my further investigations on Encryption usecases using Babrican

Thanks and Regards,
Asha Seshagiri


On Wed, Jun 3, 2015 at 3:51 PM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All,

Unable to retrieve the secret in text/plain format  generated from Barbican 
order resource

Please find the curl command and responses for

Order creation with payload content type as text/plain :

[root@barbican-automation ~]# curl -X POST -H 'content-type:application/json' 
-H "X-Auth-Token:9b211b06669249bb89665df068828ee8" \
> -d '{"type" : "key", "meta": {"name": "secretname2","algorithm": "aes", 
> "bit_length":256,  "mode": "cbc", "payload_content_type": "text/plain"}}'  -k 
> https://169.53.235.102:9311/v1/orders

{"order_ref": 
"https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680"}

Retrieval of the order by ORDER ID in order to get to know the secret generated 
by Barbican

[root@barbican-automation ~]# curl -H 'Accept: application/json' -H 
"X-Auth-Token:9b211b06669249bb89665df068828ee8" \
> -k  https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
{"status": "ACTIVE", "sub_status": "Unknown", "updated": "2015-06-03T19:08:13", 
"created": "2015-06-03T19:08:12", "order_ref": 
"https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680";, 
"secret_ref": 
"https://169.53.

Re: [openstack-dev] Barbican : Retrieval of the secret in text/plain format generated from Barbican order resource

[John Wood]

Hello Asha,

The AES type key should require an application/octet-stream Accept header to 
retrieve the secret as it is a binary type. Please replace 'text/plain' with 
'application/octet-stream' in your curl calls below.

Thanks,
John


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Friday, June 5, 2015 at 2:42 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
John Wood mailto:john.w...@rackspace.com>>, "Reller, 
Nathan S." mailto:nathan.rel...@jhuapl.edu>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>, Paul 
Kehrer mailto:paul.keh...@rackspace.com>>
Subject: Re: Barbican : Retrieval of the secret in text/plain format generated 
from Barbican order resource

Hi All ,

I am currently working on use cases for database and file Encryption.It is 
really important for us to know since my Encryption use case would be using the 
key generated by Barbican through order resource as the key.
The encyption algorithms would not accept the binary format and even if 
converted into ascii , encoding is failing for few of the keys because some 
characters exceeeds the range of ASCII and for some key  after encoding length 
exceeds 32 bytes  which is the maximum length for doing AES encryption.
It would be great if  someone could respond to the query ,since it would block 
my further investigations on Encryption usecases using Babrican

Thanks and Regards,
Asha Seshagiri


On Wed, Jun 3, 2015 at 3:51 PM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All,

Unable to retrieve the secret in text/plain format  generated from Barbican 
order resource

Please find the curl command and responses for

Order creation with payload content type as text/plain :

[root@barbican-automation ~]# curl -X POST -H 'content-type:application/json' 
-H "X-Auth-Token:9b211b06669249bb89665df068828ee8" \
> -d '{"type" : "key", "meta": {"name": "secretname2","algorithm": "aes", 
> "bit_length":256,  "mode": "cbc", "payload_content_type": "text/plain"}}'  -k 
> https://169.53.235.102:9311/v1/orders

{"order_ref": 
"https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680"}

Retrieval of the order by ORDER ID in order to get to know the secret generated 
by Barbican

[root@barbican-automation ~]# curl -H 'Accept: application/json' -H 
"X-Auth-Token:9b211b06669249bb89665df068828ee8" \
> -k  https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680
{"status": "ACTIVE", "sub_status": "Unknown", "updated": "2015-06-03T19:08:13", 
"created": "2015-06-03T19:08:12", "order_ref": 
"https://169.53.235.102:9311/v1/orders/727113f9-fcda-4366-9f85-93b15edd4680";, 
"secret_ref": 
"https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e";, 
"creator_id": "cedd848a8a9e410196793c601c03b99a", "meta": {"name": 
"secretname2", "algorithm": "aes", "payload_content_type": "text/plain", 
"mode": "cbc", "bit_length": 256, "expiration": null}, "sub_status_message": 
"Unknown", "type": "key"}[root@barbican-automation ~]#


Retrieval of the secret failing with the content type text/plain

[root@barbican-automation ~]# curl -H 'Accept:text/plain' -H 
"X-Auth-Token:9b211b06669249bb89665df068828ee8" -k 
https://169.53.235.102:9311/v1/secrets/5c25525d-a162-4b0b-9954-90c4ce426c4e/payload
{"code": 500, "description": "Secret payload retrieval failure seen - please 
contact site administrator.", "title": "Internal Server Error"}

I would like to know wheather this is a bug from Barbican side  since Barbican 
allows creation of the order resource with text/plain as the payload_content 
type but the retrieval of the secret payload with the content type text/plain 
is not allowed.

Any help would highly be appreciated.
--
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

Re: [openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

[John Wood]

.@gmail.com>> wrote:
To clarify: we already have to include the groups produced as a result of 
federation mapping **in the payload** of Fernet tokens so that scoped tokens 
can be created later:

  
https://github.com/openstack/keystone/blob/a637ebcbc4a92687d3e80a50cbe88df3b13c79e6/keystone/token/providers/fernet/token_formatters.py#L523

These are OpenStack group IDs, so it's up to the deployer to keep those under 
control to keep Fernet token sizes down. It's the only place in the current 
Fernet implementation that's (somewhat alarmingly) unbounded in the real world.

But we do **not** have a use case to add groups to *all* Fernet payloads: only 
to token creation & validation responses.


On Thu, Jun 4, 2015 at 2:36 AM, Morgan Fainberg 
mailto:morgan.fainb...@gmail.com>> wrote:
For Fernet, the groups would only be populated on validate as Dolph outlined. 
They would not be added to the core payload. We do not want to expand the 
payload in this manner.

--Morgan

Sent via mobile

On Jun 3, 2015, at 21:51, Lance Bragstad 
mailto:lbrags...@gmail.com>> wrote:

I feel if we allowed group ids to be an attribute of the Fernet's core payload, 
we continue to open up the possibility for tokens to be greater than the 
initial "acceptable" size limit for a Fernet token (which I believe was 255 
bytes?). With this, I think we need to provide guidance on the number of group 
ids allowed within the token before that size limit is compromised.

We've landed patches recently that allow for id strings to be included in the 
Fernet payload [0], regardless of being uuid format (which can be converted to 
bytes before packing to save space, this is harder for us to do with non-uuid 
format id strings). This can also cause the Fernet token size to grow. If we 
plan to include more information in the Fernet token payload I think we should 
determine if the original acceptable size limit still applies and regardless of 
what that size limit is provide some sort of "best practices" for helping 
deployments keep their token size as small as possible.


Keeping the tokens user (and developer) friendly was a big plus in the design 
of Fernet, and providing resource for deployments to maintain that would be 
helpful.


[0] 
https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:bug/1459382,n,z

On Wed, Jun 3, 2015 at 10:19 PM, Steve Martinelli 
mailto:steve...@ca.ibm.com>> wrote:
Dozens to hundreds of roles or endpoints could cause an issue now :)

But yeah, groups are much more likely to number in the dozens than roles or 
endpoints. But I think the Fernet token size is so small that it could probably 
handle this (since it does so now for the federated workflow).

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:"Fox, Kevin M" mailto:kevin@pnnl.gov>>
To:"OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date:06/03/2015 11:14 PM
Subject:Re: [openstack-dev] [keystone][barbican] Regarding
exposingX-Group- in token validation




Will dozens to a hundred groups or so on one user cause issues? :)

Thanks,
Kevin


From: Morgan Fainberg
Sent: Wednesday, June 03, 2015 7:23:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][barbican] Regarding exposing 
X-Group- in token validation

In general I am of the opinion with the move to Fernet there is no good reason 
we should avoid adding the group information into the token.

--Morgan

Sent via mobile

On Jun 3, 2015, at 18:44, Dolph Mathews 
mailto:dolph.math...@gmail.com>> wrote:


On Wed, Jun 3, 2015 at 5:58 PM, John Wood 
mailto:john.w...@rackspace.com>> wrote:
Hello folks,

There has been discussion about adding user group support to the per-secret 
access control list (ACL) feature in Barbican. Hence secrets could be marked as 
accessible by a group on the ACL rather than an individual user as implemented 
now.

Our understanding is that Keystone does not pass along a user’s group 
information during token validation however (such as in the form of 
X-Group-Ids/X-Group-Names headers passed along via Keystone middleware).

The pre-requisite for including that information in the form of headers would 
be adding group information to the token validation response. In the case of 
UUID, it would be pre-computed and stored in the DB at token creation time. In 
the case of PKI, it would be encoded into the PKI token and further bloat PKI 
tokens. And in the case of Fernet, it would be included at token validation 
time.

Including group information, however, would also let us efficient revoke tokens 
using token revocation events when group membership is affected in any way 
(user being removed f

[openstack-dev] [keystone][barbican] Regarding exposing X-Group-xxxx in token validation

[John Wood]

Hello folks,

There has been discussion about adding user group support to the per-secret 
access control list (ACL) feature in Barbican. Hence secrets could be marked as 
accessible by a group on the ACL rather than an individual user as implemented 
now.

Our understanding is that Keystone does not pass along a user's group 
information during token validation however (such as in the form of 
X-Group-Ids/X-Group-Names headers passed along via Keystone middleware).

Would the community consider this a useful feature? Would the community 
consider adding this support to Liberty?

Thank you,
John

__
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

[John Wood]

?+1


From: Chad Lung 
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-winfree&release=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

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

[John Wood]

+1

From: Douglas Mendizábal 
Sent: Tuesday, May 19, 2015 7:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for barbican-core

-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

__
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 : Dependency of pyenv configuration in Barbican.sh script

[John Wood]

Hello Asha,

The barbican.sh script was originally intended to be a convenient way to boot 
up a Barbican instance locally to quickly start evaluating its API and 
functionality.

It was not intended to be used as a production script, deferring instead to 
deployments utilizing packages such as RDO RPMs and so forth for that purpose.

That said, changes to that script have been discussed, including removing pyenv 
and uWSGI as dependencies, hence such changes would be good to consider.

I'd also note that a solution based on this recently added script [1] might be 
in order.

Thanks,
John

[1] https://github.com/openstack/barbican/blob/master/bin/barbican-api


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Wednesday, April 22, 2015 at 4:57 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
Paul Kehrer mailto:paul.keh...@rackspace.com>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>, Alexis 
Lee mailto:alex...@hp.com>>, 
"nut...@gmail.com<mailto:nut...@gmail.com>" 
mailto:nut...@gmail.com>>
Subject: Barbican : Dependency of pyenv configuration in Barbican.sh script

Hi All,

I would like to know the reason behind the dependency of the pyenv virtual 
environment and pyenv in the barbican.sh script.
Ideally in the production environment  , barbican would run on standalone 
virtual box with a particular python version .I feel that their dependecies 
needs to be removed from the script.

Was able to stand up the barbican instance without configuring pyenv and 
pyenv-virtualenv dependencies  by modifying the barbican script , installing 
few additional packages and exporting the python path to PATH variable
Please find the change in barbican.sh script for installation and starting of 
the script below :

VENV_DIR=${VIRTUAL_ENV:-`pyenv prefix`} -> This line needs to be removed
uwsgi --master --emperor $CONFIG_DIR/vassals -H  $VENV_DIR -> The  $VENV_DIR 
variable need to be removed as an argument and -H as an option.

The barbican script has been tied to $VENV_DIR variable which is dependent on 
the pyenv  for python configuration.Hence the barbican.sh  script needs to be  
modified to remove $VENV_DIR variable  by configuring python path in PATH 
variable.
On doing this , we can avoid the sourcing the pyenv and pyenv-virtualenv 
packages  and its dependices on Barbican script.

Any help would be highly appreciated and also would like to know opinion from 
the openstack group  on the changes indicated
Thanks in advance


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

Re: [openstack-dev] Barbican : What is the difference between secret and order resource

[John Wood]

Hello Asha,

So the last step you have is retrieving a decrypted secret from Barbican. 
Barbican indeed stores the secret internally encrypted using an internal KEK. 
When it is retrieved however, it is first decrypted by Barbican and then 
returned the client decrypted.

Beyond TLS to protect this information back to the client, there is also a 
transport key feature that has not yet been fully supported via the client 
library, that allows the client to select a session key that can be used to 
encrypt the secret between the client and Barbican.

Thanks,
John


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Friday, April 17, 2015 at 1:02 PM
To: John Wood mailto:john.w...@rackspace.com>>
Cc: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
Paul Kehrer mailto:paul.keh...@rackspace.com>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>, Alexis 
Lee mailto:alex...@hp.com>>
Subject: Re: Barbican : What is the difference between secret and order resource

Hi All,

 I would like to know if the keys generated  by Barbican through the order 
resource are  encrypted using KEKS and then stored in the secret object or is 
it stored in unencypted format.

Any help  would be highly appreciated.

root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345' 
http ://localhost:9311/v1/orders

Please find the command and response below :

{"total": 3, "orders": [{"status": "ACTIVE", "secret_ref": 
"http://localhost:9311/v1/secrets/b3709da7-4691-40d6-af9a-1ae23772a7b2";, 
"updated": "2015-03-13T22:27:48.866683", "meta": {"name": "secretname2", 
"algorithm": "aes", "payload_content_type": "application/octet-stream", "mode": 
"cbc", "bit_length": 256, "expiration": null}, "created": 
"2015-03-13T22:27:48.844860", "type": "key", "order_ref": 
"http://localhost:9311/v1/orders/5a4844ca-47a9-4bd7-ae56-fb84655f48d9"},

root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345' 
http://localhost:9311/v1/secrets/b3709da7-4691-40d6-af9a-1ae23772a7b2
{"status": "ACTIVE", "secret_type": "opaque", "updated": 
"2015-03-13T22:27:48.863403", "name": "secretname2", "algorithm": "aes", 
"created": "2015-03-13T22:27:48.860600", "secret_ref": 
"http://localhost:9311/v1/secrets/b3709da7-4691-40d6-af9a-1ae23772a7b2";, 
"content_types": {"default": "application/octet-stream"}, "expiration": null, 
"bit_length": 256, "mode": "cbc"}


root@barbican:~#  curl -H 'Accept:application/octet-stream' -H 
'X-Project-Id:12345' 
http://localhost:9311/v1/secrets/b3709da7-4691-40d6-af9a-1ae23772a7b2
▒▒R▒v▒▒▒W▒4▒A?Md▒L[▒K4A▒▒bx▒▒▒   - > would like to know if this response is 
encyprted by barbican using KEKS or it is unencypted format whose content type 
is application/octet-stream


Thanks and Regards,
Asha Seshagiri

On Fri, Apr 17, 2015 at 11:30 AM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Thanks a lot  John for your response.

I also thank everyone who has been responding to my queries if I have missed 
someone .
There was  some problem while configuring my email .I do not receive the email 
response directly  from openstack Dev group.I would check the archive folder 
for that.
I will have a look into it

Once again , it's  nice working and collaborating with the openstack Dev -group.

Thanks and Regards,
Asha Seshagiri











jh



Thanks and Regards,
Asha Seshagiri

On Thu, Apr 16, 2015 at 8:10 AM, John Wood 
mailto:john.w...@rackspace.com>> wrote:
Hello Asha,

The /v1/secrets resource is used to upload, encrypt and store your secrets, and 
to decrypt and retrieve those secrets. Key encryption keys (KEKs) internal to 
Barbican are used to encrypt the secret.

The /v1/orders resource is used when you want Barbican to generate secrets for 
you. When they are done they give you references to where the secrets are 
stored so you can retrieve them via the secrets resource above.

Hope that helps!

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Thursday, April 16, 2015 at 1:23 AM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 

Re: [openstack-dev] Barbican : What is the difference between secret and order resource

[John Wood]

Hello Asha,

The /v1/secrets resource is used to upload, encrypt and store your secrets, and 
to decrypt and retrieve those secrets. Key encryption keys (KEKs) internal to 
Barbican are used to encrypt the secret.

The /v1/orders resource is used when you want Barbican to generate secrets for 
you. When they are done they give you references to where the secrets are 
stored so you can retrieve them via the secrets resource above.

Hope that helps!

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Thursday, April 16, 2015 at 1:23 AM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
Paul Kehrer mailto:paul.keh...@rackspace.com>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>, Alexis 
Lee mailto:alex...@hp.com>>
Subject: Barbican : What is the difference between secret and order resource

Hi All ,

What is the difference between secret and the order resource ?
Where is the key stored that is used for encrypting the payload in the secret 
resource and how do we access it.

According to my understanding ,

Storing/Posting  the secret  means  we are encrypting the actual 
information(payload)  using the key generated internally by the barbican based 
on the type mentioned in the secret type.
Geting the secret means we are decryprting the information and geting the 
actual information.

Posting the order refers to the generation of the actual keys by the barbican  
and encyrpting those keys based on the algorithm and the internal key generated 
by barbican.
This encrypted key is referred through the secret reference and the whole meta 
data is referred through a order reference.

Please correct me if I am wrong.
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

Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

[John Wood]

Hello Christopher,

I’m glad you are making progress. I’m including two folks that worked on the 
KMIP plugin to see if they can help with your error diagnosis.

Thanks,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, April 14, 2015 at 10:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin


Hey John.
Thanks!
You were right. It was reading the config from the /root directory because I 
switched to the root user.
After switching back to the normal user it is reading the correct config file 
again.
It is trying to use the kmip plugin now.

However, I cannot not make a request to the kmip plugin because of an ssl error:

2015-04-14 10:02:26,219 - barbican.plugin.kmip_secret_store - ERROR - Error 
opening or writing to client
Traceback (most recent call last):
  File "/home/swift/barbican/barbican/plugin/kmip_secret_store.py", line 167, 
in generate_symmetric_key
self.client.open()
  File 
"/home/swift/.pyenv/versions/barbican27/lib/python2.7/site-packages/kmip/services/kmip_client.py",
 line 86, in open
self.socket.connect((self.host, self.port))
  File "/home/swift/.pyenv/versions/2.7.6/lib/python2.7/ssl.py", line 333, in 
connect
self._real_connect(addr, False)
  File "/home/swift/.pyenv/versions/2.7.6/lib/python2.7/ssl.py", line 314, in 
_real_connect
self.ca_certs, self.ciphers)
SSLError: [Errno 0] _ssl.c:343: error::lib(0):func(0):reason(0)

I believe there is a problem in the KMIP plugin part of the barbican-api.conf 
file:
keyfile = '/path/to/certs/cert.key'
certfile = '/path/to/certs/cert.crt'
ca_certs = '/path/to/certs/LocalCA.crt'

What exactly is each variable suppose to contain?
I have keyfile and certfile being a self signed certificate and 2048 bit RSA 
key respectively for barbican to use and
ca_certs is the kmip_plugins' certificate for barbican to trust. Does this 
setup sound right?

Regards,
Christopher Solis

[Inactive hide details for John Wood ---04/10/2015 07:24:59 PM---Hello 
Christopher, It does seem that configs are being read for]John Wood 
---04/10/2015 07:24:59 PM---Hello Christopher, It does seem that configs are 
being read for another location. Try to remove that

From: John Wood mailto:john.w...@rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: 04/10/2015 07:24 PM
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin





Hello Christopher,

It does seem that configs are being read for another location. Try to remove 
that copy in you home directory (so just keep the /etc location). If you see 
the same issue, try to rename your /etc/barbican/barbican-api.conf file to 
something else. Barbican should crash, probably with a No SQL connection error.

Also, double check the ‘kmip_plugin’ setting in setup.cfg as per below, and try 
running ‘pip install -e .’ again in your virtual environment.

FWIW, this CR adds better logging of plugin errors once the loading problem you 
have is figured out: https://review.openstack.org/#/c/171868/

Thanks,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, April 9, 2015 at 1:55 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

Hey John.
Thanks for letting me know about the error. But I think my configuration is not 
seeing the kmip_plugin selection.
In my barbican-api.conf file in /etc/barbican I have set 
enabled_secretstore_plugins = kmip_plugin

However, I don't think it is creating a KMIPSecretStore instance.
I edited the code in kmip_secret_store.py and put a breakpoint at the very 
beginning of the init function.
When I make a barbican request to put a secret in there, it did not stop at the 
breakpoint at all.
I put another breakpoint in the store_crypto.py file inside the init function 
for the StoreCryptoAdapterPlugin and I
was able to enter the code at that breakpoint.

So even though in my barbican-api.conf file I specified kmip_plugin it seems to 
be using the store_crypto plugin instead.

Is there something that might cause this to happen?
I also want to note that my code has the most up to date pull from the 
community code.

Here's what my /etc/barbican/barbican-api.conf file has in it:

# = Secret Store Plugin ===
[s

Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

[John Wood]

Hello Christopher,

It does seem that configs are being read for another location. Try to remove 
that copy in you home directory (so just keep the /etc location). If you see 
the same issue, try to rename your /etc/barbican/barbican-api.conf file to 
something else. Barbican should crash, probably with a No SQL connection error.

Also, double check the ‘kmip_plugin’ setting in setup.cfg as per below, and try 
running ‘pip install -e .’ again in your virtual environment.

FWIW, this CR adds better logging of plugin errors once the loading problem you 
have is figured out: https://review.openstack.org/#/c/171868/

Thanks,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, April 9, 2015 at 1:55 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin


Hey John.
Thanks for letting me know about the error. But I think my configuration is not 
seeing the kmip_plugin selection.
In my barbican-api.conf file in /etc/barbican I have set 
enabled_secretstore_plugins = kmip_plugin

However, I don't think it is creating a KMIPSecretStore instance.
I edited the code in kmip_secret_store.py and put a breakpoint at the very 
beginning of the init function.
When I make a barbican request to put a secret in there, it did not stop at the 
breakpoint at all.
I put another breakpoint in the store_crypto.py file inside the init function 
for the StoreCryptoAdapterPlugin and I
was able to enter the code at that breakpoint.

So even though in my barbican-api.conf file I specified kmip_plugin it seems to 
be using the store_crypto plugin instead.

Is there something that might cause this to happen?
I also want to note that my code has the most up to date pull from the 
community code.

Here's what my /etc/barbican/barbican-api.conf file has in it:

# = Secret Store Plugin ===
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = kmip_plugin
...
...
...
# == KMIP plugin =
[kmip_plugin]
username = '**'
password = '**'
host = 10.0.2.15
port = 5696
keyfile = '/etc/barbican/rootCA.key'
certfile = '/etc/barbican/rootCA.pem'
ca_certs = '/etc/barbican/rootCA.pem'


Regards,
Christopher Solis


[Inactive hide details for John Wood ---04/08/2015 03:16:58 PM---Hello 
Christopher, My local configuration is indeed seeing the]John Wood 
---04/08/2015 03:16:58 PM---Hello Christopher, My local configuration is indeed 
seeing the kmip_plugin selection, but when steve

From: John Wood mailto:john.w...@rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: 04/08/2015 03:16 PM
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin





Hello Christopher,

My local configuration is indeed seeing the kmip_plugin selection, but when 
stevedore tries to load the KMIP plugin it crashes because required files are 
missing in my local environment (see 
https://github.com/openstack/barbican/blob/master/barbican/plugin/kmip_secret_store.py#L131)
 for example.

Stevedore logs the exception but then doesn’t load this module, so when 
Barbican asks for an available plugin it doesn’t see it and crashes as you see. 
So the root exception from stevedore isn’t showing up in my logs for some 
reason, and probably not in yours as well. We’ll try to put up a CR to at least 
expose this exception in logs. In the mean time, make sure the KMIP values 
checked via that link above are configured on your machine.

Sorry for the inconvenience,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 11:27 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

Hey John.
I do have the barbican-api.conf file located in the /etc/barbican folder. But 
that does not seem to be the one that barbican
reads from. It seems to be reading from the barbican-api.conf file locate in my 
home directory.
Either way, both have the exact same configurations.

I also checked the setup.cfg file and it does have the line for kmip_plugin .

Regards,

 CHRIS SOLIS

[Inactive hide details for John Wood ---04/07/2015 10:39:18 AM---Hello 
Christopher, Just checking, but is that barbican-api.conf]John Wood 
---04/07/2015 10:39:18 AM---Hello Christopher, Just checking, but is that 
ba

Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

[John Wood]

Hello Christopher,

My local configuration is indeed seeing the kmip_plugin selection, but when 
stevedore tries to load the KMIP plugin it crashes because required files are 
missing in my local environment (see 
https://github.com/openstack/barbican/blob/master/barbican/plugin/kmip_secret_store.py#L131)
 for example.

Stevedore logs the exception but then doesn't load this module, so when 
Barbican asks for an available plugin it doesn't see it and crashes as you see. 
So the root exception from stevedore isn't showing up in my logs for some 
reason, and probably not in yours as well. We'll try to put up a CR to at least 
expose this exception in logs. In the mean time, make sure the KMIP values 
checked via that link above are configured on your machine.

Sorry for the inconvenience,
John


From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, April 8, 2015 at 11:27 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin


Hey John.
I do have the barbican-api.conf file located in the /etc/barbican folder. But 
that does not seem to be the one that barbican
reads from. It seems to be reading from the barbican-api.conf file locate in my 
home directory.
Either way, both have the exact same configurations.

I also checked the setup.cfg file and it does have the line for kmip_plugin .

Regards,

  CHRIS SOLIS

[Inactive hide details for John Wood ---04/07/2015 10:39:18 AM---Hello 
Christopher, Just checking, but is that barbican-api.conf]John Wood 
---04/07/2015 10:39:18 AM---Hello Christopher, Just checking, but is that 
barbican-api.conf file located in your local system's

From: John Wood mailto:john.w...@rackspace.com>>
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>
Date: 04/07/2015 10:39 AM
Subject: Re: [openstack-dev] [barbican] Utilizing the KMIP plugin





Hello Christopher,

Just checking, but is that barbican-api.conf file located in your local 
system's /etc/barbican folder? If not that is the preferred place for local 
development. Modifying the copy that is in your local git repository will have 
no effect.

Also, please double check that your local git repository's setup.cfg has a line 
like this in there (at/around #35):

kmip_plugin = barbican.plugin.kmip_secret_store:KMIPSecretStore

Thanks,
John




From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 6, 2015 at 10:25 AM
To: 
"openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin

Hello!

Sorry to Kaitlin Farr for not responding directly to your e-mail.
My openstack settings were misconfigured and I was not receiving e-mail from 
the dev mailing list.
Thanks for looking into the issue.

I double checked the permissions at the bottom of the kmip_plugin part in the 
barbican-api.conf file
and they are set to 400.

I would also like to note that I do not think the code ever actually entered 
the __init__ function
of KMIPSecretStore. I put a breakpoint in the __init__ function but the 
debugger never gets open.
The error occurs and returns without ever seeming to enter the init function.

Here are the parts of the barbican-api.conf file that concern the kmip_plugin:
.
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = kmip_plugin
.
[kmip_plugin]
username = '**'
password = '**'
host = 
port = 
keyfile = '/etc/barbican/rootCA.key'
certfile = '/etc/barbican/rootCA.pem'
ca_certs = '/etc/barbican/rootCA.pem'
...

Thank You!!

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

Re: [openstack-dev] Barbican : Unable to authenticate with keystone V3 for Barbican curl command

[John Wood]

Hello Asha,

Please following the steps in the pending CR [1]. That configures v3 usage with 
Keystone, and if you use the Docker Keystone instance mentioned, it syncs the 
passwords with it as well. Note the need to execute the setup script noted to 
configure Keystone properly as well.

Thanks,
John

[1] https://review.openstack.org/#/c/169114/2/doc/source/setup/keystone.rst

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Tuesday, April 7, 2015 at 2:49 PM
To: John Wood mailto:john.w...@rackspace.com>>
Cc: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"a...@redhat.com<mailto:a...@redhat.com>" 
mailto:a...@redhat.com>>, Paul Kehrer 
mailto:paul.keh...@rackspace.com>>, Adam Harwell 
mailto:adam.harw...@rackspace.com>>, Alexis Lee 
mailto:alex...@hp.com>>
Subject: Re: Barbican : Unable to authenticate with keystone V3 for Barbican 
curl command

Thanks a lot John for your help and response.

I had followed the same set of instructions as given in the link 1 initially 
changing the version to v3  , it did not work and hence followed with link 2 
and is not working though.

The link 1 provided  below points to keystone v2 changes with barbican  and not 
v3
[1]  http://docs.openstack.org/developer/barbican/setup/keystone.html .
But in this link  2 for Integration keystone V3 with barbican we have to modify 
both the configuriation files
 barbican-api-paste.ini and barbican-admin-paste.ini files . There are some 
changes in the filter and pipline names  names tied with v3


pipeline = keystone_v3_authtoken context apiapp
.
[filter:keystone_v3_authtoken]

[2] https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API

Could you please confirm that we need to follow the link 1 changing the version 
from v2 to v3 with only modification in barbican-api-paste.ini  file and not 
barbican-admin-paste.ini so that I can start looking into the issue with the 
changes mentioned in link1 alone.

Thanks and Regards,
Asha Seshagiri

On Tue, Apr 7, 2015 at 2:08 PM, John Wood 
mailto:john.w...@rackspace.com>> wrote:
Hello Asha,

We are in the process of migrating our documentation to Sphinx, so I'd suggest 
following this link for Keystone configuration options [1].

I'd also note that a CR is pending with a bit more details to setup via a 
Docker Keystone here [2].

Thanks,
John


[1]  http://docs.openstack.org/developer/barbican/setup/keystone.html
[2]  https://review.openstack.org/#/c/169114/

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Tuesday, April 7, 2015 at 1:34 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"a...@redhat.com<mailto:a...@redhat.com>" 
mailto:a...@redhat.com>>, Paul Kehrer 
mailto:paul.keh...@rackspace.com>>, Adam Harwell 
mailto:adam.harw...@rackspace.com>>, Alexis Lee 
mailto:alex...@hp.com>>
Subject: Barbican : Unable to authenticate with keystone V3 for Barbican curl 
command

Hi All ,

Could anyone please help me on this integration issue.
I am unable to authenticate with keystone V3  for Barbican curl command   .I 
have followed the procedure given in the following link :

https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API

I was unable to authenticate with the keystone V3 even though the right token 
was provided in the curl command
Please find the command to get the token and the curl command to post the 
secret .

[root@keystone-versiontest ~]# openstack --insecure token issue (Command to get 
token from keystone v3)
++--+
| Field  | Value|
++--+
| expires| 2015-04-07T18:26:13.835641Z  |
| id | f28b93f27cce4bc09f9ac50d84bde736 |
| project_id | 9d37f9ecc481422aa8ab53674cb82410 |
| user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
++--+

[root@keystone-versiontest ~]# curl -X POST -H 'content-type:application/json' 
-H 'X-Project-Id:12345' \
> -H "X-Auth-Token:f28b93f27cce4bc09f9ac50d84bde736" -d '{"payload": 
> "my-secret-here", "payload_content_type": "text/plain"}' 
> http://localhost:9311/v1/secrets
Authentication required[root@keystone-versiontest ~]#

The contents of the admin.opensrc file is as given below :

[root@keystone-versiontest ~]# cat admin.openrc
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL=https://169.5

Re: [openstack-dev] Barbican : Unable to authenticate with keystone V3 for Barbican curl command

[John Wood]

Hello Asha,

We are in the process of migrating our documentation to Sphinx, so I'd suggest 
following this link for Keystone configuration options [1].

I'd also note that a CR is pending with a bit more details to setup via a 
Docker Keystone here [2].

Thanks,
John


[1]  http://docs.openstack.org/developer/barbican/setup/keystone.html
[2]  https://review.openstack.org/#/c/169114/

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Tuesday, April 7, 2015 at 1:34 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"a...@redhat.com<mailto:a...@redhat.com>" 
mailto:a...@redhat.com>>, Paul Kehrer 
mailto:paul.keh...@rackspace.com>>, Adam Harwell 
mailto:adam.harw...@rackspace.com>>, Alexis Lee 
mailto:alex...@hp.com>>
Subject: Barbican : Unable to authenticate with keystone V3 for Barbican curl 
command

Hi All ,

Could anyone please help me on this integration issue.
I am unable to authenticate with keystone V3  for Barbican curl command   .I 
have followed the procedure given in the following link :

https://github.com/cloudkeep/barbican/wiki/Integration-with-Keystone-V3-API

I was unable to authenticate with the keystone V3 even though the right token 
was provided in the curl command
Please find the command to get the token and the curl command to post the 
secret .

[root@keystone-versiontest ~]# openstack --insecure token issue (Command to get 
token from keystone v3)
++--+
| Field  | Value|
++--+
| expires| 2015-04-07T18:26:13.835641Z  |
| id | f28b93f27cce4bc09f9ac50d84bde736 |
| project_id | 9d37f9ecc481422aa8ab53674cb82410 |
| user_id| e7d02ed8e7e64b01a1d66bb86ffa90d8 |
++--+

[root@keystone-versiontest ~]# curl -X POST -H 'content-type:application/json' 
-H 'X-Project-Id:12345' \
> -H "X-Auth-Token:f28b93f27cce4bc09f9ac50d84bde736" -d '{"payload": 
> "my-secret-here", "payload_content_type": "text/plain"}' 
> http://localhost:9311/v1/secrets
Authentication required[root@keystone-versiontest ~]#

The contents of the admin.opensrc file is as given below :

[root@keystone-versiontest ~]# cat admin.openrc
export OS_USERNAME=admin
export OS_TENANT_NAME=admin
export OS_PASSWORD=admin
export OS_AUTH_URL=https://169.54.204.69:35357/v3
export OS_REGION_NAME=RegionOne
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_ID=default
export OS_PROJECT_DOMAIN_ID=default


And also I have attached the  barbican-api-paste.ini and 
barbican-admin-paste.ini files.

I would like to know why the curl command for posting the secret is not geting 
authenticated with Keystone V3

Any help would highly be 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

Re: [openstack-dev] Barbican : Unable to reterieve asymmetric order request for rsa algorithm type

[John Wood]

Hello Asha,

The root error here is that the stock plugin does not support generating 256 
bit length asymmetric keys, rather only 1024, 2048 or 4096. Ideally you would 
have received a validation error when you POST-ed the order, but we have not 
yet integrated plugins with our validation process.

FYI, this link [1] shows the method that guides which algorithm parameters are 
supported by the default plugin.

Thanks for you patience,
John

[1]  
https://github.com/openstack/barbican/blob/master/barbican/plugin/crypto/simple_crypto.py#L194



From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Tuesday, April 7, 2015 at 12:23 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>, 
Paul Kehrer mailto:paul.keh...@rackspace.com>>, Adam 
Harwell mailto:adam.harw...@rackspace.com>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"a...@redhat.com<mailto:a...@redhat.com>" 
mailto:a...@redhat.com>>, Alexis Lee 
mailto:alex...@hp.com>>
Subject: Re: Barbican : Unable to reterieve asymmetric order request for rsa 
algorithm type

Hi All ,

I would like someone to provide the pointer so that I would look into this 
issue and confirm whether asymmetric order retrieval would be supported in 
Barbican.

Any help would be appreciated!

Thanks in advance,
Asha Seshagiri

On Fri, Apr 3, 2015 at 11:06 AM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All ,

Could any one please let me know if Barbican would support asymmetric order 
retrieval and the request .
Please find the curl command and response for creating the order and retrieving 
 the order

root@barbican:~# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id: 12345' -d '{"type" : "asymmetric", "meta": {"name": 
"secretnamepk2", "algorithm": "rsa", "bit_length": 256, "mode": "cbc", 
"payload_content_type": 
"application/octet-stream"}}'http://localhost:9311/v1/orders
{"order_ref": 
"http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c"}root@barbican:~#

root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345' 
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{"status": "ERROR", "updated": "2015-03-30T21:36:38.102832", "created": 
"2015-03-30T21:36:38.083428", "order_ref": 
"http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c";, "meta": 
{"name": "secretnamepk2", "algorithm": "rsa", "payload_content_type": 
"application/octet-stream", "mode": "cbc", "bit_length": 256, "expiration": 
null}, "error_status_code": "400", "error_reason": "Process TypeOrder issue 
seen - No plugin was found that could support your request.", "type": 
"asymmetric"}root@barbican:~#

It seems that we are unable to reterive the asymmetric order request
Could any one please help.
Any Help would be appreciated.

Thanks in Advance

On Mon, Mar 30, 2015 at 4:42 PM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All ,

I would like to know whether Barbican supports asymmetric order request .
Please find the curl command and response for creating the order and retrieving 
 the order

root@barbican:~# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id: 12345' -d '{"type" : "asymmetric", "meta": {"name": 
"secretnamepk2", "algorithm": "rsa", "bit_length": 256, "mode": "cbc", 
"payload_content_type": "application/octet-stream"}}' 
http://localhost:9311/v1/orders
{"order_ref": 
"http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c"}root@barbican:~#

root@barbican:~# curl -H 'Accept: application/json' -H 'X-Project-Id:12345' 
http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c
{"status": "ERROR", "updated": "2015-03-30T21:36:38.102832", "created": 
"2015-03-30T21:36:38.083428", "order_ref": 
"http://localhost:9311/v1/orders/f9870bb5-4ba3-4b19-9fe3-bb0c2a53557c";, "meta": 
{"name": "secretnamepk2", "algorithm": "rsa", "payload_content_type": 
"application/octet-stream", "mode": "cbc", "bit_length": 256, "expiration": 
null}, "error_status_code": "400", "error_reason": "Process TypeOrder issue 
seen - No plugin was found that could support your request.", "type": 
"asymmetric"}root@barbican:~#

Could any one please help.
Thanks in Advance
--
Thanks and Regards,
Asha Seshagiri



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

Re: [openstack-dev] [barbican] Utilizing the KMIP plugin

[John Wood]

Hello Christopher,

Just checking, but is that barbican-api.conf file located in your local 
system's /etc/barbican folder? If not that is the preferred place for local 
development. Modifying the copy that is in your local git repository will have 
no effect.

Also, please double check that your local git repository's setup.cfg has a line 
like this in there (at/around #35):

kmip_plugin = barbican.plugin.kmip_secret_store:KMIPSecretStore

Thanks,
John




From: Christopher N Solis mailto:cnso...@us.ibm.com>>
Reply-To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, April 6, 2015 at 10:25 AM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [barbican] Utilizing the KMIP plugin


Hello!

Sorry to Kaitlin Farr for not responding directly to your e-mail.
My openstack settings were misconfigured and I was not receiving e-mail from 
the dev mailing list.
Thanks for looking into the issue.

I double checked the permissions at the bottom of the kmip_plugin part in the 
barbican-api.conf file
and they are set to 400.

I would also like to note that I do not think the code ever actually entered 
the __init__ function
of KMIPSecretStore. I put a breakpoint in the __init__ function but the 
debugger never gets open.
The error occurs and returns without ever seeming to enter the init function.

Here are the parts of the barbican-api.conf file that concern the kmip_plugin:
.
[secretstore]
namespace = barbican.secretstore.plugin
enabled_secretstore_plugins = kmip_plugin
.
[kmip_plugin]
username = '**'
password = '**'
host = 
port = 
keyfile = '/etc/barbican/rootCA.key'
certfile = '/etc/barbican/rootCA.pem'
ca_certs = '/etc/barbican/rootCA.pem'
...

Thank You!!

Regards,
Christopher Solis
__
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 : Use of consumer resource

[John Wood]

(Including Adam, who implemented this feature last year to make sure I'm not 
misspeaking here :)

Hello Asha,

The consumers feature allows clients/services to register 'interest' in a given 
secret or container. The URL provided is unrestricted. Clients that wish to 
delete a secret or consumer may add logic to hold off deleting if other 
services have registered their interest in the resource. However for Barbican 
this data is only informational, with no business logic (such as rejecting 
delete attempts) associated with it.

I hope that helps.

Thanks,
John


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Monday, March 30, 2015 at 5:04 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
"Reller, Nathan S." 
mailto:nathan.rel...@jhuapl.edu>>, Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"a...@redhat.com<mailto:a...@redhat.com>" 
mailto:a...@redhat.com>>, Paul Kehrer 
mailto:paul.keh...@rackspace.com>>
Subject: Re: Barbican : Use of consumer resource

Including Alee and Paul in the loop

Refining the above question :

The consumer resource allows the clients to register with container resources. 
Please find the command and response below


POST v1/containers/888b29a4-c7cf-49d0-bfdf-bd9e6f26d718/consumers

Header: content-type=application/json
X-Project-Id: {project_id}
{
"name": "foo-service",
"URL": "https://www.fooservice.com/widgets/1234";
}

I would like to know the following :

1. Who  does the client here refers to ? Openstack Services or any other 
services as well?

2. Once the client gets registered through the consumer resource , How does 
client consume or use the consumer resource

Any Help would be appreciated.

Thanks Asha.




On Mon, Mar 30, 2015 at 12:05 AM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All,

Once the consumer resource registers to the containers , how does the consumer 
resource consume the container resource?
Is there any API supporting the above operation.

Could any one please help on this?

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

Re: [openstack-dev] Barbican : Unable to install Barbican on CentOS due to Import Error

[John Wood]

Hello Asha,

It seems like your installer script might be crashing for some reason. You 
might need to execute the steps in the installer script manually to stand 
things up, such as the pip install step here: 
https://github.com/openstack/barbican/blob/master/bin/barbican.sh#L87

Please let us know if that helps.

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Date: Wednesday, March 25, 2015 at 2:24 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Cc: John Wood mailto:john.w...@rackspace.com>>, 
Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>, 
"Reller, Nathan S." mailto:nathan.rel...@jhuapl.edu>>
Subject: Barbican : Unable to install Barbican on CentOS due to Import Error

Hi  ,

When I tried installing barbican using the command  bin/barbican.sh install , I 
got the following error  :

ImportError: No module named pecan
Traceback (most recent call last):
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 272, in loadobj
return context.create()
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 710, in create
return self.object_type.invoke(self)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 144, in invoke
**context.local_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/util.py",
 line 55, in fix_call
val = callable(*args, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/urlmap.py", 
line 25, in urlmap_factory
app = loader.get_app(app_name, global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 350, in get_app
name=name, global_conf=global_conf).create()
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 362, in app_context
APP, name=name, global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 450, in get_context
global_additions=global_additions)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 559, in _pipeline_app_context
APP, pipeline[-1], global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 458, in get_context
section)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 517, in _context_from_explicit
value = import_string(found_expr)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 22, in import_string
return pkg_resources.EntryPoint.parse("x=" + s).load(False)
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2320, in 
load
  File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2326, in 
resolve
  File "/root/barbican/barbican/api/__init__.py", line 22, in 
import pecan
ImportError: No module named pecan
OOPS ! failed loading app in worker 1 (pid 27606) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
OOPS ! failed loading app in worker 1 (pid 27607) :( trying again...
worker respawning too fast !!! i have to sleep a bit (2 seconds)...
Respawned uWSGI worker 1 (new pid: 27608)
Respawned uWSGI worker 1 (new pid: 27609)
Loading paste environment: config:/etc/barbican/barbican-api-paste.ini
Loading paste environment: config:/etc/barbican/barbican-admin-paste.ini
Traceback (most recent call last):
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 247, in loadapp
return loadobj(APP, uri, name=name, **kw)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 271, in loadobj
global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 296, in loadcontext
global_conf=global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 320, in _loadconfig
return loader.get_context(object_type, name, global_conf)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/paste/deploy/loadwsgi.py",
 line 450, in get_context
global_additions=global_additions)
  File 
"/root/.pyenv/versions/barbican27/lib/python2.7/site-packages/

Re: [openstack-dev] [barbican] Barbican : Unable to send PUT request to store the secret

[John Wood]

Hello Asha,

I missed this later email, sorry.

The content type on the PUT call determines the type of the secret (the first 
POST call only creates the metadata for the secret).

This older wiki page might help clarify things: 
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#two-step-binary-secret-createretrieve

Thanks,
John

From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Reply-To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, March 20, 2015 at 3:04 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] Barbican : Unable to send PUT request to store the 
secret

Hi All ,

Now the command for put request  has been successful .the content type for the 
header needs to be text/plain.
I thought that the  datatype for the data parameters would determine the 
content type of the header.

For ex : In this case the data is passed in the following format   '{"secret": 
{"payload": "secretput", "payload_content_type": "text/plain }}' which is the 
JSON type .

curl -X PUT -H 'content-type:text/plain' -H 'X-Project-Id: 12345' -d 
'{"secret": {"payload": "secretput", "payload_content_type": "text/plain }}' 
http://localhost:9311/v1/secrets/89d424c3-f4c1-4822-8bd7-7691f40f7ba3

Could anyone provide the clarity on content type of the header

Thanks and Regards,
Asha Seshagiri

On Fri, Mar 20, 2015 at 2:05 PM, Asha Seshagiri 
mailto:asha.seshag...@gmail.com>> wrote:
Hi All ,

I am unable to send the PUT request using the CURL command for storing the 
secret .


root@barbican:~# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id: 12345' -d '{"secret": {"name": "secretname", "algorithm": "aes", 
"bit_length"  : 256, "mode": "cbc"}}' 
http://localhost:9311/v1/secrets
{"secret_ref": 
"http://localhost:9311/v1/secrets/84aaac35-daa9-4ffb-b03e-18596729705d"}

curl -X PUT -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d 
'{"secret": {"payload": "secretput", "payload_content_type": "text/plain" }}' 
http://localhost:9311/v1/secrets
{"code": 405, "description": "", "title": "Method Not Allowed"}

It would be great if some one could help me .
Thanks in advance.

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

Re: [openstack-dev] [barbican] Barbican : Unable to send PUT request to store the secret

[John Wood]

Hello Asha,

First, please add '[barbican]' to the subject line to indicate this thread is 
of Barbican interest only. So for example, the revised subject line would look 
like:
Re: [openstack-dev] [barbican] Unable to send PUT request to store the secret

You appear to be doing a two step secret upload, in which case the second step 
(the PUT) needs the full URI to the secret...the URI in your PUT call is 
missing the UUID in other words.

This demo script may help you as well: 
https://github.com/openstack/barbican/blob/master/bin/demo_requests.py#L85

Thanks,
John


From: Asha Seshagiri mailto:asha.seshag...@gmail.com>>
Reply-To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, March 20, 2015 at 2:05 PM
To: openstack-dev 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] Barbican : Unable to send PUT request to store the 
secret

Hi All ,

I am unable to send the PUT request using the CURL command for storing the 
secret .


root@barbican:~# curl -X POST -H 'content-type:application/json' -H 
'X-Project-Id: 12345' -d '{"secret": {"name": "secretname", "algorithm": "aes", 
"bit_length"  : 256, "mode": "cbc"}}' 
http://localhost:9311/v1/secrets
{"secret_ref": 
"http://localhost:9311/v1/secrets/84aaac35-daa9-4ffb-b03e-18596729705d"}

curl -X PUT -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d 
'{"secret": {"payload": "secretput", "payload_content_type": "text/plain" }}' 
http://localhost:9311/v1/secrets
{"code": 405, "description": "", "title": "Method Not Allowed"}

It would be great if some one could help me .
Thanks in advance.

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

[openstack-dev] [all] OpenStack options for visually impaired contributors

[John Wood]

Hello folks,

I¹m curious what tools visually impaired OpenStack contributors have found
helpful for performing Gerrit reviews (the UI is difficult to scan,
especially for in-line code comments) and for Python development in
general?

Thanks,
John


__
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][grenade][tempest][qa][ceilometer] Database Upgrade Testing for Incubated Projects

[John Wood]

Hello folks,

(Apologies for the numerous tags, but my question straddles multiple areas I 
believe)

I’m a core developer on the Barbican team and we are interested in database 
upgrade testing via Grenade. In addition to Grenade documentation I’ve looked 
at two blueprints [1][2] the Ceilometer project merged in last year, and the 
CRs created for them. It would appear that in order to utilize Grenade testing 
for Barbican, we would need submit CRs to both Grenade (to add an 
‘update-barbican’ script) and to Tempest (to add Barbican-centric resources to 
the javeline.py module).

As Barbican is not yet out of incubation, would such Grenade and Tempest CRs 
need to wait until we are out of incubation?  If we do have to wait, is anyone 
aware of an alternative method of such upgrade testing without need to submit 
changes to Grenade and Tempest (similar to the DevStack gate hook back to the 
project)?

[1] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/grenade-upgrade-testing.html
[2] 
http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/grenade-resource-survivability.html

Thanks in advance!,
John

__
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 Steve Heyman for barbican-core

[John Wood]

+1

Thanks,
John


From: Nathan Reller [rellerrel...@yahoo.com]
Sent: Thursday, November 06, 2014 3:35 AM
To: Openstack-Dev
Subject: Re: [openstack-dev] [Barbican] Nominating Steve Heyman for 
barbican-core

+1 for me

-Nate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for barbican-core

[John Wood]

+1

Thanks,
John


From: Chad Lung [chad.l...@gmail.com]
Sent: Thursday, November 06, 2014 4:06 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio Robles for 
barbican-core


+1

Chad Lung




Date: Wed, 5 Nov 2014 15:53:02 +
From: Douglas Mendizabal 
mailto:douglas.mendiza...@rackspace.com>>
To: "OpenStack Development Mailing List (not for usage questions)"

mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Barbican] Nominating Juan Antonio Osorio
Robles  for barbican-core
Message-ID: 
mailto:d0800668.369fa%25douglas.mendiza...@rackspace.com>>
Content-Type: text/plain; charset="utf-8"

Hi All,

I would like to nominate Juan Antonio Osorio Robles to the barbican-core
team.

Juan has been consistently giving us very well thought out and constructive
reviews for Barbican, python-barbicanclient and barbican-specs.  It?s
obvious from his reviews that he cares deeply for the quality of the
Barbican project, and I think he will be a great addition to the core team.

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.

References:

http://stackalytics.com/report/contribution/barbican-group/90

Thanks,
Douglas


Douglas Mendiz?bal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack] [Barbican] [Cinder] Cinder and Barbican

[John Wood]

Hello Giuseppe,

There have been blueprints related to this, such as here: 
https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican

I don't think all the necessary pieces for this feature have landed as of yet 
though...cc-ing Joel and Nate in case they wanted to weigh in here.

Thanks,
John



From: Douglas Mendizabal [douglas.mendiza...@rackspace.com]
Sent: Thursday, October 16, 2014 3:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack] [Barbican] [Cinder] Cinder and Barbican

Hi Giuseppe,

Someone from the Cinder team can correct me if I’m wrong, but I don’t think 
that Cinder has done any integration with Barbican yet.

-Douglas


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C

From: Giuseppe Galeota 
mailto:giuseppegale...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, October 16, 2014 at 9:54 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [OpenStack] [Barbican] Cinder and Barbican


Dear all,
is Cinder capable today to use Barbican for encryption? If yes, can you attach 
some useful doc?

Thank you,
Giuseppe
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] RE: Juno Home Stretch

[John Wood]

(kicking this thread to the dev mailing list)

Thanks for starting this discussion on Juno work efforts, Nate.  This would be 
a good discussion to pick up at the 3pm CDT IRC meeting today as well. I've 
added some thoughts below as well.

I believe the plan is to finalize features and API changes in 
openstack/barbican for M3 (so Sept 4th). My understanding is that corresponding 
updates to the client library to accommodate these features could continue 
after that date. 

So getting finalized KMIP, Dogtag and HSM secret storage options shored up 
seems like a good goal. I think the last KMIP CR is Kaitlin's (kfarr) [1]. 
Paul's (reaperhulk) CR [2] fixes an issue with HSM interactions (and stevedore 
interaction in general...we should discuss at the IRC meeting today).

Removing the tenant-ID from the URLs seems good as well, per this Venkat's 
(tsv) CR [3].

Regarding the transport key feature, I would hope that we could get the client 
portion available before the final Juno release.

Adam (rm_work) is working on the Containers portion of the client library in CR 
[4].

Regarding certificate generation...

I'm hopeful we get can get the framework for certificate generation (based on 
blueprint [5]) in place by M3, but that might be aggressive. I'm hopeful the 
feature can include the ability to invoke a certificate plugin to generate a 
certificate via the orders interface for happy path flows (i.e. data is 
correct). This could be Ade's Dogtag plugin, and the Symantec plugin. 

Work to retrieve which certificate plugins are available would probably need to 
be done in K, as well as Ade's sub-CA feature.

Per that blueprint, it would also be nice to have a simple certificate event 
plugin (that just logs, I'm working on that now) and a simple retry loop using 
periodic tasks.

As Ade (alee) pointed out, Arvind's (atiwari) CR to add type/meta to the orders 
resource [6] is needed for follow on asymmetric and certificate generation 
workflows.  Some initial work on asymmetric generation is happening in Arvind's 
CR here: https://review.openstack.org/#/c/111412/


Misc...

I'm thinking Arun's (arunkant) Keystone eventing CR [7], and my (woodster) 
json-home Version resource CR [8] might slip to K, but again we should discuss 
this today.

Ade, I had thought the Dogtag Chef work was getting fleshed out, so it might be 
close now?

I'd like to remove the 'context' argument from the secret_store.py plugin 
interface before M3. 

We might want to consider adding plugin validation to our current hard-coded 
validators.py classes as well?



Is there anything else out there?

Thanks,
John

[1] = https://review.openstack.org/#/c/101582/
[2] = https://review.openstack.org/#/c/114341/
[3] = https://review.openstack.org/#/c/112149/
[4] = https://review.openstack.org/#/c/113393/
[5] = 
https://github.com/openstack/barbican-specs/blob/master/specs/juno/add-ssl-ca-support.rst
[6] = https://review.openstack.org/#/c/87405/
[7] = https://review.openstack.org/#/c/110817/
[8] = https://review.openstack.org/#/c/108163/


From: Ade Lee [a...@redhat.com]
Sent: Friday, August 15, 2014 12:16 PM
To: Reller, Nathan S.
Cc: Jarret Raim; John Wood; Coffman, Joel M.; Farr, Kaitlin M.; 
nkin...@redhat.com; akon...@redhat.com
Subject: Re: Juno Home Stretch

On Fri, 2014-08-15 at 12:12 -0400, Reller, Nathan S. wrote:
> We are getting into the final weeks of Juno development, and I was
> wondering where we stand with status. I want to make sure we get in
> everything that we can, and I want to make sure I prioritize reviews or
> any other help that we can give appropriately.
>
> We have several Dogtag patches that were accepted. Is there anything left
> for the Dogtag secret store?
>

The key wrapping feature is basically completed on the server side.  On
the client side, though, nothing has yet been done.  I suspect that this
will be something that will end up being tackled in K.

Right now, I am focused on several Dogtag patches:
1. Patch to extend Dogtag plugin to issue certificates through the
backend CA.
2. Patch to extend Dogtag plugin to support asymmetric generation.

So, whats missing?  Once Arvind's CR lands, we still need a follow-on CR
to extend the orders API to be able to both generate and issue
certificates.  Central to this is the decision to not attempt to design
a common set of parameters for all CA's, but rather to require the
client to specify vendor specific metadata.  That means that we will
need to provide some kind of identifier that the client will use to
identify the relevant CA.

Note that a particular plugin may support multiple subCA's.  We plan in
the near future to add a feature to Dogtag that would allow the creation
of lightweight subCA's within a dogtag instance.  This would allow, for
instance, projects to issue certificates scoped to that pa

Re: [openstack-dev] [barbican] Etherpad discussion related to ssl certificate workflow CR

[John Wood]

Hello Robert,

In the etherpad, I mention that any of the plugin calls (including the 
initiate_order() one) could result in the certificate being generated. 

As for handling the certificate order synchronously vs asynchronously however, 
we are striving to minimize the amount of 3rd party interaction required on the 
synchronous/API side to improve availability, deferring to the async worker 
processes to handle such traffic. 

So all orders resource requests are handled this way currently. IMHO, handling 
some orders synchronously would seem inconsistent and awkward, but perhaps a 
new resource (like 'quick_orders') could be introduced to handle such requests?

Thanks,
John






From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Thursday, July 17, 2014 5:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: barbi...@lists.rackspace.com List
Subject: Re: [openstack-dev] [barbican] Etherpad discussion related to ssl 
certificate workflow CR

We’ve been looking into CA’s that give you an instant response on a certificate 
signing request (based on various conditions) - I’m not sure that we can easily 
make this work with the state structures described?

Our basic flow is
Client —[https|somecreds|some <https://somecreds|some>csr]--> CA
Client <—[https|certificate/error400]—CA

The CA does a lot of stuff in the backend but for the purposes of this the 
decision about making the cert is instant, there’s no ‘queue’ to wait on. It’s 
not immediately clear to me if there’s some option to shortcut the states laid 
out to make a plugin work nicely with our prototype CA…

Cheers
-Rob

From: John Wood mailto:john.w...@rackspace.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 17 July 2014 15:37
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Cc: "barbi...@lists.rackspace.com<mailto:barbi...@lists.rackspace.com>" 
mailto:barbi...@lists.rackspace.com>>
Subject: [openstack-dev] [barbican] Etherpad discussion related to ssl 
certificate workflow CR

Hello folks,

Ade raised concerns about the approach taken in the SSL cert CR here: 
https://review.openstack.org/#/c/107190/

In short, he suggests that a state machine approach that gives plugins a lot of 
control over workflow is not needed, and could lead to plugin developers having 
more difficulty creating new plugins. I think he has valid points, so I created 
an etherpad that details a 'generic' workflow approach, and an approach that 
simplifies what the plugins need to do (offloading logic to Barbican): 
https://etherpad.openstack.org/p/barbican-order-cert-gen-interactions

Please take a look at the etherpad and weigh in if you can.

Thanks,
John



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Etherpad discussion related to ssl certificate workflow CR

[John Wood]

Hello folks,

Ade raised concerns about the approach taken in the SSL cert CR here: 
https://review.openstack.org/#/c/107190/

In short, he suggests that a state machine approach that gives plugins a lot of 
control over workflow is not needed, and could lead to plugin developers having 
more difficulty creating new plugins. I think he has valid points, so I created 
an etherpad that details a 'generic' workflow approach, and an approach that 
simplifies what the plugins need to do (offloading logic to Barbican): 
https://etherpad.openstack.org/p/barbican-order-cert-gen-interactions

Please take a look at the etherpad and weigh in if you can.

Thanks,
John


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Is there an agreed way for plugins to log output

[John Wood]

Hello Robert,

We don't have logging conventions for plugins, so any recommendations you have 
would be welcome.

Thanks,
John



From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Thursday, July 17, 2014 1:14 PM
To: OpenStack List
Subject: [openstack-dev] [Barbican] Is there an agreed way for plugins to   
log output

As above, couldn’t see any conventions.

Thanks
-Rob


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] RE: Barbican doesn't authenticate with Keystoine for one particular tenant

[John Wood]

Hello Robert,

You should get 400 errors for unauthenticated requests, so it seems barbican 
still isn't running with keystone. Can you reply back with your 
/etc/barbican/barbican-api-paste.ini file (with passwords removed)?

Thanks,
John



From: Robert Marshall -X (robemars - TEKSYSTEMS INC at Cisco) 
[robem...@cisco.com]
Sent: Thursday, July 17, 2014 11:28 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] Barbican doesn't authenticate with Keystoine for one 
particular tenant

We have configure Barbican and Keystone according to the documentation and the 
direction provided by John Wood. We see Barbican authenticating with Keystone. 
The problem we see is that when we use the “service” tenant, we can retrieve 
secrets without authenticating with Keystone, where the “service” tenant is the 
tenant that we associate with the “barbican” service in Keystone:

(barbican27)[root@iac-int-ma15 ~]# curl -XGET -d '{}' -H "Content-type: 
application/json" -H "X_IDENTITY_STATUS: Confirmed" -H "X_AU
TH_TOKEN:"  http://localhost:9311/v1/474bc6aec82f447ca5e4452516e0b2aa/secrets   

 <=  Empty token   -   “admin” tenant UID
{"secrets": [], "total": 0} 

   
<= Doesn’t authenticate therefore no secrets


(barbican27)[root@iac-int-ma15 ~]# curl -XGET -d '{}' -H "Content-type: 
application/json" -H "X_IDENTITY_   
  <= Empty token   -“service” tenant UID
TH_TOKEN:"  http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets   

  <= Shouldn’t authenticate, but secrets returned
{"secrets": [{"status": "ACTIVE", "secret_ref": 
"http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets/88a99c9f-5c32-444
6-8868-f732ca0c8df3", "updated": "2014-07-09T14:21:53.845324", "name": "test", 
"algorithm": null, "created": "2014-07-09T14:21:53.84
5315", "content_types": {"default": "text/plain"}, "mode": null, "bit_length": 
null, "expiration": null}, {"status": "ACTIVE", "secr
et_ref": 
"http://localhost:9311/v1/4d9cc78fdd7746c1895d0c0fc37d8a24/secrets/005c4bba-959e-4deb-9be3-1115516ff20f";,
 "updated": "2014-
07-09T14:33:13.908756", "name": "ppm", "algorithm": null, "created": 
"2014-07-09T14:33:13.908746", "content_types": {"default": "tex
t/plain"}, "mode": null, "bit_length": null, "expiration": null}, {"status": 
"ACTIVE", "secret_ref": "http://localhost:9311/v1/4d9cc
78fdd7746c1895d0c0fc37d8a24/secrets/1c095c70-c8bb-452d-b4c4-db0685d448b5", 
"updated": "2014-07-09T14:34:44.042212", "name": "nsapi",  

The following comes from the “populate-data.sh” script that we use to populate 
the empty Keystone DB at Keystone/Barbican setup:
# Add Roles to Users in Tenants
keystone user-role-add --user $ADMIN_USER --role $ADMIN_ROLE --tenant-id 
$ADMIN_TENANT
keystone user-role-add --user $SERVICE_USER --role $SERVICE_ROLE --tenant-id 
$SERVICE_TENANT
keystone user-role-add --user $BARBICAN_USER --role $ADMIN_ROLE  --tenant-id 
$SERVICE_TENANT

# Create BARBICAN Service
BARBICAN_SERVICE=$(get_id keystone service-create --name=barbican 
--type="keystore" --description="Barbican Key Management Service")

# Create BARBICAN Endpoint
keystone endpoint-create --region RegionOne --service_id $BARBICAN_SERVICE 
--publicurl "http://localhost:9311/v1"; --adminurl "http://localhost:9312/v1"; 
--internalurl http://localhost:9313/v1


Some questions:

1.  Should the “service” tenant bypass authentication and return secrets, 
due to its registered association with the Barbican Service?

2.  If so, is there a way to turn this off, so that the service tenant 
can’t be used to gather secrets?

3.  How do we turn on DEBUG in Keystone, so that we can see authentication 
occurring in Keystone in real time?

We are planning on distributing Barbican and Keystone as a secure keystore in 
an upcoming release of Cisco Systems cloud automation software, and are hoping 
to nail this down soon to get this release ready,

Re: [openstack-dev] [barbican] Nominating Nathan Reller for barbican-core

[John Wood]

+1

Thanks,
John

From: Douglas Mendizabal [douglas.mendiza...@rackspace.com]
Sent: Thursday, July 10, 2014 12:11 PM
To: OpenStack Development Mailing List (not for usage questions); Nathan Reller
Subject: [openstack-dev] [barbican] Nominating Nathan Reller for
barbican-core

Hi Everyone,

I would also like to nominate Nathan Reller for the barbican-core team.

Nathan has been involved with the Key Management effort since early 2013.  
Recently, Nate has been driving the development of a KMIP backend for Barbican, 
which will enable Barbican to be used with KMIP devices.  Nate’s input to the 
design of the plug-in mechanisms in Barbican has been extremely helpful, as 
well as his feedback in CR reviews.

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

Thanks,
Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [barbican] Nominating Ade Lee for barbican-core

[John Wood]

+1

Thanks,
John

From: Douglas Mendizabal [douglas.mendiza...@rackspace.com]
Sent: Thursday, July 10, 2014 11:55 AM
To: OpenStack Development Mailing List (not for usage questions); 
a...@redhat.com
Subject: [openstack-dev] [barbican] Nominating Ade Lee for barbican-core

Hi Everyone,

I would like to nominate Ade Lee for the barbican-core team.

Ade has been involved in the development of Barbican since January of this 
year, and he’s been driving the work to enable DogTag to be used as a back end 
for Barbican.  Ade’s input to the design of barbican has been invaluable, and 
his reviews are always helpful, which has earned him the respect of the 
existing barbican-core team.

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,
Doug


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] Barebones CA

[John Wood]

Hello folks,

Just trying clarify things...are we talking about a dev plugin to generate 
asymmetric keys, or else one to mimic working with a CA to create SSL 
certificates via workflow (so including firing off certificate-generated 
events, for example)?  

If we are talking about the former, then you would be interested in a plugin 
that implements a method such as this one: 
https://github.com/openstack/barbican/blob/master/barbican/plugin/interface/secret_store.py#L167

If you are talking about the latter, then that would be a different type of 
plugin that handles CA workflows, as proposed in this blueprint: 
https://review.openstack.org/#/c/99221/

Thanks,
John


From: Nathan Kinder [nkin...@redhat.com]
Sent: Wednesday, June 25, 2014 9:43 PM
To: OpenStack Development Mailing List (not for usage questions); 
a...@redhat.com
Subject: Re: [openstack-dev] [Barbican] Barebones CA

On 06/25/2014 02:42 PM, Clark, Robert Graham wrote:
>
> Ok, I’ll hack together a dev plugin over the next week or so, other work
> notwithstanding. Where possible I’ll probably borrow from the dog tag
> plugin as I’ve not looked closely at the plugin infrastructure in Barbican
> recently.

My understanding is that Barbican's plugin interface is currently in the
midst of a redesign, so be careful not to copy something that will be
changing shortly.

-NGK

>
> Is this something you’d like a blueprint for first?
>
> -Rob
>
>
>
>
> On 25/06/2014 18:30, "Ade Lee"  wrote:
>
>> I think the plan is to create a Dogtag instance so that integration
>> tests can be run whenever code is checked in (both with and without a
>> Dogtag backend).
>>
>> Dogtag isn't that difficult to deploy, but being a Java app, it does
>> bring in a set of dependencies that developers may not want to deal with
>> for basic/ devstack testing.
>>
>> So, I agree that a simple OpenSSL CA may be useful at least initially as
>> a 'dev' plugin.
>>
>> Ade
>>
>> On Wed, 2014-06-25 at 16:31 +, Jarret Raim wrote:
>>> Rob,
>>>
>>> RedHat is working on a backend for Dogtag, which should be capable of
>>> doing something like that. That's still a bit hard to deploy, so it
>>> would
>>> make sense to extend the 'dev' plugin to include those features.
>>>
>>>
>>> Jarret
>>>
>>>
>>> On 6/24/14, 4:04 PM, "Clark, Robert Graham"  wrote:
>>>
>>>> Yeah pretty much.
>>>>
>>>> That¹s something I¹d be interested to work on, if work isn¹t ongoing
>>>> already.
>>>>
>>>> -Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 24/06/2014 18:57, "John Wood"  wrote:
>>>>
>>>>> Hello Robert,
>>>>>
>>>>> I would actually hope we have a self-contained certificate plugin
>>>>> implementation that runs 'out of the box' to enable certificate
>>>>> generation orders to be evaluated and demo-ed on local boxes.
>>>>>
>>>>> Is this what you were thinking though?
>>>>>
>>>>> Thanks,
>>>>> John
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>> From: Clark, Robert Graham [robert.cl...@hp.com]
>>>>> Sent: Tuesday, June 24, 2014 10:36 AM
>>>>> To: OpenStack List
>>>>> Subject: [openstack-dev] [Barbican] Barebones CA
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I¹m sure this has been discussed somewhere and I¹ve just missed it.
>>>>>
>>>>> Is there any value in creating a basic ŒCA¹ and plugin to satisfy
>>>>> tests/integration in Barbican? I¹m thinking something that probably
>>>>> performs OpenSSL certificate operations itself, ugly but perhaps
>>> useful
>>>>> for some things?
>>>>>
>>>>> -Rob
>>>>>
>>>>> ___
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>> ___
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>

Re: [openstack-dev] [Barbican] Barebones CA

[John Wood]

Hello Robert,

I would actually hope we have a self-contained certificate plugin 
implementation that runs 'out of the box' to enable certificate generation 
orders to be evaluated and demo-ed on local boxes. 

Is this what you were thinking though?

Thanks,
John




From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Tuesday, June 24, 2014 10:36 AM
To: OpenStack List
Subject: [openstack-dev] [Barbican] Barebones CA

Hi all,

I’m sure this has been discussed somewhere and I’ve just missed it.

Is there any value in creating a basic ‘CA’ and plugin to satisfy 
tests/integration in Barbican? I’m thinking something that probably performs 
OpenSSL certificate operations itself, ugly but perhaps useful for some things?

-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Blueprint CR to add SSL certificate workflows

[John Wood]

Hello folks,

We have created a blueprint CR to add SSL certificate generation support to 
Barbican here: https://review.openstack.org/#/c/99221

In short, we would like to utilize Barbican's orders resource to initiate and 
manage the process of working with a certificate authority (CA) to generate 
certificate information.

We would welcome community feedback on this blueprint.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Barbican 2014.2 ("Juno") M1 is released

[John Wood]

Hello everyone,

It is my pleasure to announce the first milestone release of Barbican for Juno 
2014.2.

Information on the milestone and its associated tarball are available at: 
https://launchpad.net/barbican/juno/juno-1

With this release, work has been started to support other order generation 
types (such as asymmetric keys and certificates), as well as numerous bug fixes.

Thanks to our contributors and supporters for this release.

--
John Wood

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[John Wood]

The impression I have from this thread is that Containers should remain 
immutable, but it would be helpful to allow services like LBaaS to register as 
interested in a given Container. This could be the full URI to the load 
balancer instance for example. This information would allow clients to see what 
services (and load balancer instances in this example) are using a Container, 
so they can update them if a new Container replaces the old one. They could 
also see what services depend on a Container before trying to remove the 
Container.

A blueprint submission to Barbican tomorrow should provide more details on 
this, and let the Barbican and LBaaS communities weigh in on this feature.

Thanks,
John



From: Tiwari, Arvind [arvind.tiw...@hp.com]
Sent: Monday, June 09, 2014 2:54 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

As per current implementation, containers are immutable.
Do we have any use case to make it mutable? Can we live with new container 
instead of updating an existing container?

Arvind

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, June 09, 2014 1:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

As far as I understand the Current Barbican implementation is immutable.
Can anyone from Barbican comment on this?

-Original Message-
From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Monday, June 09, 2014 8:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

+1 for the idea of making certificate immutable.
However, if Barbican allows updating certs/containers then versioning is a must.

Thanks,
Vivek


On 6/8/14, 11:48 PM, "Samuel Bercovici"  wrote:

>Hi,
>
>I think that option 2 should be preferred at this stage.
>I also think that certificate should be immutable, if you want a new
>one, create a new one and update the listener to use it.
>This removes any chance of mistakes, need for versioning etc.
>
>-Sam.
>
>-Original Message-
>From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
>Sent: Friday, June 06, 2014 10:16 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS
>Integration Ideas
>
>Hey everyone,
>
>Per our IRC discussion yesterday I'd like to continue the discussion on
>how Barbican and Neutron LBaaS will interact. There are currently two
>ideas in play and both will work. If you have another idea please free
>to add it so that we may evaluate all the options relative to each other.
>Here are the two current ideas:
>
>1. Create an eventing system for Barbican that Neutron LBaaS (and other
>services) consumes to identify when to update/delete updated secrets
>from Barbican. For those that aren't up to date with the Neutron LBaaS
>API Revision, the project/tenant/user provides a secret (container?) id
>when enabling SSL/TLS functionality.
>
>* Example: If a user makes a change to a secret/container in Barbican
>then Neutron LBaaS will see an event and take the appropriate action.
>
>PROS:
> - Barbican is going to create an eventing system regardless so it will
>be supported.
> - Decisions are made on behalf of the user which lessens the amount of
>calls the user has to make.
>
>CONS:
> - An eventing framework can become complex especially since we need to
>ensure delivery of an event.
> - Implementing an eventing system will take more time than option #2ŠI
>think.
>
>2. Push orchestration decisions to API users. This idea comes with two
>assumptions. The first assumption is that most providers' customers use
>the cloud via a GUI, which in turn can handle any orchestration
>decisions that need to be made. The second assumption is that power API
>users are savvy and can handle their decisions as well. Using this
>method requires services, such as LBaaS, to "register" in the form of
>metadata to a barbican container.
>
>* Example: If a user makes a change to a secret the GUI can see which
>services are registered and opt to warn the user of consequences. Power
>users can look at the registered services and make decisions how they
>see fit.
>
>PROS:
> - Very simple to implement. The only code needed to make this a
>reality is at the control plane (API) level.
> - This option is more loosely coupled that option #1.
>
>CONS:
> - Potential for services to not register/unregister. What happens in
>this case?
> - Pushes complexity of decision making on to GUI engineers and power
>API users.
>
>
>I would like to get a consensus on which option to move forward with
>ASAP since the hackathon is coming up and delivering Barbican to
>Neutron LBaaS integration is essential to exp

Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

[John Wood]

Hello Jorge,

Just noting that for option #2, it seems to me that the registration feature in 
Barbican would not be required for the first version of this integration 
effort, but we should create a blueprint for it nonetheless. 

As for your question about services not registering/unregistering, I don't see 
an issue as long as the presence or absence of registered services on a 
Container/Secret does not **block** actions from happening, but rather is 
information that can be used to warn clients through their processes. For 
example, Barbican would still delete a Container/Secret even if it had 
registered services.

Does that all make sense though?

Thanks,
John


From: Youcef Laribi [youcef.lar...@citrix.com]
Sent: Friday, June 06, 2014 2:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS 
Integration Ideas

+1 for option 2.

In addition as an additional safeguard, the LBaaS service could check with 
Barbican when failing to use an existing secret to see if the secret has 
changed (lazy detection).

Youcef

-Original Message-
From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com]
Sent: Friday, June 06, 2014 12:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration 
Ideas

Hey everyone,

Per our IRC discussion yesterday I'd like to continue the discussion on how 
Barbican and Neutron LBaaS will interact. There are currently two ideas in play 
and both will work. If you have another idea please free to add it so that we 
may evaluate all the options relative to each other.
Here are the two current ideas:

1. Create an eventing system for Barbican that Neutron LBaaS (and other
services) consumes to identify when to update/delete updated secrets from 
Barbican. For those that aren't up to date with the Neutron LBaaS API Revision, 
the project/tenant/user provides a secret (container?) id when enabling SSL/TLS 
functionality.

* Example: If a user makes a change to a secret/container in Barbican then 
Neutron LBaaS will see an event and take the appropriate action.

PROS:
 - Barbican is going to create an eventing system regardless so it will be 
supported.
 - Decisions are made on behalf of the user which lessens the amount of calls 
the user has to make.

CONS:
 - An eventing framework can become complex especially since we need to ensure 
delivery of an event.
 - Implementing an eventing system will take more time than option #2ŠI think.

2. Push orchestration decisions to API users. This idea comes with two 
assumptions. The first assumption is that most providers' customers use the 
cloud via a GUI, which in turn can handle any orchestration decisions that need 
to be made. The second assumption is that power API users are savvy and can 
handle their decisions as well. Using this method requires services, such as 
LBaaS, to "register" in the form of metadata to a barbican container.

* Example: If a user makes a change to a secret the GUI can see which services 
are registered and opt to warn the user of consequences. Power users can look 
at the registered services and make decisions how they see fit.

PROS:
 - Very simple to implement. The only code needed to make this a reality is at 
the control plane (API) level.
 - This option is more loosely coupled that option #1.

CONS:
 - Potential for services to not register/unregister. What happens in this case?
 - Pushes complexity of decision making on to GUI engineers and power API users.


I would like to get a consensus on which option to move forward with ASAP since 
the hackathon is coming up and delivering Barbican to Neutron LBaaS integration 
is essential to exposing SSL/TLS functionality, which almost everyone has 
stated is a #1/#2 priority.

I'll start the decision making process by advocating for option #2. My reason 
for choosing option #2 has to deal mostly with the simplicity of implementing 
such a mechanism. Simplicity also means we can implement the necessary code and 
get it approved much faster which seems to be a concern for everyone. What 
option does everyone else want to move forward with?



Cheers,
--Jorge


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

[John Wood]

Hello Samuel,

The team is working on adding transport key support to Barbican per this 
blueprint: 
https://blueprints.launchpad.net/barbican/+spec/add-wrapping-key-to-barbican-server

We would like to add convenience methods to the Python barbican client to 
support this key wrapping behavior. 


From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 29, 2014 7:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS APIsupport for 
authentication

+1 to Carlos.

In addition, there should be possible for LBaaS (It might only be just the 
LBaaS drivers) to get the information including the private key back so that 
the backend can use it.
This means that a "trusted" communication channel between the driver and 
Barbican needs to be established so that such information will be passed.
I am waiting for the "code review" in barbican to check that such capabilities 
will be available.

Regards,
-Sam.



-Original Message-
From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: Wednesday, May 28, 2014 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication


On May 27, 2014, at 9:13 PM, Stephen Balukoff 
 wrote:

> Hi y'all!
>
> I would advocate that if the user asks the front-end API for the private key 
> information (ie. "GET" request), what they get back is the key's modulus and 
> nothing else. This should work to verify whether a given key matches a given 
> cert, and doesn't break security requirements for those who are never allowed 
> to actually touch private key data. And if a user added the key themselves 
> through the front-end API, I think it's safe to assume the responsibility for 
> keeping a copy of the key they can access lies with the user.

I'm thinking at this point all user interaction with their cert and key be 
handled by barbican directly instead of through our API. It seems like we've 
punted everything but the IDs to barbican. Returning the modulus is still RSA 
centric though.


>
> Having said this, of course anything which spins up virtual appliances, or 
> configures physical appliances is going to need access to the actual private 
> key. So any back-end API(s) will probably need to have different behavior 
> here.
>
> One thing I do want to point out is that with the 'transient' nature of 
> back-end guests / virtual servers, it's probably going to be important to 
> store the private key data in something non-volatile, like barbican's store. 
> While it may be a good idea to add a feature that generates a private key and 
> certificate signing request via our API someday for certain organizations' 
> security requirements, one should never have the only store for this private 
> key be a single virtual server. This is also going to be important if a 
> certificate + key combination gets re-used in another listener in some way, 
> or when horizontal scaling features get added.

I don't think our API needs to handle the CSRs it looks like barbican 
aspires to do this so our API really is pretty insulated.

>
> Thanks,
> Stephen
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican] KMIP support

[John Wood]

Hello Robert,

Nathan Reller has created a blueprint for this effort here: 
https://blueprints.launchpad.net/barbican/+spec/kmip-secret-store

The first of several CRs to implement this feature is underway here: 
https://review.openstack.org/#/c/94710/

I'll defer to others regarding the open KMIP client status.

Thanks,
John



From: Clark, Robert Graham [robert.cl...@hp.com]
Sent: Sunday, June 01, 2014 2:17 PM
To: OpenStack List
Subject: [openstack-dev] [Barbican] KMIP support

All,

I’m researching a bunch of HSM applications and I’m struggling to find much 
info. I was wondering about the progress of KMIP support in Barbican? Is this 
waiting on an open python KMIP support?

Also, is the “OpenStack KMIP Client” ever going to be a thing? 
(https://wiki.openstack.org/wiki/KMIPclient)

Cheers
-Rob

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Barbican][Heat] Reviews requested for Barbican resources

[John Wood]

Hello Randall,

We'll take a look at these CRs for sure, thanks.

Thanks,
John


From: Randall Burt [randall.b...@rackspace.com]
Sent: Thursday, May 29, 2014 3:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Barbican][Heat] Reviews requested for Barbican
resources

Hello Barbican devs. I was wondering if we could get some of you to weigh in on 
a couple of reviews for adding Barbican support in Heat. We seem to be churning 
a bit around current and future features supported by the resources and could 
use some expert opinions.

Blueprint: https://blueprints.launchpad.net/heat/+spec/barbican-resources
Order Resource: https://review.openstack.org/81906
Secret Resource: https://review.openstack.org/79355

Thanks in advance for your time.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Juno roadmap items

[John Wood]

Hello folks,

An etherpad capturing potential CRs for the Juno release is available here: 
https://etherpad.openstack.org/p/barbican-juno-roadmap

Suggestions/corrections are welcome!

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[John Wood]

to 
store pfx files in the LBaaS DB and store the key for the pfx files in 
Barbican. You could probably store them together in Barbican, using containers 
if you really wanted to 
(https://blueprints.launchpad.net/barbican/+spec/crud-endpoints-secret-container)

-Rob

From: Carlos Garza [mailto:carlos.ga...@rackspace.com]
Sent: 08 May 2014 04:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN


On May 7, 2014, at 10:53 AM, Samuel Bercovici 
mailto:samu...@radware.com>> wrote:

Hi John,

If the user already has an SSL certificate that was acquired outside of the 
barbican Ordering system, how can he store it securely in Barbican as a SSL 
Certificate?
The Container stored this information in a very generic way, I think that there 
should be an API that formalizes a specific way in which SSL certificates can 
be stored and read back as SSL Certificates and not as loosely coupled 
container structure.
This such API should have RBAC that allows getting back only the public part of 
an SSL certificate vs. allowing to get back all the details of the SSL 
certificate.

Why the need for that complexity? The X509s are public by nature and don't 
need to be stored in Barbican so there isn't really a private part of the 
certificate. The actual private key itself is what needs to be secured so I 
would advocate that the private key is what will be stored in barbican. I also 
think we should also declare that the private key need not be an RSA key as 
x509 supports other asymmetric encryption types so storing as a generic blob in 
barbican is probably a good idea.





-Sam.



From: John Wood [mailto:john.w...@rackspace.com<http://RACKSPACE.COM>]
Sent: Thursday, May 01, 2014 11:28 PM
To: OpenStack Development Mailing List (not for usage 
questions);os.v...@gmail.com<mailto:os.v...@gmail.com>
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

Hello Samuel,

Just noting that the link below shows current-state Barbican. We are in the 
process of designing SSL certificate support for Barbican via blueprints such 
as this one: 
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
We intend to discuss this feature in Atlanta to enable coding in earnest for 
Juno.

The Container resource is intended to capture/store the final certificate 
details.

Thanks,
John



From: Samuel Bercovici [samu...@radware.com<mailto:samu...@radware.com>]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.com<mailto:os.v...@gmail.com>
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN
Hi Vijay,

I have looked at the Barbican APIs 
–https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a “native” API that will accept an SSL certificate 
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as a single file as a secret or use a 
container and store all the certificate parts as secrets.

I think that having LBaaS reference Certificates as IDs using some service is 
the right way to go so this might be achived by either:
1.   Adding to Barbican and API to store / generate certificates
2.   Create a new “module” that might start by being hosted in neutron or 
keystone that will allow to manage certificates and will use Barbican behind 
the scenes to store them.
3.   Decide on a container structure to use in Babican but implement the 
way to access and arrange it as a neutron library

Was any decision made on how to proceed?

Regards,
-Sam.




From: Vijay B [mailto:os.v...@gmail.com]
Sent: Wednesday, April 30, 2014 3:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for 
LBaaS and VPN

Hi,

It looks like there are areas of common effort in multiple efforts that are 
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   
(https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   
(https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it better 
to implement SSL entities as first class citizens in the OS world. So, three 
points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a 
mapping table, instead of maintaining certs separately and referencing them 
using IDs. The LBaaS implementation stores certificates in a separate table, 
but implements the necessary extensions and logic unde

Re: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review

[John Wood]

Hello Arvind,

These all look like topics to dig into if possible at the summit, so let's 
discuss this at today's IRC meeting for sure.

Thanks,
John


From: Tiwari, Arvind [arvind.tiw...@hp.com]
Sent: Monday, May 05, 2014 11:24 AM
To: Tiwari, Arvind; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review

Chad,

Please let me know if you want me to start etherpads for them?

Regards,
Arvind

From: Tiwari, Arvind
Sent: Monday, May 05, 2014 10:22 AM
To: openstack-dev@lists.openstack.org
Subject: RE: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review

Hi Chad,

We are working on following topics and expecting some time to discuss in the 
summit. Can we accommodate them in the summit?

https://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level 
(We are working on POC + API change proposal)
https://blueprints.launchpad.net/barbican/+spec/api-remove-uri-tenant-id (API 
change proposal)
https://blueprints.launchpad.net/barbican/+spec/ability-to-hard-delete-barbican-entities
 (API change proposal)

Thanks,
Arvind


From: Chad Lung [mailto:chad.l...@gmail.com]
Sent: Monday, May 05, 2014 10:06 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Atlanta Summit Etherpads for Review


The Barbican team has placed a few etherpads on our wiki for the community to 
review. We plan to work on these at the Atlanta summit next week in our 
sessions and throughout the week.

https://wiki.openstack.org/wiki/Barbican#Discussions_.2F_Etherpads
Thanks,
Chad Lung
http://giantflyingsaucer.com/blog/
@chadlung
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert implementation for LBaaS and VPN

[John Wood]

Hello Samuel,

Just noting that the link below shows current-state Barbican. We are in the 
process of designing SSL certificate support for Barbican via blueprints such 
as this one: 
https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates
We intend to discuss this feature in Atlanta to enable coding in earnest for 
Juno.

The Container resource is intended to capture/store the final certificate 
details.

Thanks,
John



From: Samuel Bercovici [samu...@radware.com]
Sent: Thursday, May 01, 2014 12:50 PM
To: OpenStack Development Mailing List (not for usage questions); 
os.v...@gmail.com
Subject: Re: [openstack-dev] [Neutron] [LBaaS][VPN][Barbican] SSL cert 
implementation for LBaaS and VPN

Hi Vijay,

I have looked at the Barbican APIs – 
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
I was no able to see a “native” API that will accept an SSL certificate 
(private key, public key, CSR, etc.) and will store it.
We can either store the whole certificate as a single file as a secret or use a 
container and store all the certificate parts as secrets.

I think that having LBaaS reference Certificates as IDs using some service is 
the right way to go so this might be achived by either:

1.   Adding to Barbican and API to store / generate certificates

2.   Create a new “module” that might start by being hosted in neutron or 
keystone that will allow to manage certificates and will use Barbican behind 
the scenes to store them.

3.   Decide on a container structure to use in Babican but implement the 
way to access and arrange it as a neutron library

Was any decision made on how to proceed?

Regards,
-Sam.




From: Vijay B [mailto:os.v...@gmail.com]
Sent: Wednesday, April 30, 2014 3:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for 
LBaaS and VPN

Hi,

It looks like there are areas of common effort in multiple efforts that are 
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   
(https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   
(https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it better 
to implement SSL entities as first class citizens in the OS world. So, three 
points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a 
mapping table, instead of maintaining certs separately and referencing them 
using IDs. The LBaaS implementation stores certificates in a separate table, 
but implements the necessary extensions and logic under LBaaS. We propose that 
both these implementations move away from this and refer to SSL entities using 
IDs, and that the SSL entities themselves are implemented as their own 
resources, serviced either by a core plugin or a new SSL plugin (assuming 
neutron; please also see point 3 below).

2. The actual data store where the certs and keys are stored should be 
configurable at least globally, such that the SSL plugin code will singularly 
refer to that store alone when working with the SSL entities. The data store 
candidates currently are Barbican and a sql db. Each should have a separate 
backend driver, along with the required config values. If further evaluation of 
Barbican shows that it fits all SSL needs, we should make it a priority over a 
sqldb driver.

3. Where should the primary entries for the SSL entities be stored? While the 
actual certs themselves will reside on Barbican or SQLdb, the entities 
themselves are currently being implemented in Neutron since they are being 
used/referenced there. However, we feel that implementing them in keystone 
would be most appropriate. We could also follow a federated model where a 
subset of keys can reside on another service such as Neutron. We are fine with 
starting an initial implementation in neutron, in a modular manner, and move it 
later to keystone.


Please provide your inputs on this.


Thanks,
Regards,
Vijay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

[John Wood]

I was going to bring up Postern [1] as well, Clint. Unfortunately not much work 
has been done on it though. 

[1] https://github.com/cloudkeep/postern

Thanks,
John




From: Clint Byrum [cl...@fewbar.com]
Sent: Thursday, May 01, 2014 2:22 PM
To: openstack-dev
Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

Excerpts from Nachi Ueno's message of 2014-05-01 12:04:23 -0700:
> Ah I got it now!
> so even if we get stolen HDD, we can keep password safe.
>
> However, I'm still not sure why this is more secure..
> anyway, the ID/PW to access barbican will be written in neutron.conf, right?
>

Yes. However, you can surround the secret in policies. You'll have an
audit trail of when and where it was accessed, and you can even restrict
access, so that out of band you have to open up access with barbican.

So while the server may have access, that access is now audited and
limited by policy, instead of just being dependent on the security
measures you can take to protect a file.

> Furthermore,  ID/PW for mysql will be written in conf file..
> so if we can't trust unix file system protection, there is no security
> in OpenStack.

The ID/PW for mysql only grants you access to mysql for as long as that
id/pw are enabled for access. However, the encryption keys for OpenVPN
will grant any passive listener access for as long as they keep any
sniffed traffic. They'll also grant an attacker the ability to MITM
traffic between peers.

So when an encryption key has been accessed, from where, etc, is quite
a bit more crucial than knowing when a username/password combo have
been accessed.

Producing a trustworthy audit log for access to /etc/neutron/neutron.conf
is a lot harder than producing an audit log for a REST API.

So it isn't so much that file system permissions aren't enough, it is
that file system observability is expensive.

Note that at some point there was a POC to have a FUSE driver backed by
Barbican called 'Postern' I think. That would make these discussions a
lot simpler. :)

>
> 2014-05-01 10:31 GMT-07:00 Clint Byrum :
> > I think you'd do something like this (Note that I don't know off the top
> > of my head the barbican CLI or openvpn cli switches... just
> > pseudo-code):
> >
> > oconf=$(mktemp -d /tmp/openvpnconfig.XX)
> > mount -o tmpfs $oconf size=1M
> > barbican get my-secret-openvpn-conf > $oconf/foo.conf
> > openvpn --config-dir $oconf foo --daemonize
> > umount $oconf
> > rmdir $oconf
> >
> > Excerpts from Nachi Ueno's message of 2014-05-01 10:15:26 -0700:
> >> Hi Robert
> >>
> >> Thank you for your suggestion.
> >> so your suggestion is let OpenVPN process download key to memory
> >> directly from Babican?
> >>
> >> 2014-05-01 9:42 GMT-07:00 Clark, Robert Graham :
> >> > Excuse me interrupting but couldn't you treat the key as largely
> >> > ephemeral, pull it down from Barbican, start the OpenVPN process and
> >> > then purge the key?  It would of course still be resident in the memory
> >> > of the OpenVPN process but should otherwise be protected against
> >> > filesystem disk-residency issues.
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Nachi Ueno [mailto:na...@ntti3.com]
> >> >> Sent: 01 May 2014 17:36
> >> >> To: OpenStack Development Mailing List (not for usage questions)
> >> >> Subject: Re: [openstack-dev] [Neutron] SSL VPN Implemenatation
> >> >>
> >> >> Hi Jarret
> >> >>
> >> >> IMO, Zang point is the issue saving plain private key in the
> >> > filesystem for
> >> >> OpenVPN.
> >> >> Isn't this same even if we use Barbican?
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> 2014-05-01 2:56 GMT-07:00 Jarret Raim :
> >> >> > Zang mentioned that part of the issue is that the private key has to
> >> >> > be stored in the OpenVPN config file. If the config files are
> >> >> > generated and can be stored, then storing the whole config file in
> >> >> > Barbican protects the private key (and any other settings) without
> >> >> > having to try to deliver the key to the OpenVPN endpoint in some
> >> > non-
> >> >> standard way.
> >> >> >
> >> >> >
> >> >> > Jarret
> >> >> >
> >> >> > On 4/30/14, 6:08 PM, "Nachi Ueno"  wrote:
> >> >> >
> >> >> >>> Jarret
> >> >> >>
> >> >> >>Thanks!
> >> >> >>Currently, the config will be generated on demand by the agent.
> >> >> >>What's merit storing entire config in the Barbican?
> >> >> >>
> >> >> >>> Kyle
> >> >> >>Thanks!
> >> >> >>
> >> >> >>2014-04-30 7:05 GMT-07:00 Kyle Mestery
> >> >> :
> >> >> >>> On Tue, Apr 29, 2014 at 6:11 PM, Nachi Ueno 
> >> >> wrote:
> >> >>  Hi Clint
> >> >> 
> >> >>  Thank you for your suggestion. Your point get taken :)
> >> >> 
> >> >> > Kyle
> >> >>  This is also a same discussion for LBaaS Can we discuss this in
> >> >>  advanced service meeting?
> >> >> 
> >> >> >>> Yes! I think we should definitely discuss this in the advanced
> >> >> >>> services meeting today. I've added it to the agenda [1].
> >> >> >>>
> >> >> >>

Re: [openstack-dev] [barbican] certificate orders discussion

[John Wood]

Hello folks,

FWIW, we've been trying to refine the ssl cert generation workflows via this 
blueprint: https://blueprints.launchpad.net/barbican/+spec/add-ssl-ca-support

These flows could be kicked off via the orders API.

Thanks,
John




From: Adam Young [ayo...@redhat.com]
Sent: Monday, April 28, 2014 2:52 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [barbican] certificate orders discussion

On 04/28/2014 02:07 PM, Pitucha, Stanislaw Izaak wrote:

Hi all,
I've seen some blueprints/wikis from people interested in certificate
signing via barbican orders, so hopefully you'll have some feedback.

I submitted a proposal for certificate/signing order API at
https://review.openstack.org/90613 (based on previous Arvind's work with
keys)

Good stuff.


It's not pretty and needs some more details, but it's there :)
There are some things I wasn't really sure how to handle, so here's my
reasoning you may have an opinion on:

1. The keys for generating a new certificate request + signing could be
handled inside of the generate+sign order. This would require fewer requests
than uploading a key as a secret first, but on the other hand, there's
already an api for generating those keys, so it would be nice to just
reference the key potentially already generated by barbican. I went with
posting an id reference to the key.

Lets not reinvent a format here.  Certmonger can already do that stuff client 
side, so lets just focus on getting the request to the server, signed, and 
returned.



2. The signing-only request takes the pkcs10-style csr inline in its meta
part. I thought about treating it that same as the key decision above, but
thought this would be wrong. The request isn't really secret - it doesn't
contain any private data, so it would be incorrect to treat it the same as
keys.

Correct.  This should be simpler than a Keys escrow call:  you might want to do 
key escrow for encryption keys that get signed this way, but that could used 
the existing mechanism via a separate call, either prior or after.  Prior might 
 be the way to go:  "if you request a certificate with an encryption attribute, 
you need to have submitted the key for escrow."

On the other hand, having one order to generate a CSR and one to sign it
would be a cleaner design without a mix of attributes that are required or
not depending on the use case.
In this case the first option won - just include it as inline - generation
of the request by barbican is unlikely to be a very common case.

Otherwise, if you're interested in certificate orders, please have a look
and see if the proposed api is missing any parts you would like to see.
Maybe we can figure it out before the coding starts :)

Lets get the basics down:  process a CSR.  We still need to handle the workflow 
for approval.



Regards,
Stanisław Pitucha
Cloud Services
Hewlett Packard





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] [messaging] Curious about retry/scheduled tasks

[John Wood]

Hello folks,

I am curious if olso.messaging exposes a means to support retry and defer 
semantics for tasks. For example, it could be nice to retry processing a failed 
task under some circumstances, such as if a network service is temporarily 
unavailable. It might also be beneficial to be able to run a task at a time in 
the future, or on a recurring basis such as to drive an asynchronous polling 
process.

These features can be handled in application code or orchestration services of 
course, but just curious if olso.messaging provides a lower-level mechanism for 
handling this.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Icehouse-3 development milestone available

[John Wood]

Hi everyone,

The third (and last) milestone of the Icehouse development cycle,
"icehouse-3", is now available for Barbican.

You can see the full list of new features and fixed bugs, as well as
tarball downloads, at: https://launchpad.net/barbican/+milestone/icehouse-3

This release includes code changes and bug fixes, including to satisfy 
incubation requirements.

Thanks to all who helped with this release!

Thank you,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Barbican 2014.1.b2 ("Icehouse M2") is released

[John Wood]

Hello everyone,

The Barbican team is proud to announce the second milestone delivery for the 
OpenStack Icehouse series.

Information on the milestone and its associated tarball are available at: 
https://launchpad.net/barbican/icehouse/icehouse-2

With this milestone, 3 blueprints have been implemented and 4 bugs have been 
fixed. Here is a quick summary of the new features:

1) Includes several modifications to satisfy incubation requirements, including:
- Utilizes oslo.messaging to replace Celery dependency.
- Uses pbr and implements global requirements.

2) Improves validation error reporting.

3) Adds the ability to query secrets by select fields.

4) Includes numerous file and code base cleanup and test coverage improvements.

An updated Python client library and command line interface for Barbican is 
also available in Pypi here: https://pypi.python.org/pypi/python-barbicanclient/

Thanks to Huseyin Gedikli, Wyllys Ingersoll, Monty Taylor, Craig Tracey, Jarret 
Raim, Andrew Hartnett, Lisa Clark, Douglas Sims, Sheena Gregson, John Vrbanac, 
Steve Heyman, Douglas Mendizabal, Paul Kehrer, Chad Lung, Steven Gonzales, Taz 
El-Kikhia and John Wood for their contributions to this milestone.

--
John Wood

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] olso.messaging and Rabbit HA configs

[John Wood]

Hello folks,

I would like to configure olso.messaging to work with an HA Rabbit cluster and 
was curious about the correct configuration to use.

I am setting the following values in my private network:

ampq_durable_queues = True
rabbit_userid=guest
rabbit_password=guest
rabbit_hosts=192.168.50.8:5672, 192.168.50.9:5672
rabbit_ha_queues = True
rabbit_port=5672
transport_url = rabbit://guest@192.168.50.8:5672,guest@192.168.50.9:5672/


...but when I try to remove the 192.168.50.8 Rabbit node I get this error:

2013-12-20 16:12:18.014 24700 ERROR oslo.messaging._drivers.impl_rabbit [-] 
AMQP server on 192.168.50.8:5672 is unreachable: [Errno 113] No route to host. 
Trying again in 1 seconds.
2013-12-20 16:12:19.016 24700 INFO oslo.messaging._drivers.impl_rabbit [-] 
Reconnecting to AMQP server on 192.168.50.8:5672


I was expecting the node at 192.168.50.9 to be used if 192.168.50.8 became 
unavailable.

Another note is that it appears the transport_url configs are not utilized by 
the impl_rabbit.py module, hence setting the 'rabbit_hosts' separately.

Thanks in advance,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[John Wood]

>> Just an FYI that I've submitted a pull request [1] to replace Celery
>> with oslo.messaging.
>
> wow. That was quick!
>
> /me is impressed

Ha! Just trying to put the polish on! Thanks for the feedback and hope it is a 
step in the right direction. I'll look to add testing for it on Monday or 
before to take it out of 'in progress'.


> Since you jumped on that - I went ahead and jumped on a pbr-ification
> patch for you. ...

Thanks for the assist! I think we have some competing CRs out there but we'll 
sort those out once the oslo.messaging CR goes in...then we'll be able to 
remove Celery from the requirements once and for all!

Thanks again,
John



From: Monty Taylor [mord...@inaugust.com]
Sent: Friday, December 06, 2013 10:11 AM
To: John Wood; Mark McLoughlin; Douglas Mendizabal
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack...@lists.openstack.org; barbi...@lists.rackspace.com
Subject: Re: [openstack-tc] [openstack-dev] Incubation Request for Barbican

On 12/06/2013 08:35 AM, John Wood wrote:
> Hello folks,
>
> Just an FYI that I've submitted a pull request [1] to replace Celery
> with oslo.messaging.

wow. That was quick!

/me is impressed

Since you jumped on that - I went ahead and jumped on a pbr-ification
patch for you. It may not work yet - I'm on weird network and having
trouble install python things into virtualenvs:

  https://review.openstack.org/60551
  https://review.openstack.org/60552


> I've tagged it as a work in progress per this note:
>
> "Please review this CR, which replaces Celery with oslo.messaging
> components. I've verified that this works in my local environment,
> but I still need to add unit testing. I also need to verify that it
> works correctly with an HA Rabbit MQ cluster, as that is a hard
> requirement for Barbican."
>
> Special thanks to Mark McLoughlin and Sylvain Bauza for pointing me
> to very useful links here [2] and here [3] respectively.
>
> [1] https://review.openstack.org/#/c/60427/ [2]
> https://review.openstack.org/#/c/39929 [3]
> https://review.openstack.org/#/c/57880
>
> Thanks, John
>
>  From: Monty Taylor
> [mord...@inaugust.com] Sent: Thursday, December 05, 2013 8:35 PM To:
> Mark McLoughlin; Douglas Mendizabal Cc: OpenStack Development Mailing
> List (not for usage questions); openstack...@lists.openstack.org;
> barbi...@lists.rackspace.com Subject: Re: [openstack-tc]
> [openstack-dev] Incubation Request for Barbican
>
> On 12/06/2013 01:53 AM, Mark McLoughlin wrote:
>> On Thu, 2013-12-05 at 23:37 +, Douglas Mendizabal wrote:
>>>>
>>>> I agree that this is concerning. And that what's concerning
>>>> isn't so much that the project did something different, but
>>>> rather that choice was apparently made because the project
>>>> thought it was perfectly fine for them to ignore what other
>>>> OpenStack projects do and go off and do its own thing.
>>>>
>>>> We can't make this growth in the number of OpenStack projects
>>>> work if each project goes off randomly and does its own thing
>>>> without any concern for the difficulties that creates.
>>>>
>>>> Mark.
>>>
>>> Hi Mark,
>>>
>>> You may have missed it, but barbican has added a blueprint to
>>> change our queue to use oslo.messaging [1]
>>>
>>> I just wanted to clarify that we didn’t choose Celery because we
>>> thought that “it was perfectly fine to ignore what other
>>> OpenStack projects do”. Incubation has been one of our goals
>>> since the project began.  If you’ve taken the time to look at our
>>> code, you’ve seen that we have been using oslo.config this whole
>>> time.  We chose Celery because it was
>>>
>>> a) Properly packaged like any other python library, so we could
>>> just pip-install it. b) Well documented c) Well tested in
>>> production environments
>>>
>>> At the time none of those were true for oslo.messaging.  In
>>> fact, oslo.messgaging still cannot be pip-installed as of today.
>>> Obviously, had we know that using oslo.messaging is hard
>>> requirement in advance, we would have chosen it despite its poor
>>> distribution story.
>>
>> I do sympathise, but it's also true is that all other projects
>> were using the oslo-incubator RPC code at the time you chose
>> Celery.
>>
>> I think all the verbiage in this thread about celery is just to
>> reinforce that we need to be v

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[John Wood]

Hello folks,

Just an FYI that I've submitted a pull request [1] to replace Celery with 
oslo.messaging.

I've tagged it as a work in progress per this note:

"Please review this CR, which replaces Celery with oslo.messaging components. 
I've verified that this works in my local environment, but I still need to add 
unit testing. I also need to verify that it works correctly with an HA Rabbit 
MQ cluster, as that is a hard requirement for Barbican."

Special thanks to Mark McLoughlin and Sylvain Bauza for pointing me to very 
useful links here [2] and here [3] respectively.

[1] https://review.openstack.org/#/c/60427/
[2] https://review.openstack.org/#/c/39929
[3] https://review.openstack.org/#/c/57880

Thanks,
John


From: Monty Taylor [mord...@inaugust.com]
Sent: Thursday, December 05, 2013 8:35 PM
To: Mark McLoughlin; Douglas Mendizabal
Cc: OpenStack Development Mailing List (not for usage questions); 
openstack...@lists.openstack.org; barbi...@lists.rackspace.com
Subject: Re: [openstack-tc] [openstack-dev] Incubation Request for Barbican

On 12/06/2013 01:53 AM, Mark McLoughlin wrote:
> On Thu, 2013-12-05 at 23:37 +, Douglas Mendizabal wrote:
>>>
>>> I agree that this is concerning. And that what's concerning isn't so
>>> much that the project did something different, but rather that choice
>>> was apparently made because the project thought it was perfectly fine
>>> for them to ignore what other OpenStack projects do and go off and do
>>> its own thing.
>>>
>>> We can't make this growth in the number of OpenStack projects work if
>>> each project goes off randomly and does its own thing without any
>>> concern for the difficulties that creates.
>>>
>>> Mark.
>>
>> Hi Mark,
>>
>> You may have missed it, but barbican has added a blueprint to change our
>> queue to use oslo.messaging [1]
>>
>> I just wanted to clarify that we didn’t choose Celery because we thought
>> that “it was perfectly fine to ignore what other OpenStack projects do”.
>> Incubation has been one of our goals since the project began.  If you’ve
>> taken the time to look at our code, you’ve seen that we have been using
>> oslo.config this whole time.  We chose Celery because it was
>>
>> a) Properly packaged like any other python library, so we could just
>> pip-install it.
>> b) Well documented
>> c) Well tested in production environments
>>
>> At the time none of those were true for oslo.messaging.  In fact,
>> oslo.messgaging still cannot be pip-installed as of today.  Obviously, had
>> we know that using oslo.messaging is hard requirement in advance, we would
>> have chosen it despite its poor distribution story.
>
> I do sympathise, but it's also true is that all other projects were
> using the oslo-incubator RPC code at the time you chose Celery.
>
> I think all the verbiage in this thread about celery is just to
> reinforce that we need to be very sure that new projects feel a
> responsibility to fit closely in with the rest of OpenStack. It's not
> about technical requirements so much as social responsibility.
>
> But look - I think you've reacted well to the concern and hopefully if
> it feels like there was an overreaction that you can understand the
> broader thing we're trying to get at here.

I agree. I think you've done an excellent job in responding to it - and
I appreciate that. We're trying to be clearer about expectations moving
forward, which I hope this thread in some part helps with.

Monty

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Barbican 2014.1.b1 ("Icehouse") is released

[John Wood]

Hello everyone,

It is my pleasure to announce the first milestone delivery for the OpenStack 
Icehouse series.

Information on the milestone and its associated tarball are available at: 
https://launchpad.net/barbican/+milestone/icehouse-1

With this milestone, 2 blueprints have been implemented and 5 bugs fixed. 

An updated Python client library and command line interface for Barbican is 
also available in Pypi here: https://pypi.python.org/pypi/python-barbicanclient/

Thanks to Bryan Payne, Wyllys Ingersoll, Dolph Mathews, Jarret Raim, Andrew 
Hartnett, Douglas Sims, Sheena Gregson, John Vrbanac, Steve Heyman, Douglas 
Mendizabal, Paul Kehrer, Constanze Kratel, Arash Ghoreyshi, and John Wood for 
their contributions to this milestone.

-- 
John Wood

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [openstack-tc] [barbican] Curious about oslo.messaging (from Incubation Request for Barbican)

[John Wood]

Hello folks,

I was curious if there is an OpenStack project that would be a good example to 
follow as we convert Barbican over to oslo messaging. 

I've been examining existing OpenStack projects such as Ceilometer and Keystone 
to see how they are utilizing oslo messaging. These projects appear to be 
utilizing packages such as 'rpc' and 'notifier' from the oslo-incubator 
project. It seems that the oslo.messaging project's structure is different than 
the messaging structure of oslo-incubator (there are newer classes such as 
Transport now for example). Is there an example OpenStack project utilizing the 
oslo.messaging structure that might be better for us to follow?

The RPC approach of Ceilometer in particular seems well suited to Barbican's 
use case, so seems to be a good option for us to follow, unless there are 
better options folks can suggest.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



From: Russell Bryant [rbry...@redhat.com]
Sent: Monday, December 02, 2013 8:08 PM
To: Dolph Mathews
Cc: Monty Taylor; OpenStack Development Mailing List (not for usage questions); 
openstack...@lists.openstack.org; cloudkeep@googlegroups. com; 
barbi...@lists.rackspace.com
Subject: Re: [openstack-tc] [openstack-dev] Incubation Request for Barbican

On 12/02/2013 06:46 PM, Dolph Mathews wrote:
>
>
>
> On Mon, Dec 2, 2013 at 11:55 AM, Russell Bryant  > wrote:
>
> On 12/02/2013 12:46 PM, Monty Taylor wrote:
> > On 12/02/2013 11:53 AM, Russell Bryant wrote:
> >>>  * Scope
> >>>  ** Project must have a clear and defined scope
> >>
> >> This is missing
> >>
> >>>  ** Project should not inadvertently duplicate functionality
> present in other
> >>> OpenStack projects. If they do, they should have a clear
> plan and timeframe
> >>> to prevent long-term scope duplication.
> >>>  ** Project should leverage existing functionality in other
> OpenStack projects
> >>> as much as possible
> >>
> >> I'm going to hold off on diving into this too far until the scope is
> >> clarified.
> >
> > I'm not.
> >
> > *snip*
> >
>
> Ok, I can't help it now.
>
> >>
> >> The list looks reasonable right now.  Barbican should put
> migrating to
> >> oslo.messaging on the Icehouse roadmap though.
> >
> > *snip*
>
> Yeahhh ... I looked and even though rpc and notifier are imported, they
> do not appear to be used at all.
>
> >>
> >>
> http://git.openstack.org/cgit/stackforge/barbican/tree/tools/pip-requires
> >>
> >> It looks like the only item here not in the global requirements is
> >> Celery, which is licensed under a 3-clause BSD license.
> >
> > I'd like to address the use of Celery.
> >
> > WTF
> >
> > Barbican has been around for 9 months, which means that it does not
> > predate the work that has become oslo.messaging. It doesn't even
> try. It
> > uses a completely different thing.
> >
> > The use of celery needs to be replaced with oslo. Full stop. I do not
> > believe it makes any sense to spend further time considering a project
> > that's divergent on such a core piece. Which is a shame - because I
> > think that Barbican is important and fills an important need and I
> want
> > it to be in. BUT - We don't get to end-run around OpenStack project
> > choices by making a new project on the side and then submitting it for
> > incubation. It's going to be a pile of suck to fix this I'm sure, and
> > I'm sure that it's going to delay getting actually important stuff
> done
> > - but we deal with too much crazy as it is to pull in a non-oslo
> > messaging and event substrata.
> >
>
> Yeah, I'm afraid I agree with Monty here.  I didn't really address this
> because I was trying to just do a first pass and not go too far into the
> tech bits.
>
> I think such a big divergence is going to be a hard sell for a number of
> reasons.  It's a significant dependency that I don't think is justified.
>  Further, it won't work in all of the same environments that OpenStack
> works in today.  You can't use Celery with all of the same messaging
> transports as oslo.messaging (or the older rpc lib).  One example is
> Qpid.
>
>
> I feel like I'm trying to read past the rant :) so I'd like to stop an
> ask for clarification on the exact argument being made. Is the *only*
> reason that celery should not be used in openstack because it is
> incapable of being deployed against amqp 1.0 brokers (i.e. qpid).
>
> I'm really trying to understand if the actual objection is over the use
> (or not) of oslo (which seems like something the TC should express an
> opin

Re: [openstack-dev] [openstack-tc] Incubation Request for Barbican

[John Wood]

Hello folks,

I've created a blueprint to move over to oslo.messaging per Jarret's comments 
below: https://blueprints.launchpad.net/barbican

I'd also note that out of the box barbican does not use celery in order to 
simplify demo/standalone deployments...asynchronous calls simply invoke their 
worker tasks directly. 

Thanks,
John

From: cloudk...@googlegroups.com [cloudk...@googlegroups.com] on behalf of 
Jarret Raim [jarret.r...@rackspace.com]
Sent: Monday, December 02, 2013 9:16 PM
To: Fox, Kevin M; OpenStack Development Mailing List (not for usage questions); 
Russell Bryant
Cc: openstack...@lists.openstack.org; cloudkeep@googlegroups. com; 
barbi...@lists.rackspace.com
Subject: RE: [openstack-dev] [openstack-tc] Incubation Request for Barbican

> I've been anxious to try out Barbican, but haven't had quite enough time
to
> try it yet. But finding out it won't work with Qpid makes it unworkable
for us
> at the moment. I think a large swath of the OpenStack community won't be
> able to use it in this form too.

As mentioned in the other thread, Barbican will be looking at oslo messaging
for Icehouse.

In the meantime, you can configure celery to use a pass-through (e.g. no
queue needed). This is the configuration we use for dev / testing. The
documentation for that can be found in the celery docs here:
http://docs.celeryproject.org/en/latest/userguide/


Jarret

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

[John Wood]

Hello folks,

FWIW, I've created a wiki page here aimed at easing the code transition to 
barbican for the KDS patch: 
https://github.com/cloudkeep/barbican/wiki/Blueprint:-KDS-Service

Please let us know if we can be of further help.

Thanks,
John
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



From: Thierry Carrez [thie...@openstack.org]
Sent: Monday, November 25, 2013 4:17 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution 
Server, Trusted Messaging

Adam Young wrote:
> Keep KDS configuration separate from the Keystone configuration: the
> fact that they both point to the same host and port is temporary.  In
> fact, we should probably spin up a separate wsgi service/port inside
> Keystone for just the KDS.  This is not hard to do, and will support
> splitting it off into its own service.
>
> KDS should not show up in the Service catalog.  It is not an end user
> visible service and should not look like one to the rest of the world.
>
> Once we have it up and running, we can move it to its own service or
> hand off to Barbican when appropriate.

Right, I think a decent trade-off between availability and avoiding code
duplication would be to have a minimal KDS available as an option in
Keystone, with Barbican/something-else being developed in parallel as
the complex/featureful/configurable option. If Barbican/something-else
reaches feature parity, covers the "basic and simple" use case and is
integrated, we could deprecate the in-Keystone minimal-KDS option.

I know this plan looks a bit like the nova-network chronicles, but I
think the domain is more simple so feature parity is not as much of a
challenge.

--
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Barbican 2013.2 ("Havana") is released

[John Wood]

Hello everyone,

It is my pleasure to announce the final release of Barbican for Havana 2013.2. 

Information on the milestone and its associated tarball are available at: 
https://launchpad.net/cloudkeep/havana/havana

With this release, the following features are available:

1) Added Vagrant support to standup an entire Barbican network locally (so the 
API, queue, worker and database nodes). See this page for more details: 
https://github.com/cloudkeep/barbican/wiki/Vagrant-Usage

2) Addresses bug #1220957, whereby Barbican will return a 500 error on attempts 
to GET binary secrets with an Accept header of text/plain. 
A 406 is returned instead as expected.

An updated Python client library and command line interface for Barbican is 
also available in Pypi here: https://pypi.python.org/pypi/python-barbicanclient/

Thanks to Jarret Raim, Andrew Hartnett, Douglas Sims, Sheena Gregson, John 
Vrbanac, Henry Yamauchi, Douglas Mendizabal, Paul Kehrer, Melissa Kam, Arash 
Ghoreyshi, Malini Bhandaru and John Wood for their contributions to this 
milestone.

-- 
John Wood

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] re: Is barbican suitable/ready for production deployment?

[John Wood]

Hello Pathik,

We are preparing the application for production usage, but it is not yet ready 
to go. We could speak further with you about your production needs if that 
would be of interest.

For evaluation purposes, we have stood up an integration 
environment.
 You could also stand up a local instance of 
Barbican. The PKCS 
based HSM plugin may be used with a SafeNet HSM as well.

Thanks,
John
-
john.w...@rackspace.com


From: Pathik Solanki [psola...@salesforce.com]
Sent: Wednesday, September 25, 2013 6:03 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Is barbican suitable/ready for production 
deployment?

Hi Barbican Team,
My team here at salesforce.com is evaluating Barbican 
for our use case of managing secrets. The git repository indicates that 
Barbican is still in development and not ready for production deployment. I 
vaguely remember from the presentation at OpenStack Summit that 
cloudkeep/barbican has production ready code too. Please correct me if I am 
wrong and if there is some production ready instance then please point me to it.

Thanks,
Pathik
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Barbican] re: MIME types vs path (secrets/{id}/{name})

[John Wood]

Hello Justin,

First off, the current implementation of Barbican only supports one encrypted 
payload per secret record. We plan to revisit this once we begin work on the 
SSL certificate processing features.

As for the Barbican API, please note that the latest Barbican API is located 
here: 
https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface

As detailed in this wiki page, the current implementation of Barbican utilizes 
an 'Accept' request header to indicate to the Barbican service which media type 
to return the secret in. If 'application/json' is provided, only the secret's 
metadata is returned (i.e. nothing is decrypted). Alternate 'Accept' types may 
then be used to decrypted and return the secret, such as 
'application/octet-stream' from binary secret types, and 'text/plain' for text 
based secrets.

Effectively these are different representations of the same REST-ful secret 
resource, which we believe is an acceptable (no pun intended) use of the 
'Accept' header, but open for further debate.

That said, we did encounter an issue related to the 'Accept-Encoding' request 
header. We had hoped to use this header to indicate if (for example) a binary 
secret should be returned as 'base64' encoded versus raw binary data. We found 
the ability to override this header from default was problematic on Chrome, so 
decided to hold off on this feature for now. Curiously one option discussed was 
to add a '/base64' extension to the URI. Hence this feature could similarly be 
open for debate.

BTW, we do have a Python client library available for interaction with Barbican 
as well: https://github.com/cloudkeep/python-barbicanclient

Thanks,
John








From: Justin Santa Barbara [jus...@fathomdb.com]
Sent: Sunday, September 22, 2013 2:25 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Barbican] MIME types vs path (secrets/{id}/{name})

As part of my project to add a second implementation of the OpenStack API, I'm 
implementing Barbican, and I'm struggling to understand the motivations behind 
the API spec.

The API supports storing multiple secrets under a given key, the canonical 
example for that being SSL keys which comprise a certificate/public key and a 
private key.  That makes sense.

But, to set or retrieve the "sub-secrets", the MIME type of the request is 
used.  'application/json' is special and retrieves the metadata.

Wouldn't it be much easier just to use a path ( i.e. .../secrets/{id}/{name} ), 
rather than using MIME types?  Using MIME types seems very un-RESTy, but I'll 
leave that argument to the REST police :-)

It seems much more complicated to use MIME types, so I'm betting there's a good 
reason.  Can someone from the Barbican team share what those are?

(The API ref I'm looking at is here: 
https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp )

Justin

---

Justin Santa Barbara
Founder, FathomDB
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Havana M3 Release

[John Wood]

Hello folks,

The Barbican team is proud to announce the third milestone delivery with the 
OpenStack project: Havana-3.

This milestone can be found at:

https://launchpad.net/cloudkeep/havana/havana-3/+download/barbican-2013.2.b3.tar.gz

With this milestone, 3 blueprints have been implemented. Here is a quick 
summary of the new features:

  * Added a variety of refinements to the API and crypto plugin contracts.
  * Added PKCS #11 interface support for HSMs, currently operating with 
SafeNet's Luna SA
  * Added Role Base Access Control (RBAC) utilizing 4 roles: admin, creator, 
audit, observer.
  * Added an error reason to 'orders' resource creates that fail asynchronously

More details can be found at: https://launchpad.net/cloudkeep/havana/havana-3,
and here: https://github.com/cloudkeep/barbican/wiki/Release-Notes

An updated Python client library and command line interface for Barbican is 
also available in Pypi here: https://pypi.python.org/pypi/python-barbicanclient/

Thanks to Jarret Raim, Andrew Hartnett, Douglas Sims, Sheena Gregson, John 
Vrbanac, Douglas Mendizabal, Paul Kehrer, Melissa Kam, Arash Ghoreyshi, Malini 
Bhandaru and John Wood for their contributions to this milestone.

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [barbican] Havana M2 Release

[John Wood]

Hello folks,

We are pleased to announce a Havana M2 release for the Barbican key management 
project, as detailed here: https://launchpad.net/cloudkeep/+announcements

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Update on monitoring vs instrumentation?

[John Wood]

Thanks for the update Sandy. 

>From this link (https://github.com/Cerberus98/tach) it seems that Nova is 
>currently using Tach and would thus serve as a good example for us to follow 
>on our project. Do you know if there are other OpenStack projects using Tach 
>currently?

Thanks,
John
 

From: Sandy Walsh [sandy.wa...@rackspace.com]
Sent: Tuesday, July 09, 2013 7:00 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Update on monitoring vs instrumentation?

While StackTach is still under active development and has undergone many 
awesome enhancements since that page was written, we're working on porting it 
all to Ceilometer (CM).

Recently, CM added a UDP Collector, but don't think it's been tested against 
Tach. Tach + statsd + graphite is still a great quick way to get metrics from 
OpenStack, but we hope that CM will be able to do all of that and more.

Hope it helps.
-S
____
From: John Wood [john.w...@rackspace.com]
Sent: Tuesday, July 09, 2013 2:42 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev]  Update on monitoring vs instrumentation?

Hello folks,

I've found this page to be informative in trying to understanding monitoring vs 
instrumentation within OpenStack: 
https://wiki.openstack.org/wiki/UnifiedInstrumentationMetering

It is a bit dated though (from October last year I believe). I was curious if 
it still reflects current trends within OpenStack, especially in regards to 
favoring the use of Ceilometer for monitoring/auditing collection services, and 
the use of Tach/Stacktach feeding into Statsd/Graphite for lower level metrics 
gathering and display?

Thanks,
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Update on monitoring vs instrumentation?

[John Wood]

Hello folks,

I've found this page to be informative in trying to understanding monitoring vs 
instrumentation within OpenStack: 
https://wiki.openstack.org/wiki/UnifiedInstrumentationMetering

It is a bit dated though (from October last year I believe). I was curious if 
it still reflects current trends within OpenStack, especially in regards to 
favoring the use of Ceilometer for monitoring/auditing collection services, and 
the use of Tach/Stacktach feeding into Statsd/Graphite for lower level metrics 
gathering and display?

Thanks, 
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev