Hey everyone 👋
If you’ve just started using Terraform with AWS, it’s tempting to hardcode your AWS access key and secret key directly into your Terraform config.
I get it — it’s easy, fast, and seems to work fine. But here’s the deal: hardcoding credentials is one of the fastest ways to accidentally leak sensitive info, especially if you push your code to GitHub. And yes, people do this all the time 😬
In this post, I’ll walk you through the secure, production-grade way to authenticate Terraform with AWS — and explain why it matters 👇
🚫 Don’t Do This:
provider "aws" {
region = "us-east-1"
access_key = "AKIAXXXXXXXX"
secret_key = "abcd1234XXXX"
}
This works, but:
- Your keys are exposed in plaintext
- Anyone with access to your repo (or terminal history) can misuse them
- If uploaded to a public repo, AWS will detect it and auto-disable them (yes, really)
Instead, let’s do this the right way 👇
✅ Do This Instead: Use the AWS CLI + Credential Files
The best way to handle credentials is to:
- Install the AWS CLI
- Run
aws configure
to set your credentials securely - Let Terraform automatically pick them up from the standard credential location
Step-by-step:
# Step 1: Install AWS CLI
aws --version # make sure it's installed
# Step 2: Configure credentials
aws configure
You’ll be prompted to enter:
- AWS Access Key
- AWS Secret Key
- Default Region (e.g. us-east-1)
AWS CLI will then store your credentials in:
~/.aws/credentials
~/.aws/config
✅ These are the default files Terraform looks for. So now your provider block can be super clean:
provider "aws" {
region = "us-east-1"
}
No credentials in code. No secrets in Git. Safe and simple.
🔐 Where Terraform Looks for Credentials (In Order)
Terraform checks for AWS credentials in this order:
Environment variables
AWS_ACCESS_KEY_ID
andAWS_SECRET_ACCESS_KEY
Shared credentials file
(~/.aws/credentials
and~/.aws/config
)EC2 instance profile / IAM role
If you're running Terraform on an EC2 or CloudShell with a roleExplicit
access_key
andsecret_key
in code
(not recommended)
You should prefer 2 or 3. Option 1 is useful in CI/CD pipelines. Option 4 is a last resort.
🧠 Why This Approach Is Better
Approach | Secure? | Team-Friendly? | CI/CD-Ready? |
---|---|---|---|
Hardcoded keys in code | ❌ | ❌ | ❌ |
AWS CLI credentials | ✅ | ✅ | ✅ |
Environment variables | ✅ | ✅ | ✅ |
EC2 IAM Roles | ✅ | ✅ | ✅ |
✅ Keeps your code clean
✅ Avoids secret leaks
✅ Works in team setups and production pipelines
💡 Bonus: Switching Profiles (Multiple AWS Accounts)
If you use multiple AWS accounts, define profiles in your AWS CLI like this:
aws configure --profile dev-account
Then use it in Terraform:
provider "aws" {
region = "us-east-1"
profile = "dev-account"
}
🧩 Final Thoughts
It’s easy to overlook authentication when you’re focused on learning Terraform, but it’s one of the most important habits you can build early.
Good habits save you from painful leaks and awkward Slack messages from security teams. 😅
Use AWS CLI. Keep your credentials out of your .tf
files. Let Terraform do the work behind the scenes.
Got a tip or use-case for handling credentials securely? Drop it in the comments or message me on LinkedIn — I’d love to learn how others are managing this in the wild! ☁️🔐
Top comments (0)