Custom permission policies for Blueprint Entities
complete
P
Pablo Quintana
Now, the only way to assign permissions over an entity is by using owning_teams property and configuring the ownedByTeam: true/false on the blueprint permissions. We would like to define custom teams arrays as properties that can be inherited from relations and assigned granular permissions over entities (just like owning_teams, but being custom properties).
Dudi - Port team
complete
The new
policy
key allows you to grant read
permissions to users using dynamic rules based on Port’s catalog query capabilities, including contextual queries that access the user’s properties and owning teams. This enables advanced permission policies such as:- Only allowing tech leads or department managers to view specific entities.
- Allow developers access to services owned by their team at all times, and to all services while they are currently on call.
Read more here.
Z
Zayne Halsall
Hi Dudi - Port team,
Does this new feature actually complete this request? We were hoping it would solve our issue, which is an inability to control user access to catalogs/entities based on a custom property. But this would include updating as well, because read access can already be controlled to some extent.
If it does solve the request, do we have an ETA on the rest of the entity CRUD operations (i.e. allowing the
policy
key to be used under update, register, delete)?CC: Antara Palit, Adrian Wong
Dudi - Port team
Hi Zayne Halsall
Thank you for the feedback! The scope of this item is indeed for the "read" operation. We see the dynamic permission policy as an integral part of Port, so adding support for the rest of the entities' operations (create, update, and delete) is on our roadmap. There's no exact ETA as of yet, but we would love it if you could add your vote to this item, and we will update there on the progress.
Also, if you could describe your use cases inside the new item, it will be really helpful for us to make sure we consider them when designing these new additions 🙏
Gur Shafriri
We are getting closer to the beta version of this feature.
As part of it, we will:
- Enable the setting of both the propertyandvaluearguments in our search API using dynamic values derived from the User executing the query and the teams to which they belong. This will include referencing custom properties defined in the User/Team blueprint.
- Allow the configuration of policies based on these queries as part of the "read" permission settings for blueprint entities.
Attached is the syntax we have settled on, and we would love your feedback.
The policy shown in the image will display entities according to the following rules:
- Tech leads of the team that owns the entity will always be able to see the entities associated with their team's blueprint.
- Other users will only be able to see entities with the property "language" set to "ts"
Gur Shafriri
planned
We are now planning to add this capabilities to entities permission, by defining custom policies directly in permission configuration.
Gur Shafriri
exploring
C
Constant Young (US)
I would also say to show various views within port where the data ownership could be inherited from multiple places this is crucial to managing that. Think of a developer versus a large portfolio leader where both need access but atm we can only support one or the other.
Matan Grady
Constant Young (US): Thank you for the feedback. We do have the ability today to inherit team ownership from a different component. Can you clarify what else are you looking for?
C
Constant Young (US)
Matan Grady I am looking to have different views of data through dynamic permissions, currently you can only have 1 owning team and my understanding is when you inherit ownership it is not having multiple teams? Are you saying we could have multiple teams have ownership currently?
Gur Shafriri
Constant Young (US)
You can have multiple teams as owners of an entity (either directly or inherited from another blueprint)
That being said, currently you cannot aggregate this list of owners from multiple inheritance path - would you say an option like that will solve the entire usecase described above?
C
Constant Young (US)
I would also say to show various views within port where the data ownership could be inherited from multiple places this is crucial to managing that. Think of a developer versus a large portfolio leader where both need access but atm we can only support one or the other.
Aidan O'Connor
Without this feature, this will be very difficult to implement for very large organizations. The burden of centralized administration is too much, so this will help to delegate smaller aspects of administration
Members of teams should be able to have different access permissions for certain blueprints to help manage this
P
Pablo Quintana
In my mind it would look smth like this:
{
"entities": {
"read": {
"roles": [
"arde_sast_vuln-moderator",
"Admin"
],
"users": [],
"teams": [],
"entityRoles": [
"owning_teams",
"reader_teams" // where reader_teams is a custom blueprint property we assign or mirror
]
},