Skip to main content

XKF on Github

As a XKF user you can use both Azure DevOps and GitHub to store your Terraform and GitOps repositories.

In this document we will go through how to use XKF on GitHub focusing on Infrastructure As Code (IAC) using Terraform.

Terraform​

How to run Terraform plan and apply through a GitHub action workflow.

Workflow​

Just like in the Azure DevOps case we have created a basic pipeline for easy use.

Below you can find an example pipeline that uses the Github Actions workflow. Read further down to see how to create the secrets needed to run the pipeline.

You should store this GitHub action in your Terraform repository under .github/workflows/name.yaml

name: terraform_core

on:
  push:
    branches:
      - main
    paths:
      - core/**
  pull_request:
    paths:
      - core/**
  workflow_dispatch:
    inputs:
      OPA_BLAST_RADIUS:
        description: OPA Blast Radius
        required: true
        default: "50"

jobs:
  terraform:
    uses: xenitab/azure-devops-templates/.github/workflows/terraform-docker.yaml@2021.10.1
    with:
      DIR: core
      runs-on: '["self-hosted", "linux"]' # If you do not want to use the default ubuntu-latest
      ENVIRONMENTS: |
        {
          "environments":[
            {"name":"dev"},
            {"name":"qa"},
            {"name":"prod"}
          ]
        }
    secrets:
      AZURE_CREDENTIALS_DEV: ${{ secrets.AZURE_CREDENTIALS_DEV }}
      AZURE_CREDENTIALS_QA: ${{ secrets.AZURE_CREDENTIALS_QA }}
      AZURE_CREDENTIALS_PROD: ${{ secrets.AZURE_CREDENTIALS_PROD }}

Self-hosted runners​

It is currently not possible to use self-hosted runners hosted in GitHub organization X while calling on workflows in GitHub organization Y.

To be able to use self-hosted runners you have to import (not fork) the repository to organization X the workflow repository and make it public. If you do not do this private repositories located in organization X will not be able to find the workflows.

Azure Service Principal​

Create a Service Principal(SP) with the access that Terraform requires to perform all the tasks you want. You can read more about SP creation in our getting started guide

The workflow is using Azure Login GitHub Action to login to Azure. When uploading your SP to GitHub make sure to follow the formatting in the examples.

This is to prevent unnecessary masking of { } in your logs which are in dictionary form.

For example, do:

{"clientId": "00000000-0000-0000-0000-000000000000",
  "clientSecret": "super-duper-secret-value",
  "subscriptionId": "00000000-0000-0000-0000-000000000000",
  "tenantId": "00000000-0000-0000-0000-000000000000"}

instead of:

{
  "clientId": "00000000-0000-0000-0000-000000000000",
  "clientSecret": "super-duper-secret-value",
  "subscriptionId": "00000000-0000-0000-0000-000000000000",
  "tenantId": "00000000-0000-0000-0000-000000000000"
}

Upload the entire JSON as your GitHub secret. The workflow uses one secret per environment and we recommend that you follow our naming standard. The secret name the workflow uses is AZURECREDENTIALS\<ENV>, for example AZURE_CREDENTIALS_DEV.

To upload the secret to GitHub you can use the GitHub UI or you can use the GitHub CLI to upload secrets to GitHub.

Assuming that you are storing the SP JSON data in a file you could do:

gh secret -R ORG/xks-terraform set AZURE_CREDENTIALS_DEV < dev-secrets.json
gh secret -R ORG/xks-terraform set AZURE_CREDENTIALS_QA < qa-secrets.json
gh secret -R ORG/xks-terraform set AZURE_CREDENTIALS_PROD < prod-secrets.json