How Abbey Works
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:
The Abbey Terraform Provider that you use to delegate access management to Abbey.
The Abbey Platform contains Abbey's Policy Evaluation Engine and Workflow Engine.
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
In order to automate access management with Abbey, you use the Abbey Terraform Provider and add Grant Kit resources to your existing Terraform setup.
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.
Abbey works well with your preferred Terraform setup, whether it's Terraform natively or using one of the many wrappers such as Terraform Cloud.
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.
To maximize interoperability with other systems, Abbey uses Open Policy Agent (OPA) Policies with rules written in Rego.
Rego rules are written against the Abbey OPA Constraint Framework, which is a minimal version of the OPA Constraint Framework.
Last updated
