Skip to main content

Port RBAC capabilities overview

This page provides a comprehensive summary of all of Port's RBAC capabilities, and links to their associated documentation pages. They are grouped into 3 key topics:

1 - Catalog RBAC & Ownership

2 - RBAC for Self Service Actions

3 - RBAC for operating the Port platform

Catalog RBAC & Ownership​

Hide & show catalog pages dynamically​

With Port, you can offer a personalized experience for the various personas of your organization.

For instance, you can create:

  • A unique Costs dashboard only visible to team leaders.
  • A deep-dive view of services for developers.
  • A security dashboard & catalog view for security teams.


To achieve this, you can assign user or team ownership permissions to the various personas logging in to Port.
To configure who can see which pages, refer to the Page Permissions page.

Configuring team ownership​

Port offers various features to provide personalized views such as “show me my team’s services” or “my pull requests”.

team meta property​

Every entity in Port has a meta property called $team, which stores the Port team that the entity belongs to.
The $team property as well as other meta properties are documented here.

Port Team and Identity provider​

Port teams are automatically fetched from your identity provider when connecting to SSO. So the Port Team options will be coming from the Port Teams available under Users and teams settings.

Team inheritance​

To simplify the setup of ownership, Port supports team inheritance. Team inheritance lets you to utilize relations to automatically retrieve Port Teams from a parent entity.

In the example below, we can configure a Port Team for every service:



When configuring team inheritance in Pull Requests, every Pull Request will inherit its parent Port team.



For more details, see the Team Inheritance documentation.

Dynamic team filtering​

Once the team ownership is properly configured we can create dynamic filtering, and show users personalized views such as “my open Pull Requests” or “my team’s services”. We can also lock views to prevent a user from seeing services that are outside of his/her team’s scope.

My Team filter & Lock page view​

By using the My Teams filter you will only see entities that belong to one of your teams. This means you will only see entities from teams that you are a member of.



You may “Save this view” to permanently keep the filters.
For more details about view customization, see the customization documentation.

Initial filters to filter out teams or advanced queries​

Another way to personalize a view is to use initial filters. These allow you to create advanced and dynamic filters, invisible to "regular" users.

With initial filters you can create views such as:

  • Filter all entities owned by My Team or my Business Unit or Department.
  • Filter entities based on dates (e.g. PRs created in the last 90 days).

Leveraging teams as blueprints, we can create advanced business logics, such as services belonging to a specific product:



To achieve this, you can use the relatedTo dynamic filters, for example:

{
  "operator": "relatedTo",
  "blueprint": "githubTeam",
  "value": ["{{getUserTeams()}}"]
}

Port also offers additional dynamic properties and advanced queries:

Dynamic filters for dashboard widgets​

Advanced filters and dynamic filters are also available for dashboard widgets in your catalog or homepage, using the same logic as described in the Initial Filters section above.

You can create widgets with data based on the logged in user’s properties (email, team, etc.).

RBAC for Self Service Actions​

Self Service permissions​

When creating/editing self-service actions, you can set permissions for who can trigger or approve an action.



For more details about action permissions, see the relevant documentation.

Dynamic permissions for Self Service actions​

Port allows setting dynamic permissions for executing and/or approving execution of self-service actions, based on any properties/relations of an action's corresponding blueprint.

Potential use-cases:

  • Ensure that action executions requested by a team member can only be approved by his/her direct manager.
  • Perform validations/manipulations on inputs that depend on data from related entities.
  • Ensure that only those who are on-call can perform rollbacks of a service with issues.

Dynamic permissions for RBAC can run any query on the Port data model.

For more details about dynamic permissions, see the relevant documentation.

RBAC for operating the Port platform​

Port administration roles​

Port supports 3 role types:

RoleDescription
AdminCan perform any operation on the platform.
Moderator of a BlueprintCan perform any operation on a specific blueprint and its entities. A user can be a moderator of multiple blueprints.
MemberHas read-only permissions + permissions to execute actions.
Configurable permissions

The roles above have configurable permissions that are described in the following section. It is possible to have multiple moderator roles, allowing highly granular permission management across the developer portal.

In addition to the permissions designated for each role, permissions are also inherited based on the following hierarchy: Admin > Moderator > Member.

For more details about Port roles, see the relevant documentation.

Blueprint permissions​

Blueprint permissions allow a granular configuration of the various roles: admin, member or blueprint collaborator. You can decide, for example, that a member has edit permissions for a specific Blueprint but not for another.

For more details about Blueprint permissions, see the relevant documentation.