Open Stack

So let me try to summarize our conversations from yesterday.

=== Use Case ===
Assume we have a Domain D which contains a large number of individual users.
Each user in the domain creates a public / private key. This key pair is
later used to establish authentication to services, some not from OpenStack.

=== Challenge ===
All the user specific projects belong to the D Domain. This means that any
user with read permissions on the domain will be able to access the user
specific secrets. As it seems likely that many users will be given domain
read permissions, this violates least privilege by allowing a large number
of users access to secret data that they don't need.

=== Initial Proposal ===
The original proposal was to scope secrets to a composite key of the project
id and the user id from the user who created the secret. There is some
concern from both Keystone and Barbican members that this approach violates
the base assumption that, in OpenStack, the lowest level of authorization is
a project.

=== Open Question ===
My current thinking is that since these keys are user specific and Keystone
owns the user resource in OpenStack, it is starting to feel like this type
of data should more properly be owned by the Keystone service rather than
Barbican. Of course, Keystone could use Barbican for backend storage if
desired.


I'd really like to get some feedback from the Keystone folks on how they
think about this one as, more and more, it's feeling like a problem that
Barbican shouldn't solve.


Thanks,
Jarret


From:  <Tiwari>, Arvind <arvind.tiwari at hp.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Thursday, May 15, 2014 at 8:21 AM
To:  OpenStack List <openstack-dev at lists.openstack.org>
Cc:  "Jones, Brant" <Brant.Jones at hp.com>, "Chan, Tim" <tim.w.chan at hp.com>,
"Thyne, Bob" <bob.thyne at hp.com>, Morgan Fainberg <m at metacloud.com>
Subject:  [openstack-dev] [keystone] [barbican] Protecting user specific
secrets in Barbican

> Barbcan will be used as secret store (or Key Manager) in Open Stack
> deployments. That means users can store any kind for secrets (ssh keys ,
> access keys, password Š..) in Barbican these secrets are not shared secrets.
>  
> In below scenario it seems secrets are not well protected in Barbican
>  
> 1.      Barbican in integrated a OS based cloud deployment.
> 
> 2.      In particular domain there is one (or multiple) project.
> 
> 3.      Users are associated with the project through role (two coworker can
> have same role e.g. creator) or a admin user have higher role.
> 
> 4.      Users have their secrets (ssh keys , access keys, password Š..) for
> services (VMs per users, resources) saved in Barbican.
> 
>  
>  
> Problem
>  
> 1.      Users with the same role or Admin on project can see each other
> secrets which are not a shared secrets.
> 
> 2.      Multiple projects (or project hierarchy) per user just to store
> secrets is not going to help as it will lead to project exposition and
> confusing. At the same time projects are not meant to go 1 to 1 with user.
> 
> 3.      Project hierarchy is also not a good solution as user on top of the
> hierarchy (reseller admin) can inherits role and able to steal the secrets.
> 
>  
>  
> Note, Barbican is designed for secret storage and protection, we need better
> management on secrets in Barbican. We also need better solution to address
> this problem.
>  
>  
> Keystone and Barbican (or interested party) team, can we have a meeting today
> to brainstorm this issue and come up with better solution?
>  
>  
> Thanks
> Arvind  
>  
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140515/e0717595/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5551 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140515/e0717595/attachment.bin>