Target support in barbican policy enforcement

Registered by Arun Kant

Target support in barbican policy enforcement


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_id}/secrets/{secretA1_id} ---> Should have access as user tenant attributes matches with {tenantA_id} in URI.

How about following request
user1 [tenantA token] : PUT ../{tenantA_id}/secrets/{secretB1_id} ---> This should not be allowed even though credential tenant and URI tenant matches. To enforce it correctly, the need is to derive tenant data from target which in this case is secret_id.

Case 2: When tenant does not exist in barbican

user1 [tenantC token]: POST ../{tenantC_id}/orders ---> This should be allowed as tenant in credential matches with URI tenant.

Case 3: When requested tenant resource does not match with credential tenant id

user1 [tenantC token] : POST ../{tenantB_id}/secrets/ ---> Should not be allowed as user tenant attribute is different from {tenantB_id} in URI.
user1 [tenantC token] : POST ../{tenantA_id}/secrets/ ---> Should not be allowed as user tenant attribute is different from {tenantA_id} in URI.

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_id:%(target.secret.keystone_id)s)",

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_or_creator",
"uri_tenant_match": "tenant_id:%(keystone_id)s",
admin_or_creator": "(role:admin or role:creator) and rule:uri_tenant_match",

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

Blueprint information

Arun Kant
Needs approval
Arun Kant
Series goal:
Milestone target:
Started by
Arun Kant
Completed by
Douglas Mendizábal

Related branches



Gerrit topic:,topic:bp/policy-target-support,n,z

Addressed by:
    Adding target support for policy enforcement.

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.

Addressed by:
    Adding target support for policy enforcement


Work Items

This blueprint contains Public information 
Everyone can see this information.