[FEAT]: Switching Between PAT and GitHub App Authentication Without Modifying Terraform Code

[twokasa]

Describe the need

Hello,

I'm trying to differentiate between authentication methods: using PAT (Personal Access Token) in my local environment and the GitHub App in the CI environment. However, after adding the app_auth block for the CI setup, I receive an error in the local environment indicating that id, installation_id, and pem_file are not set. Is there a way to toggle between authentication methods without changing the Terraform code?

Thank you for your assistance.

(Note: This message was translated with the assistance of a machine translation tool.)

SDK Version

No response

API Version

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[kfcampbell]

Hi! Unfortunately there is currently no way to do so. That would be an interesting feature to add!

[wheelerlaw]

You can do this by using the GitHub CLI (gh) to authenticate. To do this, leave the provider "github" block empty. Then, make sure you have your local credentials configured by doing gh auth login. In your CI you will need to generate an app installation token from the app's private key. The following is an example if you are using GitHub Actions:

name: CI
on:
  push:
    branches: [main]
jobs:
  apply:
    name: TF Apply
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v3
      - name: Generate app token
        id: generate-app-token
        uses: tibdex/github-app-token@v1.9.0
        with:
          app_id: ${{ vars.YOUR_APP_ID }}
          private_key: ${{ secrets.YOUR_APP_PRIVATE_KEY }}
      - name: Terraform apply
        env:
          GITHUB_TOKEN: ${{ steps.generate-app-token.outputs.token }}
        run: terraform apply -auto-approve

[laughedelic]

Using the app installation token directly is a good workaround when you run Terraform from GitHub actions, but what about using it from Atlantis? Installation token is short-lived, so it can't be used in Atlantis as a static secret, but providing app credentials instead requires having app_auth {} in the code.

A potential solution here without breaking the existing interface or adding new functionality might be to look for app env vars even when there is no empty app_auth {} block, i.e.

provider "github" {}

1. First looks for the GITHUB_TOKEN env var or credentials set by gh auth login as it does now, so existing workflows don't break
2. Then it could check for the GITHUB_APP_ID+GITHUB_APP_INSTALLATION_ID+GITHUB_APP_PEM_FILE trio to use the app authentication (which would work in CI and Atlantis)

I see the docs say

When using environment variables, an empty app_auth block is required to allow provider configurations from environment variables to be specified. See: hashicorp/terraform-plugin-sdk#142

But I don't quite understand the linked issue. How does it work with an empty provider "github" {} and the GITHUB_TOKEN env var, but doesn't work with the three app env vars?
But I think it's still achievable via introduction of new parameters (making the app_auth block redundant)

P.S. Also having empty app_auth {} fails validation:

│ Error: Missing required argument
│ 
│   on provider.tf line 22, in provider "github":
│   22:   app_auth {}
│ 
│ The argument "pem_file" is required, but no definition was found.

[gulzat214]

Hello, is there an update on this ?

[gulzat214]

Hi! Unfortunately there is currently no way to do so. That would be an interesting feature to add!

Hello, do you know there has been any progress made on this issue ?

[laughedelic]

I took a stab at it in #2174

Any feedback and help are appreciated!

[phildier]

for the off chance someone arrives to this thread in the same situation as me, this is how I worked around this for my specific use case.

A little background, we use atlantis to automate our tf in most cases, but we use the terraform-precommit github action to update our tf lock files when needed. as part of this process, the precommit hook does a terraform validate, which fails when there is an empty app_auth {} block. validate seems to only need the environment variables to exist in order to succeed, so we set them to bogus values so they would be available when validate was run and allow it to succeed.

so, if like me you are just needing to run validate in CI, then set the env vars as below to bogus values

export GITHUB_APP_ID=placeholder-do-not-change
export GITHUB_APP_INSTALLATION_ID=placeholder-do-not-change
export GITHUB_APP_PEM_FILE=placeholder-do-not-change

[briceburg]

You can do this by using the GitHub CLI (gh) to authenticate. To do this, leave the provider "github" block empty. Then, make sure you have your local credentials configured by doing gh auth login. In your CI you will need to generate an app installation token from the app's private key. The following is an example if you are using GitHub Actions:

name: CI
on:
push:
branches: [main]
jobs:
apply:
name: TF Apply
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/checkout@v3
- name: Generate app token
id: generate-app-token
uses: tibdex/github-app-token@v1.9.0
with:
app_id: ${{ vars.YOUR_APP_ID }}
private_key: ${{ secrets.YOUR_APP_PRIVATE_KEY }}
- name: Terraform apply
env:
GITHUB_TOKEN: ${{ steps.generate-app-token.outputs.token }}
run: terraform apply -auto-approve

When I try the @wheelerlaw workaround using an empty provider "github" {} block, I get:

│ Error: Error
│ 
│   with provider["registry.terraform.io/hashicorp/github"],
│   on <empty> line 0:
│   (source code not available)
│ 
│ GET https://api.github.com/user: 403 Resource not accessible by integration

So it seems likje a permissions issue on the githuib app being used. Unfortunately https://api.github.com/user is not explicitly listed in https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28 -- only things like https://api.github.com/user/codespaces/*, not plain /user.

I have the following permissions assigned to the app, on all organization repositories, and have tested that tokens generated from it are able to do cross-repository checkouts &c

---

Read access to actions, attestations api, checks, code, commit statuses, issues, metadata, and pull requests
Read and write access to deployments, environments, merge queues, and packages

---

anything missing?