Blog
/
/
Announcing role-based access control
Product News

Announcing role-based access control

Dudi Elhadad
Dudi Elhadad
Dec 28, 2022
Sign up
Download PDF
Product News
Example H2
Example H3

Introduction

‍

Controlling authorizations is at the center of a good internal developer platform implementation. An inability to create granular role-based access control isn’t feasible for any internal developer portal implementation and can even deter adoption of an enterprise-wide internal developer portal.

Role-based access control makes the developer experience better, since it shows what should be possible from a developer point of view and what actions can be taken, as well as the permitted views for the software catalog entities, based on access.

It also alleviates the concerns about exposing sensitive information stored in the internal developer platform. This is one of the reasons Backstage’s RBAC plugin is a paid feature.

When defining what we want to achieve in Port’s RBAC features, we wanted to ensure a no-code experience that is both flexible and simple. The ability to set access control simply and clearly is crucial, since a poor experience of implementing access control means policies and rules are less likely to be implemented and updated, exposing the company to possible vulnerabilities. The simpler it is to create granular access control rules, by role, the likelier it is these will be implemented and complied with.

‍

Our RBAC approach consists of the following:

Users & Team

Port inherits all teams and users from the SSO provider it integrates into.

On top of the derived structure, Port’s admin can create teams in Port, when a certain structure is required.

‍

Admins can perform any operation on the platform.

Moderators can perform any operation on a specific type of asset and related entities.  

Users have read-only permissions and/or permissions to execute certain actions.

‍

Setting the right read & write permissions

Internal developer portals contain a ton of information. We’ve written elsewhere about the sheer breadth of the information contained within the internal developer portal - about cloud assets, CI/CD pipelines, databases, K8s, microservices, secrets and more. While this breadth is important - only a comprehensive software catalog can support a good developer experience, it immediately raises the question of who should read what.

This is why our approach sets permissions at the user level, as well as the team level..

In some cases, the data in the software catalog is managed and modified from the UI by users (for example, changing the owner of a service). Port supports write permissions with an asset type and even specific property granularity level by team or user. 

‍

{{cta_3}}

Setting the right self-service action permissions

Self-service actions within the developer portal are core to its positive impact on the developer experience and to freeing devops from ticketops-led work. Yet these actions allow direct consumption of different resources, from spinning up temporary environments, asking for temporary permissions or scaffolding microservices. In this respect, we set to allow the definitions of policies that not only control who can perform certain self-service actions (or request manual approval) but also limit the amount of such actions (no more than x actions per month for a certain persona).

The granularity of Port’s permissions for self-service actions enables the admin to allow different user inputs by user, according to their proficiency. A good example of this is creating an S3 bucket. A full stack engineer will need to fill out 2 inputs, while a data engineer will probably need more advanced configuration capabilities and with 6 configurable inputs.

‍

Single sign-on and ownership-led permissions

Port integrates with identity provider tools, so that it is aware of the organization’s structure - teams, groups and users - ensuring that each can see what it owns and less of what it doesn’t own (but should be aware of)

‍

The importance of the audit log in the context of RBAC

Port has an audit log that stores every event that occurred within the developer portal, on the different blueprints or entities. It shows modifications, who invoked which developer self-service action, event status and more. It also shows any logs pertaining to how machines interacted with the information in the internal developer portal. 

{{cta-demo}}

Book a demo right now to check out Port's developer portal yourself

Book a demo
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook
{{cyberark}}

Learning from CyberArk - building an internal developer platform in-house

Read more
{{dropdown}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start