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

2013-12-02 Thread Adam Young

On 11/29/2013 10:06 AM, Mark McLoughlin wrote:

Hey

Anyone got an update on this?

The keystone blueprint for KDS was marked approved on Tuesday:

   https://blueprints.launchpad.net/keystone/+spec/key-distribution-server

and a new keystone review was added on Sunday, but it must be a draft
since I can't access it:

https://review.openstack.org/58124

Thanks,
Mark.


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



It was an approach to deploying KDS inside of Keystone but as a separate 
server/running on a different port.  Jamie Lennox was working at the 
same time and has a more mature patch.  His review will be posted 
shortly, and mine can be abandoned.




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


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

2013-12-01 Thread Jarret Raim
 I also don't like that the discussions suggested that because it would be
hard
 to get Barbican incubated/integrated it should not be used. That is just
crazy
 talk. TripleO merged with Tuskar because Tuskar is part of deployment.

We are completing our incubation request for Barbican right now. I am
waiting to send it until tomorrow as I figured it woudn't get a lot of
traction right before the break.

As I've said before, I think the KDS should be part of Barbican, but if
Keystone wants to merge it sooner, I won't complain. Barbican has a pretty
full roadmap through the Icehouse release, so I doubt my team would get to
this. We'd be happy to help anyone interested in implementing it and I would
merge it, but that's up to the authors.

The public / private service argument I don't really get. The KDS will be an
internal server regardless of whether it is in Barbican or Keystone so I
don't think that is a differentiator.

 Seems to me that pulling Barbican into the identity _program_, but still
as its
 own project/repo/etc. would solve that problem.

Not sure I agree here. Key management solves many problems, some of which
are identity problems, but key management is not fundamentally an identity
service.  For example, SSL certificates for services, symmetric key
generation for at rest encryption, etc.

What do we think are the reasons for combining the two efforts?



Jarret



smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-11-30 Thread Clint Byrum
Excerpts from Adam Young's message of 2013-11-25 20:25:50 -0800:
 Back in the Day, Barbican was just one Service of Cloud Keep.  While I 
 would say that KDS belongs in the Cloud Keep, it is not the same as, and 
 should not be deployed with Barbican.  Is it possible to keep them as 
 separate services?  I think that is the right way to go.  Barbican is 
 for the  end users of Cloud, but KDS is not.  Does this make sense?
 

They're doing the same fundamental thing for two different sets of users
with two overlapping use cases. Why would we implement two KDS services
for this?

I also don't like that the discussions suggested that because it would
be hard to get Barbican incubated/integrated it should not be used. That
is just crazy talk. TripleO merged with Tuskar because Tuskar is part of
deployment. 

Seems to me that pulling Barbican into the identity _program_, but still
as its own project/repo/etc. would solve that problem.

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


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

2013-11-29 Thread Mark McLoughlin
Hey

Anyone got an update on this?

The keystone blueprint for KDS was marked approved on Tuesday:

  https://blueprints.launchpad.net/keystone/+spec/key-distribution-server

and a new keystone review was added on Sunday, but it must be a draft
since I can't access it:

   https://review.openstack.org/58124

Thanks,
Mark.


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


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

2013-11-26 Thread Chmouel Boudjnah
On Tue, Nov 26, 2013 at 5:25 AM, Adam Young ayo...@redhat.com wrote:

 Back in the Day, Barbican was just one Service of Cloud Keep.  While I
 would say that KDS belongs in the Cloud Keep, it is not the same as, and
 should not be deployed with Barbican.  Is it possible to keep them as
 separate services?  I think that is the right way to go.  Barbican is for
 the  end users of Cloud, but KDS is not.  Does this make sense?


I think that make sense to say that Barbican is for public and KDS for
internal services and should be kept as different WSGI daemons. If we were
having it in two different projects when assuming barbican graduate it may
end-up more confusing for the end user.

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


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

