Open Stack

> -----Original Message-----
> From: Jamie Lennox [mailto:jamielennox at redhat.com]
> Sent: 13 June 2014 03:25
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Message level security plans. [barbican]
> 
> On Thu, 2014-06-12 at 23:22 +0000, Tiwari, Arvind wrote:
> > Thanks Nathan for your response.
> >
> > Still not very convinced for two separate service.
> >
> > Keystone authentication is not a mandatory requirement for Barbican,
as
> per design it can work without Keystone authentication. Rest
(temporary
> session key generation, long-term keys ...) are feature gap which can
be
> easily developed in barbican.
> >
> > If Barbican has to store long term keys on behalf of Kite users than
IMO it
> is good to merge these two services. We can develop separate plug-in
to
> achieve KDC (or Kite plug-in). One can have two separate barbican
> deployments one of KDC another for KMS (or may be only one with
> enhanced barbican API).
> >
> > Thoughts?
> 
> I think you're looking at the wrong part of the stack here. Barbican
is a user
> facing component, kite is looking at securing messages between
services
> that are sent over a message bus. They will need to be deployed and
> configured in a completely different manner. The users in this case
are host
> machines.
> 
> I don't think that session key generation is a 'gap' in barbican's
features, I
> think it's very correctly outside of scope. Key generation such as
this is done
> in a very specific format for a very specific use case, and includes a
lot of
> metadata that has no application outside of kite.
> 
> Kite or a KDC plugin, would still need to manage a whole lot of state
around
> services and which services can talk to which other services.
> This is very much outside barbican's scope.
> 
> The only thing that is really common between the two projects is
safely
> storing encrypted keys, and even then a fundamental purpose of
barbican is
> being able to retrieve the keys, which kite should never do. So we
would
> then need to start putting things into barbican to mark these keys as
> special...
> 
> This was discussed at the summit (you were in that room) that when
> appropriate we should look at having an option for kite to use
barbican for
> it's long term key storage and look to extract the secure key storage
> component from barbican (or kite) into a library that can be shared
between
> the two components if feasible.
> 
> In summary, yes they both store keys but the plugin you suggest will
end up
> with the same API surface area as barbican itself, involve a lot of
service
> management that is way outside of barbican's scope, will need to scale
for
> a different reason, will need to be discovered by a different class of
user
> and have different requirements on 'privacy' on keys.
> 
> Why would we want to deal with all that if you would still need
another
> barbican deployment?
> 
> 
> Jamie
> 

I feel that we did a good job of discussing this at the summit and there
was a strong consensus that Kite is very distinct from Barbican, it
fulfils different use cases and operates at a different level of the
stack. To my mind conceptually lumping Kite together with Barbican is as
confusing as throwing it in with keystone because that handles user
credentials, different tools for different jobs.

-Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/16624b58/attachment.bin>