Terraform Providers Explained: AWS, Azure, GCP, Kubernetes and GitLab

Last reviewed: September 2026

Terraform providers are plugins that translate Terraform configuration into API operations for cloud platforms, SaaS products, Kubernetes clusters and other services. A provider defines the resource types and data sources available to a configuration.

Provider, resource and data source#

Declare required providers#

Declare every provider in the terraform block with its registry source address and a reviewed version constraint. Commit the dependency lock file so team and automation runs select consistent provider builds.

Treat the example version constraints as a pattern, not a permanent recommendation. Check the provider release notes and compatibility requirements before choosing versions for a real environment.

Configure the AWS provider#

Configure the Azure provider#

Configure the Google Cloud provider#

Configure the Kubernetes provider#

Configure the GitLab provider#

Initialize providers#

Run initialization after adding or changing provider requirements. Terraform downloads acceptable provider builds, verifies packages and updates the dependency lock file when necessary.

Use provider aliases#

Aliases allow one configuration to use multiple regions, accounts, subscriptions or endpoints for the same provider. Pass the required alias explicitly to resources and modules.

Authenticate providers securely#

• Prefer workload identity, instance roles, managed identities or short-lived federation over static credentials.
• Use environment variables or the platform's standard credential chain when required.
• Store CI/CD secrets in the automation platform's protected secret store.
• Never place access keys, client secrets, private keys or service-account JSON directly in Terraform files.
• Separate credentials and permissions by environment and workload.
• Grant only the API permissions required by the managed resources.

Manage provider versions#

• Use explicit source addresses from the Terraform Registry.
• Set compatible version constraints after testing.
• Commit .terraform.lock.hcl to version control.
• Review release notes before upgrades.
• Run initialization with controlled upgrade behavior in a branch.
• Validate plans in non-production environments before promotion.

Providers inside modules#

Reusable modules should declare provider requirements but generally receive configured providers from the calling module. Avoid embedding environment-specific credentials or assumptions inside reusable modules.

Common mistakes#

• Omitting a provider source or version constraint.
• Ignoring the dependency lock file.
• Hardcoding credentials in configuration or state-adjacent files.
• Using a default provider accidentally when an alias was intended.
• Forgetting initialization after changing provider requirements.
• Upgrading providers without reviewing the execution plan and release notes.
• Confusing a data source that reads an object with a resource that manages it.

Troubleshooting#

• Provider not found: verify the registry source address and network access.
• Configuration not present: confirm the required alias is passed to the module or resource.
• Authentication failed: inspect the active identity and credential chain without printing secrets.
• Unsupported argument: compare the configuration with documentation for the selected provider version.
• Checksum or lock mismatch: investigate the lock file and installation source before changing trust settings.
• Unexpected changes: confirm provider versions, aliases, defaults and imported state.

Official references#

Provider requirements

Provider configuration

Terraform Registry providers