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
  • Workflow Spec
  • Writing Workflows For Your Grant Kit
  • Add Your Steps
  • For Each Step, Choose a Reviewer Constraint
  • For Each Step, Optionally Add a Workflow Policy
  • Workflow Step Evaluation
  1. Reference
  2. Grant Kits

Workflows

PreviousGrant KitsNextPolicies

Last updated 1 year ago

A Workflow, written natively in using , defines how someone should get access to a Resource.

Workflow Spec

workflow = {
    steps = [
        {
            reviewers = {
                # one_of = ["...", "...", ...]
                # all_of = ["...", "...", ...]
            },
            skip_if = [
                {
                    # bundle = "..."
                    # query = "..."
                }
            ]
        }
    ]
}

Writing Workflows For Your Grant Kit

Workflows are written using the Grant Kit's Workflows DSL as native Terraform HCL code.

Writing Workflows consists of three steps:

Add Your Steps

Example Workflow Step Configurations
// Workflow with a single step.
steps = [
    { ... }
]

// Workflow with 3 steps.
steps = [
    { ... },
    { ... },
    { ... }
]

There's no practical limit to the number of Workflow Steps you can have.

For Each Step, Choose a Reviewer Constraint

Each step must have a Reviewer Constraint that represents how many of the reviewers must approve an access request for the current step to be considered approved overall.

Abbey supports two types of Reviewer Constraints:

  1. one_of: Require only one of the reviewers in the list of reviewers to approve.

  2. all_of: Require all of the reviewers in the list of reviewers to approve.

Example Workflow Step Configurations with Reviewer Constraints
# Workflow with multiple steps.
#
# The first step only requires one out of 3 reviewers to approve.
#
# The second step requires all reviewers (2 out of 2) to approve.
#
# The third step only requires one reviewer to approve, but
# effectively behaves like an `all_of` because there's only
# one reviewer in the list.
steps = [
    {
        reviewers = {
            one_of = ["alice@example.com", "bob@example.com", "carol@example.com"]
        }
    },
    {
        reviewers = {
            all_of = ["dan@example.com", "eve@example.com"]
        }
    },
    {
        reviewers = {
            one_of = ["frank@example.com"]
        }
    }
]

For Each Step, Optionally Add a Workflow Policy

Each step may optionally have Workflow Policies attached to it. Workflow Policies define when or if someone should have their access revoked.

Example Workflow Step Configurations with Reviewer Constraints and Workflow Policies
# Workflow with multiple steps.
#
# The first step has a single Workflow Policy attached.
# If the policy check passes, then the step will be skipped and
# none of the reviewers will be notified to review the access request.
#
# The second step has two Workflow Policies attached.
# Both of these policy checks must pass in order for the step to be skipped.
#
# The third step doesn't have a Workflow Policy.
# This means the step is required and will always be run.
steps = [
    {
        reviewers = {
            one_of = ["alice@example.com", "bob@example.com", "carol@example.com"]
        }
        skip_if = [
            { ... }
        ]
    },
    {
        reviewers = {
            all_of = ["dan@example.com", "eve@example.com"]
        }
        skip_if = [
            { ... },
            { ... }
        ]
    },
    {
        reviewers = {
            one_of = ["frank@example.com"]
        }
    }
]

Workflow Step Evaluation

Abbey runs your Grant Kit Workflows using Abbey's distributed Workflow Engine. Workflows consist of a series of Workflow Steps you configure for an access request for access to be approved.

Workflow Steps are evaluated serially as shown in the following diagram:

This diagram shows a Workflow with two Steps. For each Step, it will:

  1. Evaluate Workflow Policies.

    • If the policies result in a skip = true, then this step will be skipped. As a result, none of the reviewers in the reviewer list will be notified to approve or deny the access request.

  2. Notify reviewers.

    • Each reviewer may contain different notification channels, such as the Abbey App or Slack.

    • The Notification Router will notify reviewers on all of these channels.

  3. Wait for the Reviewer Constraint to be met.

    • If using one_of, then only one reviewer from the list needs to approve for the Step to be considered approved. The Workflow Engine will then advance to the next step.

      • If no one has approved the access request yet and a deny is received from a reviewer, the Workflow Engine will auto-deny the step. This auto-deny will bubble up to the Workflow and result in access being denied overall.

    • If using all_of, then all reviewers from the list must approve for the Step to be considered approved. The Workflow Engine will advance to the next step only after this condition is met.

      • If some, but not all, approvals have been received, and a deny is received from a reviewer, the Workflow Engine will auto-deny the step.This auto-deny will bubble up to the Workflow and result in access being denied overall.

Once all Steps are approved, access will be granted.

.

.

.

Workflows can have one or more steps. Each step is an object that you configure in a list as defined in the .

For more information on how to add Workflow Policies, visit the page.

Each Step must contain a list of reviewers. This is a list of strings that represent someone's .

The list of reviewers are configured with a , either one_of or all_of.

Terraform
HCL
Add your steps
For each step, choose a Reviewer Constraint
For each step, optionally add a Workflow Policy
Workflow Spec
Reviewer Constraint
Primary Identity
Configuring Policies For Your Grant Kit
Workflow Step Evaluation.
Workflow Step Evaluation