Resourcely Documentation
LoginSign Up
  • Get Started
    • 🎱What is Resourcely?
    • 👋Why Resourcely
    • 🏃Quickstart
      • Terraform policies integrated into CI
      • Remediate policy violations in existing infrastructure
      • Templates for generating Terraform
      • Glossary
  • Concepts
    • Foundry
      • Create Blueprints with Foundry
      • Creating Guardrails with Foundry
      • lmport Terraform Modules
    • Guardrails
      • Writing your own Guardrails
      • Editing Guardrails
      • Releasing Guardrails
      • Enabling Inactive Guardrails
      • Guardrails in Action
        • 🐱GitHub Actions
        • 🦊GitLab Pipelines
    • Campaigns
      • Get started with Campaigns
      • Creating Campaigns
      • Remediate Resources
      • Campaign Agent
        • State File Support
          • Amazon Simple Storage Service (S3)
          • Google Cloud Storage (GCS)
          • HCP Terraform
          • Spacelift
        • Running Campaigns with GitHub Actions and a Repo-Hosted State File
        • Running Campaigns Locally
    • Blueprints
      • Authoring Your Own Blueprints
      • Using Built-in Resourcely Blueprints
      • Configuring Global Contexts
      • Deep Linking
    • Resources
      • Provisioning Infrastructure
      • Editing Infrastructure
      • Shopping Cart
      • Config Roots and Environments
    • Other Features and Settings
      • Global Values
      • Global Context
      • Metrics
      • Resourcely-cli
      • Resourcely.yaml
      • VCS Proxy
      • Settings
        • User management
        • Company Information
        • Notification Settings
        • Change Management
          • 🐱Connect to GitHub
          • 🦊Connect to Gitlab
        • Generate API Token
    • ✨Production Setup
      • Single Sign-On (SSO)
        • Auth0
        • AWS Single Sign-On
        • Azure AD
        • Google Workspace
        • JumpCloud
        • Okta
        • Omnissa Workspace ONE (formerly VMware)
        • OneLogin
        • Ping Identity
        • Other SAML / OIDC Providers
      • Source Code Management
        • Page
        • 🐱GitHub
        • 🦊GitLab
        • Atlassian Bitbucket
        • Azure Repos
  • Tutorials and guides
    • Remediation Use Cases
      • Apply tags to resources for automating backups
      • Implement centralized logging
    • Blueprints Use Cases
      • Automate Data Pipeline Creation
      • Encryption for GCP
      • AWS Account Factory
      • Streamline and govern AI
      • IAM Factory
      • Cost optimization for FinOps
      • Guardrails for Terraform Modules
    • Using the Resourcely Terraform Provider
      • Setup Resourcely Provider
      • Blueprints
      • Guardrails
      • Global Context
  • Integrate
    • CI/CD & Terraform Runners
      • Atlantis
      • 🐟AWS CodeBuild
      • Azure Pipelines
      • Buildkite
      • CircleCI
      • CloudBees CI
      • Codefresh
      • Digger
      • Env0
      • 🎏GitHub Actions
        • 🐱Local Plan
          • 🐹AWS with OpenID Connect
        • 🐶Terraform Cloud Integration
      • 🦊GitLab Pipelines
      • Harness
      • 🗻HashiCorp Cloud Platform (formerly Terraform Cloud)
      • Jenkins
      • Octopus Deploy
      • Scalr
      • 🌌Spacelift
      • Terramate
      • 🌎Terrateam
    • Cloud Providers
      • 🌨️Amazon Web Services (AWS)
      • 🤓Google Cloud Platform (GCP)
        • Guardrail Gaunlet at Google Cloud Next 2025
      • 💾Microsoft Azure
      • Alibaba Cloud
      • Huawei Cloud
      • IBM Cloud
      • Oracle Cloud Infrastructure (OCI)
      • Tencent Cloud
      • VMware vSphere
    • Developer Portals
      • Atlassian Compass
      • Backstage
      • Cortex
      • Harness IDP
      • Home grown internal developer portals
      • OpsLevel
      • Port
      • Roadie
    • ITSM
      • Atlassian Jira
      • FreshWorks
      • ServiceNow ITSM
      • ZenDesk
    • CSPM
      • Wiz
    • More Terraform Provider Integrations
      • 🚂ConductorOne Provider
      • Databricks Provider
      • Kubernetes Provider
      • 🐕Datadog Provider
      • ❄️Snowflake Provider
