**TL;DR** - A Terraform (or [OpenTofu](/learning-center/what-is-opentofu)) provider is the plugin that translates your HCL into API calls — AWS, Azure, GCP, Kubernetes, Datadog, Okta, and hundreds more. - Configuring a provider is two steps: declare it in `required_providers` with a version constraint, then configure auth/region/etc. in a `provider` block. - Pin versions with `~>` (allow patch updates) for stability; never leave a provider unconstrained. - Commit `.terraform.lock.hcl` to git and pre-populate hashes for every platform your team or CI runs on — this is the supply-chain security layer most teams skip. - Never hardcode credentials. Use environment variables locally, IAM roles / managed identities on cloud, and OIDC in [CI/CD](/learning-center/building-robust-terraform-opentofu-pipelines-the-ultimate-ci-cd-guide). - Use provider aliases for multi-region and multi-account work; pass them explicitly via the `providers` argument when calling modules. Terraform providers are the backbone of infrastructure as code, acting as the critical connection between your HCL configuration files and the APIs of cloud platforms, SaaS services, and other infrastructure systems. Understanding how to configure, manage, and version providers effectively is fundamental to building scalable, secure, and reproducible infrastructure. This pillar article provides a complete guide to Terraform provider management, covering everything from basic configuration to advanced patterns and best practices for enterprise environments. Whether you're on Terraform or the open-source [OpenTofu](/learning-center/what-is-opentofu) fork, the configuration model is identical — both use the same provider plugin protocol. ## What Are Terraform Providers? A Terraform provider is a plugin that enables Terraform to interact with specific cloud providers (AWS, Azure, Google Cloud), SaaS platforms, APIs, or any external service with a REST or gRPC interface. The provider configuration tells Terraform how to authenticate and connect to these services. ![Diagram showing the Terraform provider flow from API to SDK to provider plugin to HCL configuration](/images/blog/azurerm-terraform-provider-overview-898fb5d0.png) Without a properly configured provider, Terraform has no way of managing your resources. Each provider plugin adds a set of resource types and data sources that your infrastructure code can then manage. ### Core Provider Responsibilities Providers handle: - **Authentication**: Managing credentials, tokens, and API keys - **API Communication**: Making calls to cloud provider APIs - **Resource Management**: Creating, updating, and destroying infrastructure objects - **Data Source Queries**: Retrieving information about existing infrastructure - **Service-Specific Features**: Handling region/location selection, custom endpoints, and other platform-specific settings ## Provider Blocks and Configuration Configuring providers in Terraform involves two essential steps: declaring the required providers and then configuring them. ### Step 1: Declare Required Providers Provider requirements are defined in the `required_providers` block within the top-level `terraform` block. This tells Terraform where to find each provider and which versions are acceptable. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } azurerm = { source = "hashicorp/azurerm" version = ">= 3.0.0, < 4.0.0" } google = { source = "hashicorp/google" version = "~> 5.0" } } } ``` Each provider entry specifies: - **Local name** (e.g., `aws`): How you reference the provider in your configuration - **Source**: The full address of the provider (format: `[hostname/]namespace/type`) - **Version constraint**: Which versions are compatible with your configuration ### Step 2: Configure the Provider After declaring requirements, configure providers with `provider` blocks. This is where you specify authentication details and default settings. ```hcl # Default AWS provider provider "aws" { region = "us-east-1" # Authentication typically handled via environment variables or IAM roles } # Azure provider provider "azurerm" { features {} } # Google Cloud provider provider "google" { project = "my-gcp-project" region = "us-central1" } ``` ### default_tags and Provider-Level Defaults The AWS provider's `default_tags` block applies a tag set to every taggable resource the provider manages, which makes it the standard home for cost-allocation and ownership tags: ```hcl provider "aws" { region = "us-east-1" default_tags { tags = local.standard_tags } } ``` Two failure modes show up repeatedly in Scalr's support queue, both involving the gap between what's written in the `default_tags` block and what actually lands in `tags_all`. The first is merge-vs-replace semantics. A platform team we worked with at Scalr defined `default_tags { tags = local.standard_tags }` in code — cost-centre, environment, and app-tier tags — while their management platform layered its own default tag on top with duplicate-tag behavior set to "skip". They expected the two layers to merge. Instead, the platform-level tags replaced the code-level block entirely, and the cost-allocation tags vanished from `tags_all` on every resource. If anything in your toolchain injects default tags above the code level, confirm whether the layers merge or replace before you depend on either. The second is expressions inside `default_tags`. One Scalr customer set `Project = var.app_name` and `Environment = var.environment` in the block, and their plans showed the literal strings `"var.app_name"` and `"var.environment"` in `tags_all`, alongside the warning `Could not auto-resolve dynamic AWS default_tags via Terraform; using statically-parsed tags.` Tooling that statically parses provider blocks — cost estimators, tag-policy checkers — cannot resolve variable references the way Terraform itself does. Prefer plain values in `default_tags` where practical, and in any case verify the resolved tags in plan output rather than trusting the source. ### Authentication Best Practices Never hardcode credentials in your configuration files. Instead: 1. **Use Environment Variables**: Set `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, etc. before running Terraform 2. **Use IAM Roles**: In AWS environments, use instance profiles or EKS service accounts 3. **Use Service Accounts**: In GCP and Azure, use service account keys or managed identities 4. **Implement OIDC**: For CI/CD pipelines, use OpenID Connect for short-lived, credential-free authentication 5. **Secrets Management**: Integrate with HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault ## Provider Aliases for Multi-Region and Multi-Account Deployments For scenarios requiring multiple configurations of the same provider, use provider aliases. This is essential for: - Deploying resources across multiple AWS regions - Managing resources in different AWS accounts - Using different API endpoints or authentication methods - Creating resources in multiple cloud providers simultaneously ### Defining Provider Aliases ```hcl # Default provider for us-east-1 provider "aws" { region = "us-east-1" } # Aliased provider for us-west-2 provider "aws" { alias = "west" region = "us-west-2" } # Aliased provider for eu-west-1 provider "aws" { alias = "europe" region = "eu-west-1" } ``` ### Using Aliases in Resources Resources use the default provider unless explicitly specified: ```hcl # Uses default us-east-1 provider resource "aws_instance" "app_east" { ami = "ami-0c55b31ad20f0c502" instance_type = "t3.micro" tags = { Name = "app-east" } } # Uses west alias (us-west-2) resource "aws_instance" "app_west" { provider = aws.west ami = "ami-068f09e03c69f0b76" instance_type = "t3.micro" tags = { Name = "app-west" } } # Uses europe alias (eu-west-1) resource "aws_vpc" "europe_vpc" { provider = aws.europe cidr_block = "10.0.0.0/16" tags = { Name = "europe-vpc" } } ``` ### Passing Aliases to Modules When using modules that require specific provider configurations, pass them via the `providers` argument: ```hcl module "vpc_east" { source = "./modules/vpc" # Uses default provider } module "vpc_west" { source = "./modules/vpc" providers = { aws = aws.west } cidr_block = "10.1.0.0/16" } ``` The child module must declare the provider in its `required_providers` block. ## Provider Requirements and Version Constraints Provider requirements form the foundation of reproducible infrastructure deployments. They ensure that specific provider versions are downloaded and used consistently across all environments. ### Version Constraint Operators Terraform supports several operators for expressing version constraints: | Operator | Description | Example | Effect | | --- | --- | --- | --- | | `=` | Exact version | `= 5.0.0` | Only version 5.0.0 | | `!=` | Exclude version | `!= 5.0.1` | Any version except 5.0.1 | | `>` | Greater than | `> 5.0.0` | Version 5.0.1 and newer | | `>=` | Greater or equal | `>= 5.0.0` | Version 5.0.0 and newer | | `<` | Less than | `< 6.0.0` | Versions before 6.0.0 | | `<=` | Less or equal | `<= 5.10.0` | Version 5.10.0 and earlier | | `~>` | Pessimistic constraint | `~> 5.0.0` | Only rightmost version component increments | ### Pessimistic Constraint Operator The `~>` operator is particularly useful as it balances stability with automatic updates: - `~> 5.0` allows any version in the 5.x series (5.0.0, 5.1.0, 5.9.9) - `~> 5.0.0` allows only patch updates (5.0.0, 5.0.1, 5.0.99) - `~> 5.1.0` allows patch updates starting from 5.1.0 ### Combining Constraints Create complex version ranges by combining constraints with commas: ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0, != 5.5.0" # Allow 5.x except 5.5.0 } azurerm = { source = "hashicorp/azurerm" version = ">= 3.50.0, < 4.0.0" # Range constraint } } } ``` ### Versioning Strategy by Use Case **Pinned versions (critical environments)**: Use exact versions ```hcl version = "5.67.1" # Exact version required ``` **Reusable modules (libraries)**: Use looser constraints for compatibility ```hcl version = ">= 5.0.0" # Specify minimum version only ``` **Root modules (applications)**: Use tight constraints for stability ```hcl version = "~> 5.67.0" # Allow patch updates only ``` ## Dependency Lock Files (.terraform.lock.hcl) The `.terraform.lock.hcl` file is Terraform's critical security and consistency mechanism. Introduced in Terraform 0.14, it records the exact provider versions and cryptographic checksums used in your configuration. ### Why Lock Files Matter Without lock files, `terraform init` would select the latest provider version matching your constraints each time it runs. This creates the "works on my machine" problem where different environments use different provider versions, leading to inconsistent behavior. Lock files solve three critical challenges: 1. **Reproducibility**: Ensures identical provider versions across all deployments 2. **Supply Chain Security**: Verifies provider package integrity through cryptographic checksums 3. **Cross-Platform Consistency**: Enables smooth collaboration across Linux, macOS, and Windows systems ### Lock File Structure A `.terraform.lock.hcl` file has this structure: ```hcl # This file is maintained automatically by "terraform init". # Manual edits may be lost in future updates. provider "registry.terraform.io/hashicorp/aws" { version = "5.38.0" constraints = "~> 5.0" hashes = [ "h1:A2B3C4D5E6F7G8H9I0J1K2L3M4N5O6P7Q8R9S0T1U2V3W4X5Y6Z7A8B9C0D1E2F3", "zh:0573de96ba316d808be9f8d6fc8e8e68e0e6b614ed4d8d11eed83062c9b60714", "zh:37560469042f5f43fdb961eb6c6b7f6e0bccec04c1c7cbf90f5d6d97893e6c3d", # Additional platform-specific hashes... ] } provider "registry.terraform.io/hashicorp/azurerm" { version = "3.85.0" constraints = ">= 3.0, < 4.0" hashes = [ # Hashes for this provider... ] } ``` Each provider block contains: - **version**: The exact provider version selected - **constraints**: The version constraints from your configuration - **hashes**: Cryptographic checksums for provider packages on different platforms ### When Lock Files Are Created and Updated - **Initial creation**: When running `terraform init` for the first time - **During updates**: When running `terraform init -upgrade` or `terraform init` with new providers - **Platform additions**: When Terraform installs a provider on a new OS/architecture combination Lock files are NOT updated during `terraform plan`, `terraform apply`, or `terraform destroy` operations. ### Platform-Specific Hash Management Lock files created on one platform (e.g., macOS) only contain checksums for that architecture. To support multi-platform teams, pre-populate checksums: ```bash terraform providers lock \ -platform=linux_amd64 \ -platform=darwin_amd64 \ -platform=darwin_arm64 \ -platform=windows_amd64 ``` This ensures your lock file works across all team members' development machines and CI/CD pipelines. ### Lock File Best Practices - **Always commit to version control**: Never add `.terraform.lock.hcl` to `.gitignore` - **Review lock file changes**: Treat lock file updates like code changes in pull requests - **Use intentional upgrades**: Only run `terraform init -upgrade` when you explicitly want to update providers - **Pre-populate for multiple platforms**: Especially critical for teams with mixed OS environments - **Separate lock files per configuration**: Each independent Terraform configuration has its own lock file ## Lock File Debugging and Troubleshooting Lock file issues are common, especially in multi-platform and team environments. Understanding how to diagnose and resolve them is essential. ### Checksum Mismatch Errors The most common error: ``` ERROR: Failed to install provider Error while installing hashicorp/null v3.2.4: the current package for registry.terraform.io/hashicorp/null 3.2.4 doesn't match any of the checksums previously recorded in the dependency lock file. ``` **Causes:** - Lock file created on one platform (macOS) used on another (Linux CI/CD) - Provider version constraints updated without updating the lock file - Corrupted local plugin cache - Provider binary tampering (security risk) **Solutions:** **Delete and reinitialize** (last resort): ```bash rm .terraform.lock.hcl terraform init ``` **Upgrade providers intentionally**: ```bash terraform init -upgrade ``` Then commit the updated lock file. **Add checksums for all platforms** (most common fix): ```bash terraform providers lock \ -platform=linux_amd64 \ -platform=darwin_amd64 ``` ### Stale Lock Files **Problem**: Version constraints updated but lock file not refreshed **Solution**: ```bash terraform init -upgrade git add .terraform.lock.hcl git commit -m "Update provider versions" ``` ### Merge Conflicts in Lock Files **Problem**: Multiple developers update different providers simultaneously **Solution**: After resolving the merge conflict, run `terraform init` to validate all entries: ```bash # Manually resolve conflict in .terraform.lock.hcl terraform init git add .terraform.lock.hcl git commit -m "Resolve lock file merge conflict" ``` ## Provider Authentication Patterns Different providers and environments require different authentication approaches. ### Environment Variables The simplest method for development: ```bash # AWS export AWS_ACCESS_KEY_ID="your-key" export AWS_SECRET_ACCESS_KEY="your-secret" # Azure export ARM_CLIENT_ID="your-client-id" export ARM_CLIENT_SECRET="your-secret" export ARM_TENANT_ID="your-tenant-id" # GCP export GOOGLE_CREDENTIALS='{"type": "service_account", ...}' ``` ### Cloud-Native Authentication **AWS IAM Roles** (recommended for EC2, ECS, Lambda): ```hcl provider "aws" { region = "us-east-1" # Automatically uses EC2 instance role credentials } ``` **Azure Managed Identities**: ```hcl provider "azurerm" { features {} # Automatically uses managed identity credentials } ``` **GCP Service Accounts**: ```hcl provider "google" { project = "my-project" # Automatically uses default application credentials } ``` ### OIDC for CI/CD Pipelines The most secure approach for automated deployments. (Note: [Terraform Cloud's free tier was discontinued on March 31, 2026](/learning-center/hcp-terraform-free-tier-is-being-discontinued-what-you-need-to-know) — Scalr and Spacelift offer the same OIDC flow.) ```hcl terraform { cloud { organization = "my-org" hostname = "app.terraform.io" } } provider "aws" { region = "us-east-1" # Terraform Cloud handles OIDC token exchange for short-lived credentials } ``` OIDC removes static credentials, but it moves the failure surface into the IAM trust policy — and trust policies fail in ways that are hard to diagnose from the Terraform side. Two incidents from our own support queue illustrate the patterns to watch for. In the first, an engineer at a customer tidied up what looked like a redundant condition in the trust policy of an IAM role — one role that, undocumented, backed both their state storage and their provider authentication. The two subsystems issue OIDC tokens with different `sub` claim formats: the storage integration's tokens carry a subject like `scalr:account:`, while provider-configuration tokens carry `account::environment:...:workspace:...`. With one of the two `StringLike` patterns removed, every run in the organization failed, surfacing as a pair of errors that look unrelated: `Cannot download the configuration version due to i/o error` from the storage side and `AccessDenied ... Not authorized to perform sts:AssumeRoleWithWebIdentity` from the provider side. The whole org was blocked until both subject patterns were restored. Two lessons: different token issuers within the same platform can use different `sub` formats, and sharing one IAM role across state storage and provider auth without documenting it turns a one-line policy edit into an org-wide outage. In the second, a team in a regulated industry copy-pasted a working commercial-AWS OIDC trust policy into their GovCloud account and got 403s on every assume-role call. GovCloud is a separate AWS partition: it needs its own OIDC identity provider resource registered in that partition, with its own thumbprints and ARNs. A trust policy is a per-partition, per-account artifact, not portable configuration you can lift between accounts. ### Secrets Management Integration For sensitive credentials, integrate with dedicated systems: ```hcl provider "aws" { region = "us-east-1" assume_role { role_arn = "arn:aws:iam::123456789012:role/terraform-role" } } ``` ## Popular Terraform Providers Overview ### AWS (Amazon Web Services) The most widely used provider for cloud infrastructure. ```hcl terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } provider "aws" { region = "us-east-1" } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" tags = { Name = "main-vpc" } } resource "aws_subnet" "main" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "us-east-1a" } ``` See detailed guides: [Top 10 Most Popular Terraform Providers](/learning-center/top-10-most-popular-terraform-providers) and [AWS Provider v6.0: What's Breaking in April 2025](/learning-center/aws-provider-v6-0-whats-breaking-in-april-2025) ### Azure (Microsoft Azure) For managing resources in Microsoft's cloud platform. ```hcl terraform { required_providers { azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } provider "azurerm" { features {} } resource "azurerm_resource_group" "main" { name = "example-resources" location = "East US" } resource "azurerm_storage_account" "main" { name = "examplestg" resource_group_name = azurerm_resource_group.main.name location = azurerm_resource_group.main.location account_tier = "Standard" account_replication_type = "LRS" } ``` ### Google Cloud (GCP) For Google Cloud Platform infrastructure. ```hcl terraform { required_providers { google = { source = "hashicorp/google" version = "~> 5.0" } } } provider "google" { project = "my-gcp-project" region = "us-central1" } resource "google_storage_bucket" "main" { name = "my-unique-bucket-name" location = "US" force_destroy = false } resource "google_compute_instance" "main" { name = "web-server" machine_type = "e2-micro" zone = "us-central1-a" } ``` ### Kubernetes For managing Kubernetes clusters and resources. ```hcl terraform { required_providers { kubernetes = { source = "hashicorp/kubernetes" version = "~> 2.0" } } } provider "kubernetes" { config_path = "~/.kube/config" config_context = "my-cluster" } resource "kubernetes_namespace" "example" { metadata { name = "example-namespace" } } resource "kubernetes_deployment" "example" { metadata { name = "example-deployment" namespace = kubernetes_namespace.example.metadata[0].name } spec { replicas = 3 # ... deployment specification } } ``` ![Kubernetes service distributing traffic across pods created by a Terraform deployment](/images/blog/kubernetes-terraform-provider-f13beb26.png) See detailed guide: [Mastering Kubernetes with Terraform: A Provider Deep Dive](/learning-center/mastering-kubernetes-with-terraform-a-provider-deep-dive) ### Datadog For monitoring and observability infrastructure. ```hcl terraform { required_providers { datadog = { source = "DataDog/datadog" version = "~> 3.0" } } } provider "datadog" { api_key = var.datadog_api_key app_key = var.datadog_app_key api_url = "https://api.datadoghq.com/" } resource "datadog_monitor" "cpu_alert" { type = "metric alert" query = "avg(last_5m):avg:system.cpu.user{*} > 0.9" message = "CPU utilization is high" } ``` ![A Datadog dashboard populated with metrics from Terraform runs executed in Scalr](/images/blog/how-to-use-terraform-or-opentofu-to-manage-datadog-3257a198.png) See detailed guide: [How to Use Terraform or OpenTofu to Manage Datadog](/learning-center/how-to-use-terraform-or-opentofu-to-manage-datadog) ### Okta For identity and access management. ```hcl terraform { required_providers { okta = { source = "okta/okta" version = "~> 4.0" } } } provider "okta" { org_name = var.okta_org_name base_url = "okta.com" api_token = var.okta_api_token } resource "okta_user" "example" { first_name = "John" last_name = "Doe" login = "john.doe@example.com" email = "john.doe@example.com" } ``` See detailed guide: [How to Use the Terraform Okta Provider](/learning-center/how-to-use-the-terraform-okta-provider) ## Best Practices for Terraform Providers in 2026 ### 1\. Version Management and Lock Files - **Always use explicit version constraints**: Never leave providers unconstrained - **Commit lock files to version control**: These should never be ignored - **Pre-populate multi-platform checksums**: Essential for diverse teams - **Document provider updates**: Include context in commit messages and pull requests - **Automate provider updates**: Use scheduled pipelines to test and merge minor/patch version updates ### 2\. Credential and Authentication Security - **Never hardcode credentials**: This is non-negotiable - **Use OIDC for CI/CD**: Eliminate static credentials in automation - **Implement least privilege**: Grant only necessary IAM permissions - **Rotate credentials regularly**: Especially for long-lived API keys - **Separate credentials per environment**: Use different accounts for dev/staging/prod - **Audit credential usage**: Monitor provider authentication and API calls ### 3\. Multi-Provider and Multi-Account Strategies - **Use aliases strategically**: Only when managing distinct configurations of the same provider - **[Separate configurations by environment](/learning-center/managing-multiple-terraform-environments-a-practical-guide)**: Use directory structure (environments/dev, environments/prod) rather than workspaces - **Use IaC platforms for credential management**: Tools like Scalr centralize provider credentials and enforce policies - **Document provider architecture**: Maintain clear diagrams showing which providers manage which infrastructure ### 4\. Module Design with Providers - **Declare required providers in all modules**: Even if inheriting from parent - **Pass aliases explicitly to [modules](/learning-center/terraform-modules-explained)**: Use the providers map in module blocks - **Use provider defaults judiciously**: Only for the primary use case - **Version external modules carefully**: Test provider version compatibility before upgrades ### 5\. Environment Management - **Separate lock files per environment**: Don't share lock files across dev/staging/prod - **Use environment-specific .tfvars**: Parameterize provider configurations - **Implement automated testing**: Validate provider configurations in pipelines - **Plan for disaster recovery**: Ensure provider credentials are secured and backed up ### 6\. Operational Excellence - **Monitor provider API usage**: Track rate limiting and quota consumption - **Document custom provider configurations**: Especially for complex alias setups - **Standardize on approved providers**: Avoid provider proliferation through governance - **Regular provider audits**: Review which providers are in use and if all are actively managed - **Test provider migrations**: Plan upgrades carefully, especially major versions ### 7\. Enterprise Considerations - **Centralize provider credential management**: Use IaC platforms rather than distributed .env files - **Enforce provider version policies**: Use [policy-as-code (OPA)](/learning-center/enforcing-policy-as-code-in-terraform-a-comprehensive-guide) to prevent breaking changes - **Implement approval workflows**: For sensitive provider configurations or multi-account access - **Maintain provider registries**: Consider private registries for internal or vetted providers - **Cross-team coordination**: Document provider ownership and support contacts ## Common Provider Configuration Pitfalls ### Unconstrained Provider Versions **Problem**: Provider blocks without version constraints allow unexpected major version upgrades ```hcl # BAD: No version constraint terraform { required_providers { aws = { source = "hashicorp/aws" # Missing version! } } } ``` **Solution**: Always specify meaningful version constraints ```hcl # GOOD: Explicit version constraint terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" # Allow patch updates only } } } ``` ### Hardcoded Credentials **Problem**: Credentials visible in source code and version control ```hcl # BAD: Never do this provider "aws" { access_key = "AKIAIOSFODNN7EXAMPLE" secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" region = "us-east-1" } ``` **Solution**: Use environment variables or cloud-native authentication ```hcl # GOOD: Credentials from environment provider "aws" { region = "us-east-1" # Uses AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables } # BETTER: Use IAM roles or OIDC provider "aws" { region = "us-east-1" # Automatically uses IAM role credentials } ``` ### Missing Lock Files in Version Control **Problem**: Lock file ignored or not committed, leading to inconsistent provider versions **Solution**: ```bash # Remove from .gitignore if present git rm --cached .terraform.lock.hcl # Commit the lock file git add .terraform.lock.hcl git commit -m "Add Terraform provider lock file" ``` ### Inconsistent Provider Configurations Across Modules **Problem**: Root module configures providers but modules redefine them differently **Solution**: Configure providers only in root modules, have modules declare requirements without configuration ```hcl # In root module provider "aws" { region = "us-east-1" } # In child module terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } } } # No provider block here - inherits from root ``` ### Assuming Provider Credentials Reach Subprocesses **Problem**: Credentials configured in a provider block authenticate the provider plugin — and nothing else. Anything Terraform shells out to, like a `local-exec` provisioner, starts with the runner's own environment and walks the default credential chain from there. A storage team we worked with at Scalr hit this with a `terraform_data` resource running `aws storagegateway update-gateway-information` through `local-exec`. The apply itself succeeded — the provider's assume-role credentials were fine — but the CLI call failed with `AccessDeniedException ... assumed-role/-instance-profile/i-... is not authorized`. The AWS CLI had fallen back to the runner's EC2 instance profile, a completely different identity from the one the provider was using. The same configuration had worked in their lab environment and failed in dev, because the two environments differed in whether assumed-role credentials were exported into the shell. **Solution**: If a provisioner or external script needs the provider's identity, export the assumed-role credentials into the subprocess environment explicitly (for example, via an `assume-role` wrapper that sets `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_SESSION_TOKEN`). Do not assume the provider's auth context leaks downward — it doesn't. ### Confusing Provider Configurations with Input Variables **Problem**: On IaC platforms, a "provider configuration" object attached to a workspace supplies credentials to the provider — it does not populate Terraform input variables. The two are separate delivery mechanisms that happen to carry similar data. A platform team migrating from Terraform Cloud created a GitHub App provider configuration (with `github_app_id`, `github_app_pem_file`, and `github_app_installation_ids`), linked it to their workspace, and every plan failed with `Error: No value for required variable` for all three. A pre-plan dump of the environment confirmed it: no `TF_VAR_*` injection at all, because their module declared those values as input variables, which provider configurations never set. Removing the `app_auth` block from the provider just moved the failure to `401 Requires authentication`. The fix was recreating their old TFC variable-set wiring as workspace and shell variables. **Solution**: Check how each value reaches Terraform. Settings consumed inside a `provider` block can come from a platform provider configuration or environment variables; values declared as `variable` blocks need `TF_VAR_*` environment variables, workspace variables, or `.tfvars` entries. When migrating between platforms, inventory every variable set on the old platform and recreate it through the equivalent mechanism — linking a provider configuration is not a substitute. ## Conclusion Terraform providers are fundamental to infrastructure as code. Mastering their configuration, management, and versioning practices is essential for building stable, secure, and reproducible infrastructure at scale. The key to successful provider management is: 1. **Be intentional** about version constraints and updates 2. **Prioritize security** in credential handling 3. **Maintain consistency** through lock files and clear documentation 4. **Automate** where possible to reduce manual errors 5. **Plan for scale** with multi-account and multi-environment strategies As infrastructure continues to grow in complexity, proper provider management becomes increasingly critical. Whether managing a single provider or orchestrating deployments across multiple clouds and accounts, the practices outlined in this guide will serve as a solid foundation for your infrastructure as code journey. For enterprise organizations managing Terraform at scale, consider IaC management platforms like Scalr that centralize provider credential management, enforce policies, and provide visibility into how providers are configured and used across your entire infrastructure portfolio. * * * > This blog has been verified for Terraform and OpenTofu

