Terraform Provider Credentials Hardcoded
AWS, GCP, or Azure credentials are hardcoded in your .tf files instead of using environment variables or instance roles, committing cloud access keys to version control.
How It Works
Terraform provider configurations need cloud credentials to create infrastructure. The wrong way — hardcoding access_key and secret_key directly in the provider block — commits those credentials to your repo. The right way is to use environment variables (AWS_ACCESS_KEY_ID, etc.) which the provider picks up automatically, keeping credentials completely out of your code.
# BAD: cloud credentials hardcoded in Terraform provider config
provider "aws" {
region = "us-east-1"
access_key = "AKIAIOSFODNN7EXAMPLE" # hardcoded — never do this
secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfi" # visible in git history forever
}# GOOD: provider uses environment variables automatically
provider "aws" {
region = "us-east-1"
# No credentials here — set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
# in your environment, CI secrets, or use an IAM instance role
}Real-World Example
This is the Terraform-specific version of the same mistake developers make with application code. GitHub's secret scanning now alerts on AKIA-prefixed strings in .tf files, but the alert comes after the push — after the credentials are already in git history and potentially in logs.
How to Prevent It
- Never add access_key or secret_key to provider blocks — use environment variables instead
- In CI/CD, store cloud credentials as encrypted pipeline secrets (GitHub Actions Secrets, etc.)
- For AWS, use OIDC federation to let GitHub Actions assume an IAM role without static credentials at all
- Add *.tfvars files that might contain credentials to .gitignore
- Scan your .tf files with tfsec or Checkov as part of your CI pipeline to catch this before merging
Affected Technologies
Data Hogo detects this vulnerability automatically.
Scan Your Repo FreeRelated Vulnerabilities
Terraform State Exposed
criticalYour terraform.tfstate file is committed to your repository or stored in an unencrypted, publicly accessible location — it contains every secret and resource ID in your infrastructure.
Kubernetes Privileged Container
highYour Kubernetes pod runs with securityContext.privileged: true, giving the container full access to the host kernel and effectively bypassing container isolation.
Kubernetes Default Service Account
mediumPods running with the default service account inherit cluster-level RBAC permissions that are often far more powerful than the workload needs, enabling lateral movement if the pod is compromised.
Helm Chart Secrets in Values
highPasswords, API keys, and other secrets are hardcoded directly in Helm values.yaml files, which get committed to version control and exposed to anyone with repository access.