Abbey Docs
  • 👋Welcome
  • Getting Started
    • Quickstart
    • Step-by-Step Tutorials
      • AWS: Managing Access to Identity Center Groups
      • AWS: Managing Access to Identity Center Permission Sets
      • AWS: Managing Access to IAM Groups
      • Azure AD: Managing Access to Groups
      • Confluent: Managing Access to Kafka ACLs
      • Databricks: Managing Access to Managed Tables in Unity Catalog
      • Databricks: Managing Access to Groups
      • GitHub: Managing Access to Teams
      • Google Cloud: Managing Access to Groups
      • Google Workspace: Managing Access to Google Groups
      • Kafka: Managing Access to ACLs
      • Okta: Managing Access to Groups
      • Postgres: Managing Access to Roles
      • Snowflake: Managing Access to Tables
      • Tabular: Managing Access to Apache Iceberg Roles
      • Tailscale: Managing Access to ACLs
      • Vault: Managing Access to Groups and Policies
      • Integrating Abbey with Terraform Cloud
      • Using Abbey with Atlantis
      • Using Abbey with Spacelift
    • Starter Kits
  • How Abbey Works
    • How Abbey Works
    • Key Concepts
  • Build a Grant Kit
    • Get a Starter Kit
    • Connect a Repo
    • Create a Grant Kit
    • Link Identities
    • Write Access Policies
    • Deploy Your Grant Kit
    • Request Access
    • Approve or Deny Access Requests
  • Use Cases
    • Time-Based Access
      • Expire After a Duration
      • Expire At a Specific Time
    • Approval Workflows
      • Using a Single Approval Step
      • Using Multiple Approval Steps
      • Conditionally Skip Approval Steps
  • Admin
    • User Roles
    • Sign-in and MFA
      • Sign-in Methods
      • Multifactor Authentication (MFA)
      • Enabling Single Sign-On
    • Sources
      • PagerDuty
      • Directory Sync
    • End User Notifications
    • Manage API Tokens
  • Reference
    • Grant Kits
      • Workflows
      • Policies
      • Outputs
    • Referencing Users and Groups
    • Linking Application Identities into Abbey
      • Why do I need to link application identities?
      • How do I Link Application Identities?
      • Supported Application Identity Types and Schemas
      • Application Data Object
    • Access Policies
      • Types of Access Policies
      • Policy Bundles
      • Inline Policies
      • Helper Functions
      • Policy Examples
    • Terms of Service
    • FAQ
      • Troubleshooting
  • Resources
    • Abbey Labs
    • Terraform Registry
    • GitHub
    • System Status
    • Privacy Policy
    • Logo
Powered by GitBook
On this page
  • What are Access Policies?
  • What is Open Policy Agent?
  • What is Rego?
  • How do I write Policies?
  • Example Policies
  1. Build a Grant Kit

Write Access Policies

PreviousLink IdentitiesNextDeploy Your Grant Kit

Last updated 1 year ago

What are Access Policies?

Access Policies are a way to specify the rules under which a user can get access to a resource.

Access Policies can be of different and be used to allow or deny a request, skip specific workflow steps, or expire access after a certain period of time. For example:

  • Only Engineers can get access to a table containing PII

  • Revoke access after a maximum of 24 hours.

  • Require manager approval unless the request is from someone in Engineering

Policies are written in Rego and run by Open Policy Agent, and Abbey evaluates these policies on your behalf. Policies evaluate to either true or false, and if a policy or set of policies evaluate to false, then a user will not be granted access.

Policies used to evaluate Access Requests are specified inside Abbey Grant Kit Policy blocks.

What is Open Policy Agent?

Open Policy Agent (OPA) is an open source, general-purpose policy engine. Open Policy Agent is used to evaluate policies against structured data to make sure that the data passes the policy checks. OPA evaluates policies specified in Abbey Grant Kits and resolve as true or false when an Access Request is made. Abbey creates a structured data payload based on attributes and other information about a user, which is used as input to Policy Evaluation. On a false evaluation, the policy check fails, and the Access Request is denied.

Learn more about OPA .

What is Rego?

Rego is the Open Policy Agent language. Rego is a declarative language based on the well-known query language of Datalog. Rego is the policy language that Abbey and OPA use to evaluate policies. You can find documentation on the Rego language .

How do I write Policies?

There are two ways to write policies:

  1. Policy Bundles

  2. Inline Policies

Policy Bundles are sets of files that define a Rego package. Policy Bundles allow you to reuse policy code. You can write Policy code once, store it in a Bundle, and refer back to it as many times as you like.

Inline Policies are used for simple policies, which don't require the complexity of multiple files. Inline Policies are specified within the definition of an Abbey Grant Kit and can be used for simple policies which require little Rego code in them.

Policies can also be used to skip steps a workflow. Details about this and the differences between skipping workflow steps and using a policy for approval are found in Types of Access Policies.

More information on writing Policy Bundles can be found in the Policy Bundles. More information on writing Inline Policies can be found in the Inline Policies section.

Example Policies

The Policy Examples section has examples of policies you can use with Abbey.

types
here
here