API implemetation is required to download identity policies
Problem Statement and use case :
In OpenStack Policy is taken care of in either two ways -
a. with policy.json file
b. with oslo.policy
Also projects have started migrating policy to oslo.policy.
In case, when one requires to run identity RBAC tests (Patrole Identity tests ) remotely, for the time being it is not possible.
For this one have to copy respective policy.json manually, to the machine from where tests are being run.
Also in case when policy is being handled within the code (oslo.policy case), There is no suitable way to load policies on the machine from where tests are being run.
Also without policy files and/or remote loading of oslo.policy Patrole tests (RBAC tests) can't be run from remote machine.
Solution:
An API can be implemented in keystone (and for other projects too with different blueprint) for downloading the policy on remote machine. I should be restricted to admin only.
For example - (From remote machine one can run this command)
keystone <os-auth-
If this API is implemented, Patrole framework can load policies(from code or from file) on run time remotely.
In this way all the Patrole tests can be run remotely.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Mh Raies
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Unknown
- Milestone target:
- None
- Started by
- Completed by
- Lance Bragstad
Related branches
Related bugs
Bug #1673417: Patrole framework will always fail when running from remote machine, if policy file are not explicitly on remote machine. | Confirmed |
Sprints
Whiteboard
Related Blueprint in Patrole - (----- Mh Raies)
https:/
https:/
https:/
https:/
https:/
https:/
Gerrit topic: https:/
Addressed by: https:/
API implementation to get policy rules
Addressed by: https:/
API implementation to get policy rules
(lbragstad) 19-02-13: Marking this as obsolete based on the specification feedback [0]. I think continuing the capabilities API discussion can address this use case [1]. If you'd like to continue the discussion around capabilities, please don't hesitate to leave comments in review.
[0] https:/
[1] https:/