DEV Community: Tobiloba Ogundiyan

[Boost]

Tobiloba Ogundiyan — Thu, 06 Nov 2025 20:44:39 +0000

Rethinking My AWS Admin Access: Lessons Learned From Moving to Single-Sign-On

Tobiloba Ogundiyan ・ Nov 6

#aws

[Boost]

Tobiloba Ogundiyan — Thu, 06 Nov 2025 20:44:39 +0000

Rethinking My AWS Admin Access: Lessons Learned From Moving to Single-Sign-On

Tobiloba Ogundiyan ・ Nov 6

#aws

Rethinking My AWS Admin Access: Lessons Learned From Moving to Single-Sign-On

Tobiloba Ogundiyan — Thu, 06 Nov 2025 20:41:00 +0000

Recently, I began auditing my AWS account and I saw how secure I had made it when deploying applications and managing external access. I even wrote a blog post recently on how people should adopt OpenID Connect to authenticate in CI/CD pipelines and deploy their applications to AWS.Recently, I was deploying a Terraform script locally and I could not authenticate to AWS. I figured out my static keys were expired and I needed to generate another. That was when I realized my real admin access wasn’t secure at all. I was still moving static keys around for admin access, and they were permanent.

I checked the IAM portal to see if I could find a solution to eliminate this completely, and I found a much better approach by using a federated identity through IAM Identity Center. I always thought only organizations should use this since they manage a lot of users, but now I can see why those orgs use this approach. Authenticating with a federated identity can be complex when setting up, but AWS identity center has made it easy and high-level enough to implement even for personal accounts.

What I Wanted

I knew I wanted simplicity, traceability, and the ability to eliminate static keys completely. Only a federated identity with Single Sign-On can provide that access, so I decided to implement it. I went deep into IAM Identity Center. I saw that I could create a user that authenticates through AWS’s identity provider, give it some permission sets, and time its permissions for limited access. In this setup, MFA can be enforced on all users with a single click, which is much better than IAM users authenticating with just a username and password.I also saw how I could integrate added extras like creating a separate account for the admin and using SCPs to manage the accounts and also limiting admin privileges with policies, such as blocking the creation of new IAM users. Then I came up with my own flow.

What I Tried

I experimented with a lot of things. I gave myself no permissions and created another role to elevate only when i need to perform admin tasks. Logged in as admin and saw I couldn’t access anything. All console dashboards were showing “access denied,” and I realized that was too extreme. That was when I started seeing how zero trust actually works.

I tried again, increased little privileges, and switched to read-only access. Everything worked, but the admin couldn’t still create anything. Then I logged in to the console CloudShell and assumed the AdministratorAccess role which i created alongside to elevate priviledges when i need to perform admin tasks. Now the temporary tokens came into play which is valid for only 1 hour. I had to put them in manually to access any resource, and that’s when I realized how critical it is to balance security and ease of use.

Checking the roles, I saw the permissions assigned by the identity provider were also short-lived, and there was no need to limit them further since they would be rotated automatically. That’s when I saw it was AWS Security Token Service (STS) still giving access behind the scenes to the SSO.

What I Eventually Arrived At

I eliminated the extra admin role I created for admin to assume because that was redundant. I went back to IAM Identity Center permissions and changed access from read-only to admin, but limited the session to 1 hour. This isn’t fully zero trust, but the admin still has to verify every hour if they are truly admin. It’s better than IAM users that give implicit trust. This setup is different because admin is never trusted it’s always verified.the fact that the sessions are logged through cloudtrail means the administrator actions can also be audited if warranted.

It’s like asking a police officer to always identify who he is by showing his badge. If he can’t, he doesn’t get access. So here’s the high-level overview I arrived at.

everything starts with the cloud admin logging in through the sso portal. mfa is enforced first thing so no one just walks in without verification. once i’m in, aws identity center takes over, assigns the right permission set and handles federation internally using saml. i don’t manage any credentials or keys myself anymore, aws does it all behind the scenes.

after that, sts kicks in and gives me temporary credentials. these are short lived, valid for just about an hour. once they expire, i have to re-authenticate again through sso. that’s where the zero trust idea really comes in. the admin role i assume is AWSReservedSSO_AdministratorAccess, and it only gives me access for that short window. when the session ends, that access disappears.

