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
  • How does Abbey work?
  • Configuring a Grant Kit
  • Request Access
  • Grant and Revoke Access
  1. How Abbey Works

How Abbey Works

PreviousUsing Abbey with SpaceliftNextKey Concepts

Last updated 3 months ago

How does Abbey work?

Abbey acts as a companion to your existing infrastructure by automating access management for you. Your employees request access, Abbey collaborates with your infrastructure to provision access, they use the resources, and access is revoked when they're done.

The core of Abbey consists of 3 components:

  1. The Abbey Terraform Provider that you use to delegate access management to Abbey.

  2. The Abbey Platform contains Abbey's Policy Evaluation Engine and Workflow Engine.

  3. The Abbey App for your employees to discover resources and request access and for your security teams to get visibility into identity and access.

The high-level flow of Abbey has 3 stages:

Configuring a Grant Kit

A Grant Kit is a Terraform resource that represents any resource in your infrastructure that you want Abbey to manage for you. You define and configure a Grant Kit for resources, add Access Policies, and deploy normally.

The deploy registers your resources with Abbey and effectively says "Hey Abbey, from this point forward, please manage permissions for these resources for me."

Resources can be arbitrarily granular and point to any resource you want as long as it's available in the Terraform Registry.

Request Access

After registering your resources with Abbey, your employees can discover and request access to them through familiar UI and chat-based experiences.

When someone requests access, Abbey will stage new permissions change in a Pull Request for you. Abbey leverages Pull Requests and Git history to give you secure native capabilities around audit logs and visibility to simplify your compliance story.

Grant and Revoke Access

Once your CI/CD checks pass for the Pull Request, Abbey will start the Grant Kit process for granting access.

First, Abbey will evaluate your Access Policies. If any of these policy checks produce a violation, Abbey will automatically deny the access request for you and close the Pull Request.

If the policy checks pass, then Abbey will trigger your approvals workflow and route notifications to the right reviewers to approve or deny the access request. If anyone denies the request, Abbey will again close the Pull Request for you. If all approval conditions are met, then Abbey will merge your Pull Request and materialize the access changes from the request. At this point, the employee will be able to access the resource.

Once the employee is done using the resource, you can have their access automatically revoked. Revocation can be configured for a number of use cases, such as on-/offboarding for new hires or team changes, on-call rotations, and more.

Abbey's Policy Evaluation Engine is a distributed runtime that continuously evaluates your Revocation Policies. If any of these policies result in a revoke, then Abbey perform the same steps it did for granting permissions, but this time for revoking permissions. Abbey will generate the appropriate change in Terraform and leverage your infrastructure to materialize the revocation changes.

.

.

.

In order to automate access management with Abbey, you use the and add resources to your existing Terraform setup.

Abbey works well with your preferred Terraform setup, whether it's Terraform natively or using one of the many wrappers such as .

To maximize interoperability with other systems, Abbey uses (OPA) Policies with rules written in Rego.

rules are written against the Abbey OPA Constraint Framework, which is a minimal version of the .

Abbey Terraform Provider
Grant Kit
Terraform Cloud
Open Policy Agent
Rego
OPA Constraint Framework
Delegate access
Request access
Grant and revoke access
Requesting access with Abbey.
Delegate access to Abbey using Terraform.
Employees discover and request access.
Abbey automates granting access.
Abbey automates revoking access.
Requesting access with Abbey
Delegate access to Abbey using Terraform
Employees discover and request access
Abbey automates granting access
Abbey automates revoking access