Secret isolation at user/account level

Registered by Arvind Tiwari on 2014-02-11

Barbican is responsible to storing secrets on behalf of users (or some kind of identity).
Secrets may be shared resource but not always, Below are some examples

1. API Access key and secret key
2. SSH keys (RSA/DSA)
3. Public/private keypairs
4. Password

Users (identity) don't want to let any body access those secrets unless they want it to expose the secrets to someone.

Currently there is no way Barbican can provide isolation among users secrets, even though Oslo policy engine is capable of providing such isolations.

Reasons for such limitation

1. Our APIs are pretty coarse grained, it only know one id from Keystone (the official OpenStack IAM). That id (keystone_id) maps to keystone project/tenant. Users (or identities) are associated to a project through roles and multiple user can be associated with single project. In that case secrets stored in Barbican scoped to a projects become shared resources.

2. Barbican physical data model is also not capable to holding user id.

minimum, We have to start thinking of updating our data models and APIs to introduce the notion of users along with existing "keystone_id".

Blueprint information

Status:
Complete
Approver:
None
Priority:
Not
Drafter:
Arvind Tiwari
Direction:
Needs approval
Assignee:
Arvind Tiwari
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Douglas Mendizábal on 2014-07-09

Related branches

Sprints

Whiteboard

Mock POC in

https://review.openstack.org/#/c/76375/1/barbican/tests/api/test_resources_policy.py

kfox1111 -
   Our group is most interested in is something like the following:
       * We tag some of our vm's with a piece of metadata "key-groups = [groupa, groupb]"
       * The vendor data plugin retrieves the instance metadata, and gives back a token that can be used to talk to the key server and retrieve files associated with the instances tenant and groups specified in the instances metadata.

This allows us to simply tag a vm as a "webserver" and the webserver can download keys pertaining to the role it has. If another tenant tags their webservers with that group, they get their own keys since they are unique to <tenant>-<group>.

With this setup, it is not enough that a given read only user can see the metadata for an instance in order to download keys. They have to be able to launch an instance and set the metadata flags, making it much more secure then simply putting the keys in userdata, or putting a key allowing the download in the userdata.

This does allow autoscaling of webservers to download the appropriate keys as needed though.

=========

After discussions at the Summit with Keystone, I believe this use case will be handled by Keystone and requires no changes to Barbican. (jdr)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.