You can configure Digger to use different accounts for

  1. Storing digger specific PR-level locks

  2. Terraform backend configuration

  3. The target infra to plan / apply.

These all can even be different cloud providers - eg digger locks in AWS, state backend in Azure, while managing infra on GCP.

We rely on terraform expecting particular environment variables when authorising with cloud providers.

Let’s consider example where

  1. Digger locks are in one aws account

  2. Terraform state backend in another aws account

  3. Infra is on Azure, terraform is using Managed Service Identity for auth

env:
   DIGGER_AWS_ACCESS_KEY_ID: ${{secrets.DIGGER_AWS_ACCESS_KEY_ID}}
   DIGGER_AWS_SECRET_ACCESS_KEY: ${{secrets.DIGGER_AWS_SECRET_ACCESS_KEY}}
   STATE_ACCESS_KEY_ID: ${{secrets.STATE_AWS_KEY_ID}}
   STATE_SECRET_ACCESS_KEY: ${{secrets.STATE_SECRET_ACCESS_KEY}}
   DEV_ARM_MSI_ENDPOINT: £{{secrets.DEV_ARM_MSI_ENDPOINT}}
   DEV_ARM_SUBSCRIPTION_ID: £{{secrets.DEV_ARM_SUBSCRIPTION_ID}}
   DEV_ARM_TENANT_ID: £{{secrets.ARM_TENANT_ID}}
   DEV_ARM_USE_MSI: £{{secrets.ARM_USE_MSI}}

Then configure variables mapping in digger.yml

projects:
- name: dev
  dir: .
  workflow: dev
workflows:
  dev:
    envs:
      state:
      - name: AWS_ACCESS_KEY_ID
        value_from: STATE_ACCESS_KEY_ID
      - name: AWS_SECRET_ACCESS_KEY
        value_from: STATE_SECRET_ACCESS_KEY
      commands:
      - name: ARM_MSI_ENDPOINT
        value_from: DEV_ARM_MSI_ENDPOINT
      - name: ARM_SUBSCRIPTION_ID
        value_from: DEV_ARM_SUBSCRIPTION_ID
      - name: ARM_TENANT_ID
        value_from: DEV_ARM_TENANT_ID
      - name: ARM_USE_MSI
        value_from: DEV_ARM_USE_MSI
Project Level Roles for AWSTrigger workflow directly