Secret isolation at user/account level
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
- Started by
- Completed by
- Douglas Mendizábal
Related branches
Related bugs
Sprints
Whiteboard
Mock POC in
https:/
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)