2013-11-25 Thread Adam Young
Back in the Day, Barbican was just one Service of Cloud Keep.  While I 
would say that KDS belongs in the Cloud Keep, it is not the same as, and 
should not be deployed with Barbican.  Is it possible to keep them as 
separate services?  I think that is the right way to go.  Barbican is 
for the  end users of Cloud, but KDS is not.  Does this make sense?




On 11/25/2013 11:24 AM, John Wood wrote:

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 mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-11-24 Thread Morgan Fainberg
 I hear a concerted effort to get this bootstrapped in Keystone.  We can do
 this if it is the voice of the majority.


 If we do:

 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.

 +1 on spinning up a new service/wsgi


 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.

 I believe that KDS should be discoverable, but I agree that it is not an
end user service, so I am unsure of the best approach wrt the catalog.

The other concern is the library interfacing with KDS (I would assume this
goes into keystoneclient? At least for the time being).


 Once we have it up and running, we can move it to its own service or hand
 off to Barbican when appropriate.

 Are people OK with the current API implementation?  I didn;t see a lot of
 outside comment on the code review, and there were certainly some aspects
 of it that were unclear.

 I think the API is if not ready to go, very close (maybe a single cleanup
revision).  If we are going to do this lets get the spec done ASAP and get
the code in right away so we can get traction on it.  Icehouse milestones
will be coming through fast.  I think it is imminently possible to have
this in the repo and running fairly quickly with concerted effort.

The code might need minor tweaking to conform to the spec if it changes.
But as I recall almost 100% of the back and forth at this point was does it
belong in keystone.


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



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


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

2013-11-24 Thread Dean Troyer
On Sun, Nov 24, 2013 at 1:52 PM, Morgan Fainberg m...@metacloud.com wrote:

 The other concern is the library interfacing with KDS (I would assume this
 goes into keystoneclient? At least for the time being).


I would rather see the client get its own repo, too.  We still need to do
that with the middleware.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2013-11-23 Thread Adam Young

On 11/22/2013 01:49 PM, Mark McLoughlin wrote:

On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:

Russell Bryant wrote:

[...]
I'm not thrilled about the prospect of this going into a new project for
multiple reasons.

  - Given the priority and how long this has been dragging out, having to
wait for a new project to make its way into OpenStack is not very appealing.

  - A new project needs to be able to stand on its own legs.  It needs to
have a reasonably sized development team to make it sustainable.  Is
this big enough for that?

Having it in Barbican (and maybe have Barbican join under the identity
program) would mitigate the second issue. But the first issue stands,
and I share your concerns.

Yes, I agree. It's disappointing that this change of plans looks like
its going to push out the ability of an OpenStack deployment to be
secured.

If this becomes a Barbican API, then we might be able to get the code
working quickly ... but it will still be some time before Barbican is an
integrated project, and so securing OpenStack will only be possible if
you use this non-integrated project.

Mark.


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



I hear a concerted effort to get this bootstrapped in Keystone.  We can 
do this if it is the voice of the majority.



If we do:

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.


Are people OK with the current API implementation?  I didn;t see a lot 
of outside comment on the code review, and there were certainly some 
aspects of it that were unclear.


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

Note that we have lost Simo as a resource for this, so if it is going to 
move forward, we need other members of the community to step forward and 
keep the process going.







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


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

2013-11-22 Thread Thierry Carrez
Russell Bryant wrote:
 [...]
 I'm not thrilled about the prospect of this going into a new project for
 multiple reasons.
 
  - Given the priority and how long this has been dragging out, having to
 wait for a new project to make its way into OpenStack is not very appealing.
 
  - A new project needs to be able to stand on its own legs.  It needs to
 have a reasonably sized development team to make it sustainable.  Is
 this big enough for that?

Having it in Barbican (and maybe have Barbican join under the identity
program) would mitigate the second issue. But the first issue stands,
and I share your concerns.

-- 
Thierry Carrez (ttx)

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


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

2013-11-22 Thread Jarret Raim
On 11/21/13, 7:51 PM, Jamie Lennox jamielen...@redhat.com wrote:


So i've a feeling that this was proposed and dismissed once before. I
don't remember why.