on the governance side, scps are set to restrict what even admin can do, like creating another identity center instance. cloudtrail logs every single action i take so i can trace anything later. cloudwatch helps with visualizing and alerting on those logs when something unusual happens.

so at the end of the day, this flow gives me full control when i need it, but zero standing privileges when i don’t.

The Realization Moment

Coming back to my failed Terraform script, I checked AWS docs, configured local SSO, created an admin profile, and was able to authenticate using the single-sign-on from the browser to the CLI and that was it. No access keys, sessions are timed. Now I have one hour to do what I need before I’m asked to show my badge again.

If you still think IAM users are enough or still moving static keys , and you’re still using them because your personal AWS account is “just for labs,” think about security, reliability, and how things are done the modern way. When the newer route is clearly better than the old one, take it ,no matter the complexity.

if you are still using static keys in your github actions pipeline to access AWS. then you need to read this to fix your workflows

Tobiloba Ogundiyan — Thu, 06 Nov 2025 18:48:48 +0000

Tobiloba Ogundiyan

Nov 6 '25

Accessing AWS in Github Actions Using OIDC

#tobilobaogundiyan #aws #githubactions #cicd

Comments

6 min read

Accessing AWS in Github Actions Using OIDC

Tobiloba Ogundiyan — Thu, 06 Nov 2025 18:47:36 +0000

In CI/CD pipelines, the normal way to access AWS resources for deployment is to generate long-lived access keys in IAM and store those keys in the repository, but this approach has the following flaws:

The keys are long-lived and if they ever leak, an attacker can use them to access your AWS account.
The same static keys get reused across many jobs and branches, so it is hard to trace which workflow actually did what.
Rotating or expiring those keys requires a manual process, so they usually stay active way longer than they should.

OpenID Connect (OIDC), an identity layer on top of OAuth 2.0, solves this by letting GitHub Actions request short-lived, on-demand credentials from AWS using a trusted federation instead of storing static keys. This approach gives the following benefits:

No long-lived secrets in the repo. There are no hardcoded AWS access keys in GitHub at all.
Short-lived credentials. AWS only issues temporary credentials for that specific job, and they expire automatically after the job finishes.
Fine-grained access. You can scope which repo, branch, or even workflow is allowed to assume a specific IAM role.
Auditability. In CloudTrail, you can see exactly which workflow assumed which role, so it’s easier to trace changes.
Lower blast radius. If one repo is compromised, it can’t reuse credentials from another repo or environment.

Prerequisites

In this article, we will configure AWS to trust GitHub via OIDC, create an IAM role with read-only access to S3, and let a GitHub Actions workflow assume that role. You will need these resources to proceed:

An AWS account with the following permissions:


 iam:CreateOpenIDconnectProvider
 iam:CreateRole
 iam:PutRolePolicy or attached managed policies
For less hassle, a root account should do.

Create a new GitHub repository in your account and name it aws-oidc. Leave it empty for now with no code and no workflow. I also created a repo for this article here: github.com/t0gun/aws-oidc. We will add the workflow file later after we configure AWS.

High-Level Architecture

Below is the high-level flow of how GitHub uses OIDC to get temporary credentials for our Actions runner.

At a high level, the workflow runner requests an OIDC token, AWS STS verifies it against the trust policy, and then returns short-lived credentials that match the IAM role we created. Now let’s build this step by step.

Step 1: Add GitHub as an OIDC identity provider in AWS

You can either use the management console or the AWS CloudShell (CLI) to do this.

Using the AWS Management Console:

Open the IAM console and in the left navigation choose Identity Providers.
Once you are in that pane, proceed to add a provider, for the provider type choose OpenID connect.
For the provider URL: Use https://token.actions.githubusercontent.com
For the "Audience": Use sts.amazonaws.com
Save

At this point, AWS now trusts the GitHub OIDC provider.

Using the AWS CLI:

Paste this in the CloudShell:

aws iam create-open-id-connect-provider \
  --url "https://token.actions.githubusercontent.com" \
  --client-id-list "sts.amazonaws.com" \
  --thumbprint-list "6938fd4d98bab03faadb97b34396831e3780aea1"

The --client-id-list value is what the audience must be, and the thumbprint is GitHub’s root CA fingerprint. We can also confirm if it has been added using:

