Improved UI for managing dynamic permissions
in progress
Guy Berman
Merged in a post:
Dynamic permissions for Catalog
Ervin Varga
In my organization we have entity (software component) champions who are responsible for maintaining the integrity of their components. The component champions sometimes need to manually edit entities in Port. As a Port administrator, I want to have an approval mechanism in place when component champions are making changes in Port entities, to ensure the changes are correct before they are live.
Exactly as described here https://docs.getport.io/create-self-service-experiences/set-self-service-actions-rbac/dynamic-permissions/ but for Catalog.
P.S. This approach (dynamic permissions) is known as ABAC (see https://en.wikipedia.org/wiki/Attribute-based_access_control), a policy based access control.
Guy Berman
marked this post as
in progress
Hila Kashai
Merged in a post:
Better troubleshooting for Dynamic permissions
Matar Peles
Today if you set dynamic permissions for a self-service you don't know what are the results of the queries, and what is the actually result policy of the conditions you define.
Ideally, it would be good to have a playground for testing the evaluation of Dynamic permission queries and conditions
Matan Grady
Merged in a post:
Auth | Action | Policy dry-run
D
Daniel Sinai
Being able to run a dry run on the policies behalf of another user. It will help people debug the policies and troubleshoot to make sure they are on point before releasing them to developers.
Matan Grady
Merged in a post:
UI for Interactive Test/Troubleshooting of Dynamic Permissions in Self Service
R
R
Currently if you are building dynamic permissions in self service actions the only way to test if the permission works is trial and error by attempting to execute the action.
A UI allowing you to interactively test the permissions to is really needed.
This UI would allow you to see the following:
-the result of the query in the policy
-the result of the jq condition evaluation
-the value of any metadata references specified in value fields in the policy or condition (i.e. {{.entity.identifier}})
Matan Grady
marked this post as
exploring
Matan Grady
Ervin Varga what about using self-service actions instead?
You could set up a self-service action that allows only the "champions" to update entities, and set this action with an approval workflow.
Ervin Varga
Matan Grady Thanks for the feedback! I know about his possibility, but it is more of a workaround that would divert users into another UI flow while working with catalog entities. I would like to apply permissions directly at the level of data irrespectively of how people would use the UI. Furthermore, I am seeking for an approach that would ensure proper access to data even via API.
Matan Grady
Ervin Varga: thanks for clarifying. In the option I proposed, it of course involve setting permissions so direct update is not permitted (via API as well), and the only way to update it by using the action (via API or not).
Anyway let's keep this FR open and see if we get additional feedback
Ervin Varga
Matan Grady I have seen that what I was looking for is now in closed beta stage, but only covering read permissions (see https://docs.port.io/build-your-software-catalog/set-catalog-rbac/?permission=read). Are there plans to add Policy feature to "update," too? It would be a natural addition to the dynamic permission system for handling catalog.
Matan Grady
Ervin Varga: the feature you mentioned is now in GA (read permissions fro entities).
And yes, "write"/"update" is indeed in the plans (no specific ETA for now)
Ervin Varga
Matan Grady I would also suggest for Port to update the documentation and introduce the concept of ABAC (see https://en.wikipedia.org/wiki/Attribute-based_access_control) instead of dynamic persmissions. The latter is OK to convey the idea, but ABAC is exactly what we have here, a policy based access control. it would make the documentation more formal. I have also edited my original post to reflect this.