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
  • Allow or Deny Access
  • Expire Access
  • Skip a Workflow Step
  1. Reference
  2. Access Policies

Types of Access Policies

Abbey supports 3 types of policies:

  • Allow or Deny Access

  • Expire Access

  • Skip a Workflow Step

Allow or Deny Access

Policies which allow or deny access to a user can be specified in the policies field of a Grant Kit. For example:

resource "abbey_grant_kit" "abbey_example_kit" {
  name = "Abbey_Example"
  description = <<-EOT
    Grants access to Abbey's Demo Page.
  EOT

  workflow = {
    steps = [
      {
        reviewers = {
          one_of = ["bob@example.com"]
        }
      }
    ]
  }

  policies = [
    { bundle = "github://example-org/example-repo/policies" }
  ]

  output = ...
  }
}

Look at the policies field. The policy bundle specified must pass or Access Requests to this Grant Kit are denied. Policies used this way must use an allow variable such as below.

allow[msg] {
  in_group("Marketing")
  msg := "allow marketing folks"
}

If attributes about a user change and make the policy invalid, then the policy access will be revoked. For example, if a user was granted access in the above policy and then gets moved out of the "Marketing" group, Abbey will revoke access.

Expire Access

Abbey continues to check if policies for a given Access Request are valid. This can let you write access policies which expire access after a certain amount of time. Expiry based policies are also written in an allow Rego variable.

import data.abbey.functions

allow[msg] {
    functions.expire_after("60m")
    msg := "granting access for 60 minutes"
}

The above policy will allow access for 60 minutes, and then fail after 60 minutes. The failure will revoke access.

Skip a Workflow Step

You can also use policies to skip Workflow steps. Look at the following example.

resource "abbey_grant_kit" "abbey_example_kit" {
  name = "Abbey_Example"
  description = <<-EOT
    Grants access to Abbey's Demo Page.
  EOT

  workflow = {
    steps = [
      {
        reviewers = {
          one_of = ["bob@example.com"]
        }
        
        skip_if = [
          { bundle = "github://example-org/example-repo/policies/rbac" }
        ]
      }
    ]
  }

  policies = ...

  output = ...
  }
}

In the example, a review is required from bob@example.com to grant access through this Grant Kit. The review step may be skipped if the policy referred to in the skip_if section passes.

Policies given in a skip_if section must be placed in a skip variable such as below.

skip[msg] {
  in_group("Engineering")
  msg := "skipping review step for engineers"
}

PreviousAccess PoliciesNextPolicy Bundles

Last updated 1 year ago