Skip to main content

Permit.io Best Practices

Follow these guidelines to plan your Permit.io rollout and fit it into your software development lifecycle. None of them is required, but each one saves rework later.

Project Scope​

  • Before you integrate anything, write down your use case and user stories. They tell you the priorities, scale, and data volume your authorization layer needs to handle.
  • Decide which policy authoring interfaces each stakeholder needs: developers, product managers, security teams, and end users.

Modeling your Policies​

Once you know what your authorization layer needs to do and who operates it, model the policies:

  • Start with the policy model closest to your existing authorization logic, and extend it from there.
  • If you're not sure where to start, pick a simpler model such as Multi-Tenant RBAC or ReBAC with a simple hierarchy/direct ownership.
Mapping your Authorization Layer

Follow this step-by-step guide to planning an RBAC implementation and mapping your authorization layer.

Aim for a Quick POC​

  • Once you pick a model, apply Permit to one segment of your application first. You get fine-grained enforcement there without changing the rest of your setup.
  • If you already have an in-house solution, run Permit alongside your current authorization system. For example, run Permit checks in read-only mode and compare its decisions with your existing ones before you switch enforcement over.
  • Keep the first scope small: a side project or a single service in a development or staging environment, before a full deployment in a larger part of your application.

Deployment and Silos​

Consider Projects and Environments​

tip

Each application or major service should correspond to a Permit Project, with deployments (Development, Staging, UAT, Production) matched to specific Permit Environments

Tenants​

  • Use Tenants to isolate users and resources that should only work together. Tenants give you application-level multi-tenancy.
tip

Tenants are most often used to represent distinct B2B accounts

Policy Decision Points (PDPs)​

  • PDPs (policy decision points), the network nodes that answer authorization queries, usually start out as sidecars or as load-balanced containers on services like Fargate, Cloud Run, or Kubernetes (for example EKS).
  • Make sure each PDP is tied to its intended environment through that environment's unique secret key.

Managing Policy SDLC and CI/CD​

SDLC​

  • Use environment-specific access control to control who can change policy at each deployment stage. For example, a product manager can change policy in staging, while only a developer or DevOps engineer can apply those changes to production.

CI/CD Integration​

  • The [create-env](https://api.permit.io/v2/redoc#tag/Environments/operation/create_environment) API can be utilized to create preview environments in your CI/CD pipeline, with access limited during review (for example, only to the developer who opened the pull request).
  • The [copy-env](https://api.permit.io/v2/redoc#tag/Environments/operation/copy_environment) API merges or promotes changes between environments, so they stay consistent.
  • Use the Permit Terraform provider to manage environment baselines and policy changes as code.
  • GitOps lets you review, merge, and roll out policy changes the same way you manage code.

The Right Interfaces for the Right People​

  • Grant Policy Editor access to stakeholders based on their role and technical depth, so non-technical staff can make the changes they own.
  • Grant Permit API and Terraform provider access to the broader developer team for day-to-day operations.
  • Limit GitOps and direct policy-as-code access to the few developers who own the policy code.
  • Use Permit Elements, embeddable UI components, to delegate access control tasks to your end users safely.

Get Help​

Contents

Edit this page

Need help?