Target support in barbican policy enforcement
Target support in barbican policy enforcement
Etherpad: https:/
oslo-policy framework provides support for usage of contextual attributes as part of a policy rule. These are the attributes of objects which are referenced (or targeted) by an API call i.e. any object whose id appear in the API call.
Currently barbican only just validates via custom code that credential tenant matches with id provided as part of URI. This in itself is a confirmed bug ( as should be addressed via policy based on requested resource API) and being addressed. But this still does not leverage target support available in policy framework.
Let's say following data is there.
Tenants: tenantA, tenantB and tenantC
Users: user1, user2
tenantA has created secretA1 and secretA2.
tenantB has created secretB1.
user1 can get scoped token for tenantA and tenantC.
Assumption is that user has api specific needed barbican roles.
Case 1:
user1 [tenantA token] : PUT ../{tenantA_
How about following request
user1 [tenantA token] : PUT ../{tenantA_
Case 2: When tenant does not exist in barbican
user1 [tenantC token]: POST ../{tenantC_
Case 3: When requested tenant resource does not match with credential tenant id
user1 [tenantC token] : POST ../{tenantB_
similarly
user1 [tenantC token] : POST ../{tenantA_
This usage of target in policy rule enforcement is applicable for order, secret, container and verification APIs.
Once target data is made available for policy rbac check, then rules are modified to make usage of that e.g.
--- To address Case 1, policy defintion can be as follows ---
"secret:put": "rule:admin or (role:creator and tenant_
In above rule, user with creator role is allowed when user tenant attribute (obtained from token auth) matches with target's , in this case secret, tenant_id.
--- To address Case 2 and Case 3 policy defintion can be as follows ---
"secrets:post": "rule:admin_
...
"uri_tenant_match": "tenant_
...
admin_or_creator": "(role:admin or role:creator) and rule:uri_
In above rules, user with creator role can modify objects where user tenant attribute (obtained from token auth) matches with URI tenant. This kind of policy enforcement also addresses bug https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Arun Kant
- Direction:
- Needs approval
- Assignee:
- Arun Kant
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Started
- Milestone target:
- None
- Started by
- Arun Kant
- Completed by
- Douglas Mendizábal
Related branches
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Adding target support for policy enforcement.
malini-k-bhandaru
Long back when delegated tokens was introduced in Keystone, I thought it would be perfect to work with Barbican. Barbican keys would be accessed via other OpenStack or other services, so need to ascertain validity of service and return key. This would obviate the need to preserve meta data associated with each and every key.
Say a cloud user has a volume or object saved in Swift. They seek to access it via Cinder or Swift respectively. Cinder authenticates the user, establishes they have access to the volume, and if it is an encrypted volume, it is useless without its key, so the user gets the key tool. The same token is used to retrieve the key from Barbican in delegated mode. Sure, logging/audit services could keep track of who and when actually retrieved that key-id. Likewise for Swift object.
Just querying do we really need to bring in all the details of users etc into Barbican?
Advantages of keeping things modular is that federated authentication would be easier to support.
In the context of PKI key-pairs we may want to dis-allow delegation especially with private keys .. assuming that indeed they shall be saved, albeit encrypted, in Barbican.
arunkant: Adding etherpad to have conversation around above comments. https:/
Addressed by: https:/
Adding target support for policy enforcement
