[openstack-dev] [keystone] [barbican] Protecting user specific secrets in Barbican

Jarret Raim jarret.raim at RACKSPACE.COM
Thu May 15 15:56:50 UTC 2014


I just spoke with Dolph and he suggested an option that seems to solve the
problem.

In Keystone, projects that belong to domains (or other projects as the
hierarchy work moves forward) can be marked as Private, which will prevent
any role inheritance for users higher in the hierarchy.

This seems to solve the stated use case?

Arvind - does this work for you?


Thanks,
Jarret


From:  Jarret Raim <jarret.raim at rackspace.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Thursday, May 15, 2014 at 11:40 AM
To:  OpenStack List <openstack-dev at lists.openstack.org>
Cc:  "Chan, Tim" <tim.w.chan at hp.com>, "Jones, Brant" <Brant.Jones at hp.com>,
Morgan Fainberg <m at metacloud.com>, "Thyne, Bob" <bob.thyne at hp.com>
Subject:  Re: [openstack-dev] [keystone] [barbican] Protecting user specific
secrets in Barbican

> 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/b89da5d4/attachment-0001.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/b89da5d4/attachment-0001.bin>


More information about the OpenStack-dev mailing list