Today, we want to dive into the ability to create dynamic permissions in Port for both executing and approving self-service actions. This is a powerful feature that lets you deliver permissions that change based on role, status (e.g. on-call), time of day and more, so that the way your internal developer portal is used and accessed matches any policy you wish to implement. And the best part: dynamic permissions are based on a user-friendly interface, and require no coding.
RBAC in internal developer portals
Role-based access control is used for security reasons, but in a portal it is also used to deliver personalized experiences. It allows you to control who sees what in the software catalog and who can perform or approve self-service actions, and this creates abstractions and personalization on top of security, reducing cognitive load.
RBAC also plays a role in when and how permissions are granted. This post is about how to use dynamic permissions in an internal developer portal, making portal functionality even more powerful.
Why permissions matter more than you think
Permission management is a core capability in an internal developer portal. Let's explore why permissions matter:
- Security and compliance: The use of granular permissions decreases the risk of data breaches and ensures regulatory compliance, by allowing only authorized individuals to access sensitive data and perform critical actions.
- Personalized experiences: Using permissions customizes access according to each user's roles and responsibilities. The side effect is that users only see what they need in the portal, creating abstractions that reduce the amount of “noise” in the portal. For example, members of a specific team will only see their software assets and their associated dashboards. Only actions relevant to their jobs, such as deploying code, viewing logs, or managing environments, will be available to them, making it easier for users to find the information and tools they need to do their jobs effectively.
- Enforcement of company policies: Using permissions you can define and enforce consistent compliance with company policies by incorporating them directly into the workflow rather than maintaining stale wikis that no one looks at. As an example, a policy that requires that only a team lead can deploy a new feature to all-users can become an built-in part of the deployment process, defined and enforced through the use of permissions.
Beyond Static permissions: embracing dynamic permissions
Traditional permissions are static—a user either has access or they don't. However, static permissions may be too rigid for some real-world scenarios. Dynamic permissions, on the other hand, allow access rights to change based on various factors, such as users/teams properties, time of day or even state of a system, and still be compliant with your policies.
Here are two examples:
- Static permissions: Team A members always have the right to deploy Service A to production. If Service A is no longer owned by Team A, an admin would have to manually update the permissions for the service, a time-consuming and error-prone process.
- Dynamic permissions: A member can only deploy to production services that belong to the business unit they are in, with the prerequisite that they have completed mandatory security training.
To enable this level of granularity, context is needed. This means detailed information about:
- users (e.g. their roles, teams, certifications)
- and teams (e.g. their business units, associated services).
This information needs to be verifiable in real-time, ensuring that permissions stay strictly within policy limits.
Examples of how to use dynamic permissions in an internal developer portal
Imagine these scenarios made possible with dynamic permissions in Port:
- Incident Management: On-call engineers can get automatic access to production environments during their shift, but only outside of regular business hours.
- Feature Flags: Only the product manager for a specific service can toggle on a feature flag for a new service.
- Ephemeral Environments: Junior developers (less than a year with the company) can spin up two temporary environments per month. For more, they need their team lead's approval.
- Onboarding: Only members of a specific team can request licenses for certain software types.
- FinOps: Only director-level employees can approve budget overruns.
How does Port make this possible?
Port's dynamic permissions leverage the concept of blueprints, which define the schema of each entity within the catalog. Importantly, in Port, users and teams are also blueprints, allowing you to manage them just like any other resource in your catalog. This provides the flexibility to add custom properties, such as "Business Unit," to users for example.
With this in place, Port's RBAC engine lets you create sophisticated permissions based on these properties. You could define a rule stating, "A user can deploy a service if their 'Business Unit' property matches the 'Business Unit' property of the service”. This mechanism enables a wide range of dynamic permission scenarios, tailored to your unique organizational structure and needs.
Want to try it for yourself? Check out our documentation.
Book a demo right now to check out Port's developer portal yourself
It's a Trap - Jenkins as Self service UI
How do GitOps affect developer experience?
It's a Trap - Jenkins as Self service UI. Click her to download the eBook
Learning from CyberArk - building an internal developer platform in-house
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
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
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.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)