So my concern with barbican is that i'm under the impression that
barbican was going to be an 'overcloud' service. That's a really bad way
of putting it, but it is service and user facing and discovered via the
service catalog. 

This feature will need to be configured at a lower level (runs in
situations without a token) and so we will need to configure the
services to point to an IP for the KDS service.

Why would there be a need for token less authentication? My understanding
of the feature is that each service account would have a KDS key
associated with it. This means that each account would need to
authenticate to Keystone before talking to Barbican. Are there service
accounts that don’t have a keystone account?


Is this an expected deployment of barbican (i can't see why not)?

We certainly could enable this if needed. We already create separate uwsgi
processes for the main and admin apis. We could create another one for the
KDS. I’d rather not do that unless we have to though.


Jarret




Jamie

On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote:
 The Barbican team has been taking a look at the KDS feature and the
 proposed patch and I think this may be better placed in Barbican rather
 than Keystone. The patch, from what I can tell, seems to require that a
 service account create  use a key under its own tenant. In this use
case,
 Barbican can handle the entire exchange and Keystone can just provide
 auth/auth for the process. This would allow for some great additional
 features including guaranteed entropy and additional security through
the
 use of HSMs, auditing / logging, etc.
 
 Barbican is pretty far along at this point and it doesn¹t appear to be a
 huge amount of work to move the patch over as it doesn¹t seem to use any
 Keystone internals.
 
 What would people think about this approach? We¹re happy to help move
the
 patch over and I¹m certainly happy to merge it as it feels like a good
 feature for barbican.
 
 
 
 
 Jarret
 
 
 
 
 
 
 On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote:
 
 Greetings,
 
 I'd like to check in on the status of this API addition:
 
 https://review.openstack.org/#/c/40692/
 
 The last comment is:
 
propose against stackforge as discussed at summit?
 
 I don't see a session about this and from a quick look, don't see notes
 related to it in other session etherpads.
 
 When was this discussed?  Can you summarize it?
 
 Last I heard, this was just being deferred to be merged early in
 Icehouse [1].
 
 This is blocking one of the most important security features for
 OpenStack, IMO (trusted messaging) [2].  We've been talking about it
for
 years.  Someone has finally made some real progress on it and I feel
 like it has been given little to no attention.
 
 I'm not thrilled about the prospect of this going into a new project
for
 multiple reasons.
 
  - Given the priority and how long this has been dragging out, having
to
 wait for a new project to make its way into OpenStack is not very
 appealing.
 
  - A new project needs to be able to stand on its own legs.  It needs
to
 have a reasonably sized development team to make it sustainable.  Is
 this big enough for that?
 
 What's the thinking on this?
 
 [1]
 
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht
ml
 [2] https://review.openstack.org/#/c/37913/
 
 -- 
 Russell Bryant
 
 ___
 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] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

2013-11-22 Thread Mark McLoughlin
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:
 Russell Bryant wrote:
  [...]
  I'm not thrilled about the prospect of this going into a new project for
  multiple reasons.
  
   - Given the priority and how long this has been dragging out, having to
  wait for a new project to make its way into OpenStack is not very appealing.
  
   - A new project needs to be able to stand on its own legs.  It needs to
  have a reasonably sized development team to make it sustainable.  Is
  this big enough for that?
 
 Having it in Barbican (and maybe have Barbican join under the identity
 program) would mitigate the second issue. But the first issue stands,
 and I share your concerns.

Yes, I agree. It's disappointing that this change of plans looks like
its going to push out the ability of an OpenStack deployment to be
secured.

If this becomes a Barbican API, then we might be able to get the code
working quickly ... but it will still be some time before Barbican is an
integrated project, and so securing OpenStack will only be possible if
you use this non-integrated project.

Mark.


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


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

2013-11-21 Thread Adam Young

On 11/21/2013 01:55 AM, Russell Bryant wrote:

Greetings,

I'd like to check in on the status of this API addition:

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

The last comment is:

