AWS Builder Center

Builder Center

GitHub Didn’t Need My AWS Password. It Needed Trust. 🔐

GitHub Didn’t Need My AWS Password. It Needed Trust. 🔐

A beginner-friendly look at how GitHub Actions can deploy to AWS without storing long-lived AWS access keys. Learn how OIDC, IAM roles, and temporary credentials work together, and why trust, least privilege, and secure automation matter when building modern AWS deployment pipelines.

BUBAGANESH B

B.Tech AI & Data Science Student | Aspiring AI & Cloud Engineer

GitHub Didn’t Need My AWS Password. It Needed Trust. 🔐

When I first started learning AWS deployments, I thought the process was simple:
GitHub → AWS → Deploy.
Then I discovered the part nobody wants to think about:
How does GitHub prove to AWS that it is actually allowed to deploy?
The obvious beginner solution is to create an AWS access key, put it inside GitHub Secrets, and let the workflow use it.
It works.
But there is a better question:
What if GitHub never needed a permanent AWS key at all?
That is where OpenID Connect (OIDC) becomes interesting.

🔑 The Old Way: Give GitHub a Permanent Key

Imagine I create an IAM user and generate:
  • AWS Access Key ID
  • AWS Secret Access Key
Then I store those credentials inside GitHub.
Whenever my GitHub Actions workflow runs, it uses those credentials to access AWS.
At first, this feels convenient.
But there is a problem.
Those credentials can remain valid until they are rotated, disabled, or deleted.
That means my deployment pipeline is carrying a long-lived credential.
As a beginner, this made me realize something important:
Automation should not automatically mean permanent access.

🔐 The Different Idea: Let GitHub Prove Its Identity

With OIDC, GitHub does not need to keep a permanent AWS access key.
Instead, GitHub Actions provides an identity token.
AWS can verify that identity and determine whether the workflow is trusted to assume a particular IAM role.
Then AWS Security Token Service, or STS, provides temporary credentials for that workflow run.
The basic flow becomes:
GitHub Actions → OIDC Identity → AWS IAM Role → STS → Temporary Credentials → AWS
The credentials still exist during the workflow.
The difference is that we don't have to permanently store an AWS access key in the repository.
That small change completely changed how I think about CI/CD security.

🧠 Trust Before Permission

One concept that really stood out to me was the difference between a trust policy and a permissions policy.
They answer two different questions.

Trust Policy

Who is allowed to assume this role?

Permissions Policy

What can that role actually do?
This distinction is extremely important.
Imagine a GitHub repository successfully assumes an AWS deployment role.
That does not mean it should suddenly have permission to control everything in the AWS account.
The role should only receive the permissions required for the deployment.
That is the principle of least privilege.

☁️ My Mental Model

I started thinking about the architecture like this:
GitHub Actions
↓
“This is who I am.”
↓
AWS verifies the identity
↓
IAM checks the trust policy
↓
STS provides temporary credentials
↓
AWS deployment happens
For a static website, the workflow can then upload the website files to Amazon S3 and use Amazon CloudFront to serve the application globally.
The S3 bucket can remain private while CloudFront accesses it through the configured origin access mechanism.
So the architecture becomes:
GitHub → AWS IAM/OIDC → STS → S3 → CloudFront → Users

🚀 What Happens When I Push Code?

This is where the whole thing starts to feel like magic.
Suppose I update my website and push the changes to the main branch.
GitHub Actions starts the workflow.
Then:
  1. GitHub requests an OIDC identity token.
  2. AWS receives and verifies the identity.
  3. AWS checks the IAM role's trust policy.
  4. STS provides temporary credentials.
  5. The workflow uses those credentials to interact with AWS.
  6. The new website files are synchronized to S3.
  7. CloudFront can invalidate cached content when necessary.
And the important part is:
There is no permanent AWS access key sitting inside the GitHub repository.

👀 But What If Someone Copies My Workflow?

This was one of the most interesting parts for me.
Imagine someone copies the deployment workflow into another GitHub repository.
They may know things like the AWS account information, role name, bucket name, or other configuration values.
That alone should not give them deployment access.
Why?
Because the IAM trust policy can restrict which GitHub identity is allowed to assume the role.
So AWS isn't simply asking:
“Does this workflow know the role name?”
It is effectively checking:
“Is this the specific trusted identity I allowed to use this role?”
That is a much better security model.

🛡️ Least Privilege in Real Life

Another lesson I took from this is that security isn't just about hiding passwords.
It's also about limiting what an authenticated system can do.
A deployment role might need permissions to:
  • Upload files to a specific S3 bucket
  • Delete outdated website objects
  • Create CloudFront invalidations
But it doesn't automatically need permission to:
  • Create EC2 instances
  • Modify IAM users
  • Delete databases
  • Administer the entire AWS account
This is what makes least privilege practical rather than just a security theory.

⚠️ OIDC Doesn't Mean “No Credentials”

This is an important detail that beginners can easily misunderstand.
OIDC does not mean the workflow never receives AWS credentials.
Instead, it means the workflow doesn't need a long-lived AWS access key stored permanently for authentication.
AWS STS provides temporary credentials for the workflow.
So the better way to think about it is:
Permanent credential → Temporary identity-based access
That's the real improvement.

🧩 One More Thing I Learned

Security doesn't stop when the deployment succeeds.
A good deployment setup should also have a cleanup plan.
When the project is no longer needed, resources such as:
  • CloudFront distribution
  • S3 bucket
  • Deployment IAM role
  • Unused permissions
  • GitHub repository variables
should be reviewed and removed when appropriate.
Even the GitHub OIDC provider should only be removed if nothing else in the AWS account depends on it.
This reminded me of another AWS lesson:
Building responsibly also means knowing how to clean up responsibly.

🎓 Why This Matters to Me as a Student

Before learning about OIDC, I mostly thought of CI/CD as:
“Push code → automatic deployment.”
Now I see another layer:
“Who is deploying?”
“How does AWS know they are trusted?”
“What permissions do they receive?”
“How long do those permissions last?”
Those questions are just as important as getting the deployment to work.
A pipeline that deploys successfully is useful.
A pipeline that deploys securely and with controlled permissions is much more interesting.

🔥 My Biggest Takeaway

The biggest lesson wasn't actually about GitHub Actions.
It was about trust.
Instead of saying:
“Here is a permanent AWS key. Keep it safe.”
we can build a system where:
“Prove who you are, and AWS will give you temporary access if you're trusted.”
That feels like a much better way to think about cloud automation.

🚀 The Simple Learning Path

If you're a beginner like me, I think this is a useful way to understand the whole concept:
GitHub Actions
↓
OIDC
↓
IAM Trust Policy
↓
STS Temporary Credentials
↓
Least-Privilege IAM Permissions
↓
S3 / CloudFront Deployment
You don't need to understand everything at once.
Start with one question:
“How does GitHub prove to AWS that it is allowed to deploy?”
Once that makes sense, the rest of the architecture becomes much easier to understand.

☁️ Final Thought

I used to think secure deployment meant:
“Store the AWS credentials carefully.”
Now I'm starting to think differently:
“Maybe the best credential is the one you never have to store permanently.”
That is what made GitHub OIDC one of the most interesting AWS concepts I've learned recently.
It isn't just about automating deployment.
It's about making automation earn its permission to deploy. 🔐☁️

💬 What would you choose for your next AWS project?

Long-lived access keys, or OIDC with temporary credentials?
And if you're a beginner, what part of AWS security was confusing to you at first?
# github# aws-iam-identity-center# ai-security# ci-cd# devops
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article