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
  • Before you start
  • Atlantis Setup
  • Step 1: Choose An Atlantis Deployment Type
  • Step 2: Set Up Your GitHub App
  • Step 3: Configure Atlantis Secrets
  • Using atlantis.yaml
  • Using environment variables
  • Step 4: Configure Terraform Provider Credentials
  • Step 5: Set Up a State Backend
  • Wrap up
  • Recommendations
  • Project Structure
  • Atlantis Repo Config
  • Security Best Practices
  • Next Steps
  1. Getting Started
  2. Step-by-Step Tutorials

Using Abbey with Atlantis

PreviousIntegrating Abbey with Terraform CloudNextUsing Abbey with Spacelift

Last updated 1 year ago

Estimated time: ~15 minutes

In this tutorial, you'll learn how to use Abbey with .

Abbey helps you manage the workflows for access requests and approvals, making it easier for people to get access to .

Atlantis is an application for automating Terraform via pull requests. It is deployed as a standalone application into your infrastructure. No third-party has access to your credentials.

By using Abbey and Atlantis together, you can:

  1. Scalably manage your infrastructure access.

  2. Standardize your workflows.

  3. Increase visibility for how and when Terraform changes occur.

Before you start

  1. Create an account.

  2. Have a account.

Atlantis Setup

Setting up Atlantis contains 5 steps:

  1. Step 1: Choose An Atlantis Deployment Type

  2. Step 2: Set Up Your GitHub App

  3. Step 3: Configure Atlantis Secrets

  4. Step 4: Configure Terraform Provider Credentials

  5. Step 5: Set Up a State Backend

Step 1: Choose An Atlantis Deployment Type

Step 2: Set Up Your GitHub App

Make sure to follow instructions on the Atlantis installation screen titled "Visit https://github.com/apps/installation//installations/new to install the app for your user or organization…".

Your connection won't be complete without doing this step.

You will be redirected to GitHub's website to perform the typical OAuth flow. Select repo scopes for your app, then install.

If you miss some of the above steps, you'll see an error when launching Atlantis:

Error: initializing server: error initializing github authentication transport: wrong number of installations, expected 1, found 0

Because you have set up GitHub using Atlantis's native GitHub App setup flow, you won't have to configure webhook secrets and a webhook URL.

Step 3: Configure Atlantis Secrets

You may configure Atlantis Secrets in one of two ways:

  1. Using atlantis.yaml

  2. Using environment variables

Using atlantis.yaml

  1. GitHub App ID

  2. App Key

  3. Webhook Secret

  4. Web Basic Auth

  5. Web Username

  6. Web Password

This is where you can also configure optional configurations such as your Repo Allowlist.

Using environment variables

To do this, you will prefix your variables with ATLANTIS.

Step 4: Configure Terraform Provider Credentials

Now you will configure your Terraform provider credentials.

For each Terraform Provider or Module you have in your repo, you will need to add credentials so Atlantis can make API calls (via the providers) to each of their services.

For example, if you have infrastructure configuration for GitHub, AWS, and Okta, you will need 3 sets of credentials, one for each of those services.

You will add your provider credentials similar to step 3 above, either using the atlantis.yaml or environment variables.

Step 5: Set Up a State Backend

Atlantis by default does not come with a state backend.

Some of the usual options for a state backend are:

  1. AWS S3 to hold state with AWS Dynamo DB for state locking

  2. Terraform Cloud (only for state)

You may use Abbey's HTTP-based state backend for sandbox or prototyping, but it is not recommended for production use at scale.

That's it! Congrats, you have now set up Abbey with Atlantis!

When your users request access to resources in Abbey, a Pull Request will be created on GitHub. Once all policy and workflow checks pass, reviewers will be notified to approve or deny the request.

You can then perform atlantis apply as usual.

After that, you can approve the request on the Abbey App. Abbey will merge the Pull Request.

If your resource has an auto revocation policy, then Abbey will automatically revoke access in which another Pull Request will be created and the same git-based flow will occur, this time undoing the previous access grant.

Recommendations

Project Structure

.
├── LICENSE
├── README.md
├── atlantis.yaml
├── environments
│   ├── prod
│   |   ├── main.tf
│   |   ├── terragrunt.hcl
│   |   └── variables.tf
│   └── staging
|
├── modules
│   ├── <app>
│   │   ├── README.md
│   │   ├── access.tf
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   ├── provider.tf
│   │   ├── variables.tf
│   │   └── versions.tf
│   └── <app>-access
│       ├── README.md
│       ├── main.tf
│       ├── outputs.tf
│       ├── provider.tf
│       ├── variables.tf
│       └── versions.tf
└── policies
    └── soc2
        └── cc1.rego

Atlantis Repo Config

version: 3

projects:
- name: sandbox-atlantis
  branch: /main/
  dir: environments/sandbox-atlantis
  workflow: terragrunt
  autoplan:
    when_modified: ["*.tf"]
    enabled: true

workflows:
  terragrunt:
    plan:
      steps:
        - env:
            name: TERRAGRUNT_TFPATH
            command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"'
        - env:
            # Reduce Terraform suggestion output
            name: TF_IN_AUTOMATION
            value: 'true'
        - run:
            command: terragrunt plan -input=false -out=$PLANFILE
            output: strip_refreshing
    apply:
      steps:
        - env:
            name: TERRAGRUNT_TFPATH
            command: 'echo "terraform${ATLANTIS_TERRAFORM_VERSION}"'
        - env:
            # Reduce Terraform suggestion output
            name: TF_IN_AUTOMATION
            value: 'true'
        - run: terragrunt apply $PLANFILE

Security Best Practices

  1. Atlantis needs to be exposed to GitHub.

    • If via the public internet, configure Basic Auth with a strong password for your Atlantis server.

    • If via VPC, then make sure to have a proxy to relay/route traffic from GitHub to your private/isolated Atlantis server.

  2. Make sure that you properly scope your access to repos specific to Atlantis and have appropriate number of members and member privileges to those repos.

  3. Make sure to configure a webhook secret if using GitHub. This is the way to authenticate Atlantis against GitHub.

  4. Make sure to configure a Repo Allowlist to only repos you want Atlantis to watch. This helps with security scope and scalability as Atlantis will only need to watch a select number of repos.

Next Steps

To learn more about what Resources you can configure, try one of our Step-by-Step Tutorials.

First, follow the official Atlantis docs to for deploying an Atlantis server.

Follow the official instructions to .

Modify your Atlantis server's to configure required configurations, such as:

You may also configure these same configuration variables via .

Example Atlantis config using environment variables.

You must not use file state with Atlantis because .

Wrap up

Hold your sensitive variables in a secrets manager such as , , or AWS (or their Azure and GCP equivalent).

🎉
choose a deployment type
create a GitHub App Using Atlantis
server config
environment variables
Atlantis does not have permanent storage and does not commit it back to version control
Hashicorp Vault
Doppler
Secrets Manager
Atlantis
Abbey
GitHub
Atlantis installation screen.
Note about webhooks from the Atlantis docs.
Page cover image
Resources