propose against stackforge as discussed at summit?


Yes, it was discussed in a small group, and not officially.  That 
comment is just a place holder.


Instead of running it in Keystone, it will run in its own service. There 
really is nothing in Keystone that related to KDS, nor the other way 
around.   KDS is Undercloud specific functiojnality (for now) and not 
really appropriate to expose via the Service catalog.


The current thinking is that Pecan (and maybe WSME) and the current code 
base is the correct way to launch it.
Like all our web services, I suggest the production version run via 
mod_wsgi in Apache HTTPD to allow for TLS and X509 Certificate support.


The service/project will still be under the Keystone program (for now, 
we can discuss where it will live long term).  It should be a relatively 
short ramp up to get it deployed.


I know the Barbican folks are interested as well, and I expect they will 
be contributing to make this happen.




I don't see a session about this and from a quick look, don't see notes
related to it in other session etherpads.

When was this discussed?  Can you summarize it?

Last I heard, this was just being deferred to be merged early in
Icehouse [1].

This is blocking one of the most important security features for
OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
years.  Someone has finally made some real progress on it and I feel
like it has been given little to no attention.

I'm not thrilled about the prospect of this going into a new project for
multiple reasons.

  - Given the priority and how long this has been dragging out, having to
wait for a new project to make its way into OpenStack is not very appealing.

  - A new project needs to be able to stand on its own legs.  It needs to
have a reasonably sized development team to make it sustainable.  Is
this big enough for that?

What's the thinking on this?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
[2] https://review.openstack.org/#/c/37913/




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


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

2013-11-21 Thread Jarret Raim
The Barbican team has been taking a look at the KDS feature and the
proposed patch and I think this may be better placed in Barbican rather
than Keystone. The patch, from what I can tell, seems to require that a
service account create  use a key under its own tenant. In this use case,
Barbican can handle the entire exchange and Keystone can just provide
auth/auth for the process. This would allow for some great additional
features including guaranteed entropy and additional security through the
use of HSMs, auditing / logging, etc.

Barbican is pretty far along at this point and it doesn¹t appear to be a
huge amount of work to move the patch over as it doesn¹t seem to use any
Keystone internals.

What would people think about this approach? We¹re happy to help move the
patch over and I¹m certainly happy to merge it as it feels like a good
feature for barbican.




Jarret






On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote:

Greetings,

I'd like to check in on the status of this API addition:

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

The last comment is:

   propose against stackforge as discussed at summit?

I don't see a session about this and from a quick look, don't see notes
related to it in other session etherpads.

When was this discussed?  Can you summarize it?

Last I heard, this was just being deferred to be merged early in
Icehouse [1].

This is blocking one of the most important security features for
OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
years.  Someone has finally made some real progress on it and I feel
like it has been given little to no attention.

I'm not thrilled about the prospect of this going into a new project for
multiple reasons.

 - Given the priority and how long this has been dragging out, having to
wait for a new project to make its way into OpenStack is not very
appealing.

 - A new project needs to be able to stand on its own legs.  It needs to
have a reasonably sized development team to make it sustainable.  Is
this big enough for that?

What's the thinking on this?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
[2] https://review.openstack.org/#/c/37913/

-- 
Russell Bryant

___
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] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

2013-11-21 Thread Adam Young

On 11/21/2013 03:08 PM, Jarret Raim wrote:

The Barbican team has been taking a look at the KDS feature and the
proposed patch and I think this may be better placed in Barbican rather
than Keystone. The patch, from what I can tell, seems to require that a
service account create  use a key under its own tenant. In this use case,
Barbican can handle the entire exchange and Keystone can just provide
auth/auth for the process. This would allow for some great additional
features including guaranteed entropy and additional security through the
use of HSMs, auditing / logging, etc.

Barbican is pretty far along at this point and it doesn¹t appear to be a
huge amount of work to move the patch over as it doesn¹t seem to use any
Keystone internals.

What would people think about this approach? We¹re happy to help move the
patch over and I¹m certainly happy to merge it as it feels like a good
feature for barbican.