aws iam list-open-id-connect-providers

You should receive a response of your ARN (Amazon Resource Name) similar to this:

{
    "OpenIDConnectProviderList": [
        {
            "Arn": "arn:aws:iam::555055555555:oidc-provider/token.actions.githubusercontent.com"
        }
    ]
}

Step 2: Create the IAM Role for GitHub Actions

Now that AWS trusts GitHub as an OIDC identity provider, we need to create an IAM role that GitHub Actions can assume. This role does two things:

Defines the trust policy: which repo and branch are allowed to assume it
Defines the permissions: what that workflow is actually allowed to do in AWS

For this demo, we will give only S3 ReadOnly access so we can test the setup. For simplicity we will only use the AWS management console to create this role.

Using the AWS Console:

In the IAM console, go to “Roles” and click “Create role.”
For trusted entity type, choose “Web identity.”
For identity provider, select the GitHub provider you created in Step 1 token.actions.githubusercontent.com and the audience sts.amazonaws.com
For GitHub organization / user: set this to your GitHub username (for example, t0gun).
For Github Respository: Use the repo you created for this, aws-oidc.
We should leave the branch as is *, this gives us flexibility to run our jobs from any branch.
Attach permissions. For demo, attach AmazonS3ReadOnlyAccess.
Name the role something like github-oidc-deploy-role and save it.
Copy the Role ARN. We will use that in the GitHub Actions workflow.

Now open the role, check trust relationships and open the trust policy it should look this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::555066115752:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": [
                        "repo:t0gun/aws-oidc:*"
                    ]
                }
            }
        }
    ]
}

Principal.Federated is the OIDC provider we created in Step 1.
Action is sts:AssumeRoleWithWebIdentity, which is how GitHub asks AWS for short-lived credentials.
aud must match sts.amazonaws.com, so AWS knows this request is meant for STS.
sub is basically “who is calling.” In this case we’re allowing any branch from the repo t0gun/aws-oidc.

For example, if you only want to allow the main branch to assume this role, you can tighten the trust policy by replacing the sub condition with:

"token.actions.githubusercontent.com:sub": "repo:t0gun/aws-oidc:ref:refs/heads/main"

This means only workflows running from the main branch of t0gun/aws-oidc will get credentials. All other branches will be denied.

Step 3: Create the Github Actions Workflow

Now we will create a Github Actions workflow in the aws-oidc repo that:

Requests temporary credentials from AWS using OIDC
Assumes the IAM role we just created
Runs an AWS command to prove it works

Clone your repo locally, create a file inside the repo at .github/workflows/oidc-test.yml with this content:

name: oidc-test

on:  
  workflow_dispatch  

permissions:
  id-token: write    # required for OIDC
  contents: read     # allow checkout

jobs:
  aws-access-test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Configure AWS credentials using OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: {your own arn role here}
          role-session-name: github-actions-session
          aws-region: us-east-1 # or any region you work in

      - name: Verify AWS identity
        run: |
          aws sts get-caller-identity
          aws s3 ls

Here are the important parts:

permission.id-token: write (this is what allows the workflow to request the OIDC token from github).

configure-aws-credentials@v4: This action calls sts:AssumeRoleWithWebIdentity behind the scenes. It uses the trust policy you defined in IAM
role-to-assume: This must match the Role ARN from the role you just created in Step 2.
aws sts get-caller-identity: This prints which IAM role the job is currently using. You should see your role name here, not root and not an IAM user.
aws s3 ls: This should work because you attached AmazonS3ReadOnlyAccess. If STS or the trust policy is broken, this will fail.

After you commit this file, push it to GitHub. Since the workflow is triggered with workflow_dispatch, you need to run it manually in the Actions tab.When it finishes successfully, you’ve proved OIDC is working and GitHub Actions got temporary AWS credentials with no long-lived access keys stored in the repo.after running mine here are the results from the image below

If pipeline fails please feel free to review the steps and also check out my own aws-oidc public repo.

Conclusion

This setup removes long-lived AWS keys from your CI/CD pipeline and replaces them with short-lived, scoped credentials issued on demand through OIDC. You get least privilege, auditability, and no shared secrets across repos. This is the baseline for doing secure delivery in AWS with GitHub Actions, and it’s what I expect teams to be doing in 2025.