More RBAC for admin permissions
complete
N
Nick Amato
I would like more control over what permissions admins can have within the IDP.
For example, some admins can only edit automations, and webhooks, some admins can only edit the data model, or no admins can generate a new org token.
This enables following of least privilege principle.
The "superadmin" role could do anything.
Usecase: Our team is building a pipeline to version control data model changes as JSON, it would be nice if no one can update the data model through UI in our production environment anymore and they can only do it through the pipeline.
Guy Berman
updated the status to
complete
This is live. Team-based and dynamic (context-aware) policies now scope who can build and edit across workflows, scorecards, users, teams, and every blueprint.
Team-based permissions grant access by ownership, only the team that owns a resource can edit it. Dynamic policies go further: they compare any property on the requester against any property on the entity at the moment of the request, so a rule like "only senior engineers can edit production services" or "only the on-call engineer can edit this workflow" works without a static list of names to maintain.
Together, that's covering the core of what this request was asking for: an admin scoped to what their team owns, instead of every admin defaulting to super admin, everything-everywhere access.
Docs: https://docs.port.io/governance/governance-across-pillars/scope-building-permissions-across-teams-and-users
Blog: https://www.port.io/blog/build-in-port-at-scale
This doesn't yet cover scoping platform-level actions like org token generation, or locking blueprint schema edits to IaC only. In addition, we're tracking those separately:
- RBAC on data sources (in progress): https://roadmap.port.io/ideas/p/rbac-on-data-sources
- RBAC for folders: https://roadmap.port.io/ideas/p/rbac-for-folders-1
- Read-only admin permissions: https://roadmap.port.io/ideas/p/read-only-admin-permissions
Flag anything else you need and we'll open a new item.
Guy Berman
Merged in a post:
Support additional granular role permissions
Priya Raghu
Add support for creating and managing additional roles to improve flexibility in permissions.
Guy Berman
updated the status to
in progress
P
Prabhat Kumar
We have different experience level team members supporting the platform and I will like to have my L1/L2 support person to have ReadOnly-Admin so they can see the configs and troubleshoot while not make changes to the system
Guy Berman
updated the status to
exploring
Aidan O'Connor
This is needed for large enterprises with distinct territories that are each subject to different regulations and compliance standards. Enterprises like this tend to allow a few privileged users in each of these territories to be administrators of Port. However, because the administrator role in Port tends to be very permissive, these administrators are able to create, modify, or delete entities in Port that they really should not be permitted to create, modify, or delete. Port's extensive audit log is a good way to know when this has happened, but large enterprises would prefer to prevent it from happening in the first place.
E
Eamon Mason
We have multiple teams building different integrations and automation. We also have a central team that look after some cross-cutting concerns. Although we use IAC in upper environments, and can enforce least privileged access there, teams also need to be able to experiment and try things out in a lower environment without running into eachother.
S
Stephen Clinton
I'd also like this functionality, for example I'd like to allow our Infrastructure team the ability to create self-service actions, but not edit the catalogue manually etc.