I'm ok with it.

I would, however, like to suggest that we work to make the KDS as a 
seperatly runnable service, so that you don't need to run the rest of 
Barbican to get it.   Barbican was originally envisioned as a 
customer/outward facing project, and KDS is internal (primarily), they 
should be runnable at the same time, without getting confused about 
which service they belong in.  Thus, While I would be OK with KDS under 
the Barbican/CloudKeep program, it might not make sense to bundle it 
with the Barbican server.  Using Barbican as a way to bootstrap the 
deployment for the short term is probably OK, though.










Jarret






On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote:


Greetings,

I'd like to check in on the status of this API addition:

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

The last comment is:

   propose against stackforge as discussed at summit?

I don't see a session about this and from a quick look, don't see notes
related to it in other session etherpads.

When was this discussed?  Can you summarize it?

Last I heard, this was just being deferred to be merged early in
Icehouse [1].

This is blocking one of the most important security features for
OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
years.  Someone has finally made some real progress on it and I feel
like it has been given little to no attention.

I'm not thrilled about the prospect of this going into a new project for
multiple reasons.

- Given the priority and how long this has been dragging out, having to
wait for a new project to make its way into OpenStack is not very
appealing.

- A new project needs to be able to stand on its own legs.  It needs to
have a reasonably sized development team to make it sustainable.  Is
this big enough for that?

What's the thinking on this?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
[2] https://review.openstack.org/#/c/37913/

--
Russell Bryant

___
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] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging

2013-11-21 Thread Jamie Lennox
So i've a feeling that this was proposed and dismissed once before. I
don't remember why.

So my concern with barbican is that i'm under the impression that
barbican was going to be an 'overcloud' service. That's a really bad way
of putting it, but it is service and user facing and discovered via the
service catalog. 

This feature will need to be configured at a lower level (runs in
situations without a token) and so we will need to configure the
services to point to an IP for the KDS service. 

Is this an expected deployment of barbican (i can't see why not)?

Jamie

On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote:
 The Barbican team has been taking a look at the KDS feature and the
 proposed patch and I think this may be better placed in Barbican rather
 than Keystone. The patch, from what I can tell, seems to require that a
 service account create  use a key under its own tenant. In this use case,
 Barbican can handle the entire exchange and Keystone can just provide
 auth/auth for the process. This would allow for some great additional
 features including guaranteed entropy and additional security through the
 use of HSMs, auditing / logging, etc.
 
 Barbican is pretty far along at this point and it doesn¹t appear to be a
 huge amount of work to move the patch over as it doesn¹t seem to use any
 Keystone internals.
 
 What would people think about this approach? We¹re happy to help move the
 patch over and I¹m certainly happy to merge it as it feels like a good
 feature for barbican.
 
 
 
 
 Jarret
 
 
 
 
 
 
 On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote:
 
 Greetings,
 
 I'd like to check in on the status of this API addition:
 
 https://review.openstack.org/#/c/40692/
 
 The last comment is:
 
propose against stackforge as discussed at summit?
 
 I don't see a session about this and from a quick look, don't see notes
 related to it in other session etherpads.
 
 When was this discussed?  Can you summarize it?
 
 Last I heard, this was just being deferred to be merged early in
 Icehouse [1].
 
 This is blocking one of the most important security features for
 OpenStack, IMO (trusted messaging) [2].  We've been talking about it for
 years.  Someone has finally made some real progress on it and I feel
 like it has been given little to no attention.
 
 I'm not thrilled about the prospect of this going into a new project for
 multiple reasons.
 
  - Given the priority and how long this has been dragging out, having to
 wait for a new project to make its way into OpenStack is not very
 appealing.
 
  - A new project needs to be able to stand on its own legs.  It needs to
 have a reasonably sized development team to make it sustainable.  Is
 this big enough for that?
 
 What's the thinking on this?
 
 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.html
 [2] https://review.openstack.org/#/c/37913/
 
 -- 
 Russell Bryant
 
 ___
 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