Skip to main content
Version: 2.0.0

Permit.io Best Practices

Permit is a full-stack authorization-as-a-service solution that allows you to implement secure, granular, and easy-to-use permission management. Before you get into implementing, here are some guidelines we recommend you follow for smooth integration of Permit into your software development lifecycle. This isn't a must, but these can certainly streamline your work.

Project Scope​

  • Before we start integrating anything, it’s helpful to get a clear understanding of our use case and user story. This way, we will be able to gauge the priorities, scale, and data volume our authorization layer will need to handle.
  • It can be very useful to determine the appropriate policy authoring interfaces required by the different stakeholders in your project (Developers, product managers, security personnel, and end-users).

Modeling your Policies​

Once you've established the basic concept of what your authorization layer needs to do and who should have access to operating it, take a look at the authorization policies themselves:

  • Start with a policy model that best resembles your existing authorization mechanism and enhance it from there.
  • If you're not sure where to start, it’s best to opt for simpler models such as Multi-Tenant RBAC or ReBAC with a simple hierarchy/direct ownership.
Mapping your Authorization Layer

Need help? Check out this step-by-step guide to planning an RBAC implementation and mapping your authorization layer

Aim for a Quick POC​

  • Once you pick the model you would like to implement, it could be useful to select a specific segment of your application to apply Permit. This allows for detailed and fine-grained enforcement without overwhelming your existing setup.
  • If you have an in-house solution in place, consider running Permit alongside your current authorization system for added confidence. This can include operating Permit in a read-only mode to assess its operation without making immediate changes.
  • A PoC with Permit can be set up really quickly - implementing it into a small side project shouldn’t take more than a few minutes and range from a few hours in a development or staging environment to approximately two weeks for a full deployment in a small to medium-sized application segment.

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​

  • Leverage Tenants to isolate users and resources that should only work together. This feature facilitates application-level multi-tenancy.
tip

Tenants are most often used to represent distinct B2B accounts

Policy Decision Points (PDPs)​

  • PDPs, the network nodes responsible for answering authorization queries using policies and contextual data, are usually initially deployed as sidecars or within load-balanced containers using services like Fargate, Cloud Run, or Kubernetes (e.g., EKS).
  • It’s important to ensure each PDP is correctly siloed to its intended environment using its unique secret key.

Managing Policy SDLC and CI/CD​

SDLC​

  • You can implement environment-specific access control to manage who can make policy changes across different stages of deployment. For instance, a product manager may alter policies in the staging environment but would need a developer or DevOps to 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 dynamically preview environments for deployment as part of your CI/CD pipeline, ensuring controlled access during the review process (For example, giving access only to the developer who created the pull-request).
  • The [copy-env](https://api.permit.io/v2/redoc#tag/Environments/operation/copy_environment) API can be used to merge/promote changes between environments, maintaining consistency and efficiency.
  • Consider using the Permit Terraform provider to manage environment baselines and policy changes systematically.
  • Integration with Git allows merging and enforcing policy changes by managing authorization policies just as you would manage code.

The Right Interfaces for the Right People​

  • Policy editor access can be allocated to stakeholders based on their role and technical proficiency. This ensures that non-technical staff and developers with limited requirements can make necessary adjustments without complications.
  • Permit API and Terraform provider access can be granted to the broader developer team, facilitating standard operational tasks.
  • GitOps and direct policy-as-code access should usually be restricted for highly skilled developers, typically a small subset within any organization.
  • Permit’s embeddable UI components can be used to delegate access control functionality to your end users safely.

Never Hesitate to Reach Out​

  • The Permit Slack Community is a great place to get help with planning your implementation, using Permit features, or any other related questions you might encounter. Come say hi!
  • You can always schedule a conversation with our team to get support, ask questions, and get any type of help you might need.
  • Looking for more reading material? The Permit Blog is filled with useful articles, tutorials, and guides available to help you navigate through the complexities of authorization.

Contents