Workflows

A Workflow, written natively in Terraform using HCL, 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:

1. Add your steps.

2. For each step, choose a Reviewer Constraint.

3. For each step, optionally add a Workflow Policy.

Add Your Steps

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

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 = ["[email protected]", "[email protected]", "[email protected]"]
        }
    },
    {
        reviewers = {
            all_of = ["[email protected]", "[email protected]"]
        }
    },
    {
        reviewers = {
            one_of = ["[email protected]"]
        }
    }
]

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 = ["[email protected]", "[email protected]", "[email protected]"]
        }
        skip_if = [
            { ... }
        ]
    },
    {
        reviewers = {
            all_of = ["[email protected]", "[email protected]"]
        }
        skip_if = [
            { ... },
            { ... }
        ]
    },
    {
        reviewers = {
            one_of = ["[email protected]"]
        }
    }
]

For more information on how to add Workflow Policies, visit the Configuring Policies For Your Grant Kit page.

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:

Workflow Step Evaluation.

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 Step must contain a list of reviewers. This is a list of strings that represent someone's Primary Identity.

   • 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.

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

   • 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.