Ryan Fee

Articles by Ryan Fee

HashiCorp GPG Key Expired: Fixing Terraform Download Errors

How to Use a MCP Server with Terraform: 6 Prompts for Infrastructure Teams

Selecting a Terraform Cloud Alternative (2026 Guide)

Terraform Modules Explained

Stop Troubleshooting Terraform: How Scalr AI Helps Platform Teams

Terraform Drift Detection and Management: A Comprehensive Guide

Using Checkov with Terraform - Integrations, Features, Examples

What is a Terraform TACO?

What is Terraform?

Terraform Registry: Public vs Private Module Registries Explained

New Feature: Private Module Registry Namespaces

Terraform Outputs: How to with Examples

Terraform Providers: Complete Configuration and Management Guide

Terraform State Files Best Practices

Using the AWS S3 Backend Block in Terraform

Using the AzureRM Backend Block in Terraform

Using the GCS Backend Block in Terraform

Understanding the Terraform ignore_changes Lifecycle Block

Everything you need to know about using Terraform or OpenTofu with Slack

Scalr's MCP Server: The AI Assistant That Does the Heavy Lifting

Introducing Scalr Metrics

November 2025 Release Notes

Scalr Feature - Storage Profiles

New Scalr Feature: Control Tower

Scalr Product Updates - August 2025

Announcing a Simpler, More Transparent Pricing Model

What are Terraform Lock Files

Scalr Product Updates - July 2025

Dynamic Backend Blocks with OpenTofu

Scalr Product Updates - June 2025

How to Share Terraform State

A Guide to Terraform Audit Logs

Product Update: Scalr Federated Environments

Product Updates April 2025: Flexible Storage Options, Federation, and GitOps Workflows

Product Updates May 2025: Scalr OIDC, Improved GitOps Flows, and PR Comment Approval

About the Learning Center

Maintaining Terraform Module Health with Dependabot and Scalr

A beginner's guide to the terraform init command

HCP Terraform Cloud Pricing Review - 2025

Terraform Random Provider

Using Terraform Workspace Prefixes in a Remote Backend

Scalr VSCode Extension for Terraform & OpenTofu

The Terraform & OpenTofu Terralith

How to Use Snyk with Terraform: Securing Your Infrastructure as Code

New Feature: Terraform & OpenTofu Ephemeral Workspaces

Integrating Terraform Events w/ AWS EventBridge

Use local execution mode for free with Scalr

Terraform and OpenTofu Pull Request Comments The Right Way