RFE: Token returns Project's tag properties
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Won't Fix
|
Wishlist
|
Yang Youseok |
Bug Description
From an operator perspective, there are many situations where you need to add an ACL for each project. Currently, keystore and openstack policies do not seem to have any fine-grained APIs for project-specific privilege control.
For specific, if we want to restrict some network resources per projects we have to assign neutron's rbac_policy which enable to map specific project with network sources rather than using oslo.policy.
I found that if we can handle project's extra properties in policy code, developer can check the custom properties for their own ACL logic which can be added by oslo.policy. There is already enough required code in keystone codebase for returning token with project extra property, IMHO it can be added without major changes.
Thanks in advance.
tags: | added: rfe |
Changed in keystone: | |
status: | Incomplete → New |
summary: |
- [RFE] Token returns Project's extra properties + [RFE] Token returns Project's tag properties |
Changed in keystone: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
summary: |
- [RFE] Token returns Project's tag properties + RFE: Token returns Project's tag properties |
It is highly recommended that "extras" not be used. If we could do away with them, we would (with exception of the API-Contract that requires us to maintain them). These attributes are poorly implemented and it is not easy to unwind them. As is the current behavior it is not possible to unset them (behavior that must be maintained). Another concern is any/all extras could be eaten / lost if a similar column is added to the project model. It is impossible to know what operators/deployers have named the "extra" values. There are also concerns about typos leading to useless data / un-removable data without direct DB modification.
Would a vendor-specific location e.g. project[ 'vendor_ attributes' ] (or similar) where similar data could be placed (and a None would unset) be usable? We could discuss adding such values into the token response.
As it stands, I am against passing the "Extra" values into the token response. Use of extras should be discouraged as implemented today.