Powered by GitBook
On this page
  • AWS role
  • Creating an Identity Provider for GitHub in AWS
  • Configuring the AWS Role
  • Setting Up GitHub Actions
  • Working with multiple AWS accounts
  1. Integrate
  2. CI/CD & Terraform Runners
  3. GitHub Actions
  4. Local Plan

AWS with OpenID Connect

This guide demonstrates how to configure AWS with OpenID Connect role, create permissions, a GitHub Actions workflow, and deploy Terraform code to AWS.

OpenID Connect serves as an identity layer built on the OAuth 2.0 protocol, allowing third-party applications to verify the identity of end-users or, in this context, an AWS role.

AWS role

In AWS, you need to create an identity provider for GitHub and create a role for web identity or OIDC, associating it with the created identity provider.

Creating an Identity Provider for GitHub in AWS

Go to the IAM section -> select Identity Providers, and then create a new one. Choose OpenID Connect as the type and enter the following details:

  • Provider URL: https://token.actions.githubusercontent.com

  • Audience: sts.amazonaws.com

in Provider URL > click on Get thumbprint.

Configuring the AWS Role

Next, create a role by navigating to IAM -> Roles and opting for a new role creation. Choose "Web Identity" for the role type and select the previously created GitHub identity provider. Assign the role the desired permissions. Give the role a name e.g github_action_role .

After the role's creation, add the GitHub repository into the role's trust relationships. This integration is done by modifying the trust relationship's JSON configuration to resemble the following, where the GitHub repository and conditions for its access are specified: Go to Roles > click on the role name github_action_role -> Click on add permissions > Create inline policy -> Select JSON and past the below content. Make sure to replace StringLike with your repo information.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::12345678:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "repo:Resourcely-Inc/scaffolding-github-actions:*"
                }
            }
        }
    ]
}

This setup specifies which GitHub repositories are permitted to assume this AWS role, using a wildcard to include all branches of the example repository.

Setting Up GitHub Actions

To deploy Terraform code to AWS via GitHub Actions, you need to:

  1. Assign Necessary Permissions: The job must have permissions to request the JWT and read the contents for actions like checkout. This is specified in the YAML configuration as:

permissions:
  id-token: write
  contents: read
  1. Configure AWS Credentials in GitHub Actions: Add the aws-actions/configure-aws-credentials action to your GitHub job, specifying the role to assume and the AWS region.

  2. Incorporate Terraform Operations: Include steps for setting up Terraform, initializing, formatting, and deploying the Terraform code within the GitHub Action workflow.

The complete workflow for deploying Terraform code to AWS using OpenID Connect is detailed in a YAML configuration below, including steps for AWS credential configuration, Terraform setup, deployment commands, and Resourcely CLI setup structured to trigger on specific GitHub events.

name: Plan and Apply Terraform

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  id-token: write
  contents: read

jobs:
  terraform:
    name: 'Terraform'
    runs-on: ubuntu-latest
    environment: production

    defaults:
      run:
        shell: bash

    steps:
      - name: Configure aws credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::12345678:role/github_action_role
          aws-region: us-west-2

      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan -out=plan.raw

      - name: Convert the plan to JSON
        id: planToJson
        run: terraform show -json plan.raw

      - name: Save JSON to a file
        uses: fishcharlie/CmdToFile@v1.0.0
        with:
          data: ${{ steps.planToJson.outputs.stdout }}
          output: plan.json

      - name: Upload Terraform Plan Output
        uses: actions/upload-artifact@v2
        with:
          name: plan-file
          path: plan.json

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve -input=false

  resourcely-ci:
    needs: terraform
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Download Terraform Plan Output
        uses: actions/download-artifact@v2
        with:
          name: plan-file
          path: tf-plan-files/

      - name: Resourcely CI
        uses: Resourcely-Inc/resourcely-action@v1
        with:
          resourcely_api_token: ${{ secrets.RESOURCELY_API_TOKEN }}
          resourcely_api_host: "https://api.resourcely.io"
          tf_plan_directory: "tf-plan-files"

Working with multiple AWS accounts

One way to configure this is to use the assume role block of the AWS provider. In each AWS account create a role for Terraform to plan and apply with. This should include any permissions that Terraform will need to create/modify/delete your resources. Additionally add the trust relationship policy so that the github action role can assume the Terraform per-account role.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": <<GITHUB_ACTION_ROLE_ARN>>
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}
PreviousLocal PlanNextTerraform Cloud Integration

Last updated 1 year ago

Optionally, If you are working with resource across AWS accounts, Use the aws provider block to provide credentials to each account.

🎏
🐱
🐹
AWS Provider credential Instructions