Permit and the SDLC

With developer experience as a first-class citizen, Permit is designed to seamlessly integrate into your software development lifecycle (SDLC) with the smallest distruption possible.

In the following document, we will go over Permit.io components to explain how you should incorporate them into your SDLC.

---

To make the navigation in the Permit platform as easy as possible, this document will separate the platform components into four planes: Application, Configuration, Data, and Enforcement.

Reviewing the Permit entities in each plane, along with the best practices for working with them, will give you a clear picture of how Permit will evolve in the SDLC.

Application

This is the basic plane of the Permit platform, built to best match common product architectures.

Components

• Workspaces/Organizations - the main “namespace” of a Permit account. Usually, an account should have one workspace. In the context of the SDLC, a workspace is the equivalent of a development organization.
• Projects - the products under a workspace. A project can be considered equivalent to a code repository.
• Environment - with the project analogy to a code repository, environments are like branches. Every new Permit project has Production and Development environments by default.
• Members - the Permit platform users, usually the developers, security engineers, and product managers that work on permissions.

info

Behind the scene, Permit is creating a Policy as Code repository for each project, and environments are branches in this repository. You can control these repositories by yourself using the GitOps feature.

Flow

On the SDLC timeline, the application plane is the rarest to change and functions as the most basic building block of the Permit account. The work on the application plan is achievable via the Permit application, GitOps flows, or APIs.

Each project contains a different Configuration of policies, and it is driven by the product requirement, while each environment manages such policies as part of the continuous SDLC of the product.

Example Use Cases

• An engineering leader/product manager is creating a new project for a new application using the UI
• A security engineer that monitors the API/activity log of the platform using a SIEM solution
• A developer uses the API to continuously create environments that match feature branches

Configuration

The configuration plane of Permit is the stateless policy configuration of an application. The most intuitive way to imagine this plane is the code that you would write as part of the product code to configure the permissions in the application.

Components

• Resources - the types of resources that we want to manage permissions on. Every resource contains the possible actions that users might perform on it.
  • Resource relationships - as part of every resource type, there is a possibility to describe its possible relationship to other resources. These relationships help to derive permissions from one resource to others.
• Roles - the user roles of the applications. Roles can be at a system level (for the whole plane), or at a resource level.
  • Role derivations - a possibility to derive a set of role permissions to another role by using relationships.
• Attributes - a configuration of the possible attributes that resources and users could have. Using this configuration could help us define condition sets.
• Condition sets - the ability to build conditions to match users or resources in a set. These conditions use the attribute configuration to configure match conditions.
• Policy - maps between the allow or deny permissions in a combination of resource/role or conditions sets.
• Custom policies - a set of policies as code files that declare policies in a designated policy language (Rego or Cedar). Used mostly in very advanced use cases.
• Data fetchers - a code configuration of the synchronization between data from the application to Permit. This is a very advanced use case and requires connecting OPAL to Permit. Useful for large-scale applications.
• URL Mapping - a possibility to map API URLs to resources. This feature allow developers to seamlessly integrate API layers to product policies.

Flow

Managing the configuration plane entities of the Permit platform is achievable via the following methods:

• UI - the most recommended method, as you can allow non-developer product stakeholders to work easily on permissions configuration.
• Infrastructure as code - the best method for everything as code organizations. It lets you manage the configuration via Permit terraform provider as an integral part of your SDLC.
• Raw Policy as code - the most advanced method of using Permit, is managing the policy directly via Rego or Cedar files in git repositories. This is suitable for use-cases where the product requirements do not meet the Permit UI policy editor capabilities.

tip

It is a good practice to mix between the methods. For example, use the UI as a source of truth for product RBAC/ReBAC requirements and have manual custom policy code for more complex or Deny All rules.

Example Use Cases

• A product manager/technical leader using the Permit platform to model a fine-grained authorization model
• A developer is using Terraform to declare the application baseline policies
• A security engineer is writing policy as code policies to audit least-privileged general rules

Data

As the configuration plane defines the application's authorization layer from the product requirement perspective, the data plane is where the application data evolves in policy decisions.

Components

• Users - the users of the configured applications. Usually, these users are synced to Permit from the application Identity Provider (authentication) platforms.
  • Attributes - can help in evaluating policy decisions that involve user attributes. It is not necessary to sync the user attributes in advance, as they can be used as part of the Enforcement plane.
• Tenants - sets of users that can be separated in the policies. A tenant can also be considered as an OU in more traditional IAM terms or as Accounts in some cloud-native architectures.
• Role assignments - the relationship between users and their roles. Can also declare a relationship between a user and a specific resource instance.
• Resource instances - a mirror representation of the application objects. Usually, only the id of a resource is needed to represent it in the policy.
• Relationship tuples - declaration of relationships between single instances. The tuples create a graph of relationships that can help in deriving permissions between users and resources.

Flow

In the SDLC, the data is continuously synced to Permit, mostly in API calls. The application and configuration planes allow users to use production data in some environments and mock data in testing/staging environments.

Managing the data in the Permit platform can be achieved in the following ways:

• API/SDK - the most intuitive and comfortable way to sync the data to Permit is to integrate one of our SDKs (or call the APIs directly) from the application code. Keeping the source of every data in Permit in the application code ensures it’s tied to the SDLC in its best form.
• UI - All the data in Permit can also be configured via the Permit admin application to allow the best experience for all the product placeholders. In production environments, such UI operations should be considered carefully.
• Policy engine APIs - for advanced syncing of data, and using the OPAL/Permit architecture, data fetchers can be used to synchronize the data automatically to Permit policy engines. It is also possible to call the policy engine APIs directly, but it is less recommended to keep one source of truth for the policy data.

Example Use Cases

• A developer configures an action that will sync every user from the identity provider to Permit
• A security engineer is using the data in the policy engine to audit policy decisions
• A product manager configures data via the UI to test the policy configuration with real data
• A developer is mocking data in a development environment to test the policy configuration
• An application user assign role to another user via the product UI that calls the Permit APIs

Enforcement

With all other planes in place, the most dynamic plane in Permit is where the application enforces the configured policy and makes the correct decisions within the applications.

Components

• Check function - the main function to get allow / deny decisions within the applications. The Check function receives the following four entities as part of the decision context:
  • User - a user ID and (optionally) a set of user attributes
  • Action - the operation the user is trying to perform
  • Resource - a resource type or ID, and (optionally) a set of resource attributes
  • Context - any extra data that can be used in evaluating the policy decision
• Data filtering - a function that assists the application in filtering data based on policy evaluation. It usually gets the context of such a decision. Data filtering is currently supported only with custom policy code.
• Local PDP APIs - a set of functions to fetch data from the local policy engine to assist applications in making decisions.

Flow

In the SDLC, enforcement is the piece of an application code that controls what users can or cannot perform within the applications.

Using the enforcement plane in Permit is achievable via one of the Permit SDKs or by directly calling the policy decision point.

Example Use Cases

• A developer is using the Permit SDK to check if a user can perform an action on a resource
• A developer is using the Permit SDK to filter data based on the policy evaluation