DEV Community: Mukesh KG

Stop Using JSON Keys: Secure Your GitHub Actions with Workload Identity Federation

Mukesh KG — Tue, 13 Jan 2026 09:01:06 +0000

If you are running production workloads on Google Cloud and still authenticating GitHub Actions using Service Account JSON keys, you are carrying unnecessary security risk and not following the best practises from google

This article explains why JSON keys are dangerous, what Workload Identity Federation (WIF) actually does, and how GitHub and GCP talk to each other under the hood - written for engineers and data scientists who already understand CI/CD but want the deeper identity story.

The Problem with JSON Keys
For years, the default pattern looked like this:

Create a GCP service account
Generate a JSON key
Store it in GitHub Secrets
Authenticate from CI

It was the best we've got while it violates almost every modern security principle. Because:
A Service Account JSON key is effectively a permanent password.

It does not expire automatically
It can be copied infinitely
It works from anywhere on the internet
Rotation is manual and often forgotten

If that key leaks, the attacker does not need GitHub, your repository, or your workflow. They authenticate directly against GCP.
This is why Google has been strongly nudging teams away from keys. Away from Long-Lived to Short-Lived credentials

Long-Lived vs Short-Lived Credentials (Quick 101)
This distinction is the entire reason Workload Identity Federation exists.

Long-Lived Credentials (JSON Keys)
Think of these as static secrets:

Created once
Valid until revoked
Reusable outside their original context
High blast radius They break zero-trust and least-privilege by design.

Short-Lived Credentials (OIDC Tokens)
Short-lived credentials behave like just-in-time access passes:

Issued only when needed
Automatically expire (usually ~1 hour)
Bound to a specific workload execution
Impossible to reuse later Even if intercepted, damage is limited. This is the security model WIF enables.

What Is Workload Identity Federation?
Workload Identity Federation allows external workloads (GitHub Actions, GitLab CI, Kubernetes, etc.) to access Google Cloud without service account keys.
Instead of trusting a file, GCP trusts an identity assertion.

GitHub = Identity Provider (IdP)
Google Cloud = Resource Provider No keys stored. No secrets copied. No rotation required.

What Actually Happens Between GitHub and GCP
Assume you already understand GitHub Actions jobs and runners. Here's the identity flow.

GitHub Action job starts A runner begins executing your workflow. At this point, it has zero GCP credentials.
GitHub issues an OIDC token Because your job has id-token: write permission, the runner can request an OpenID Connect (OIDC) token from GitHub. This token is: • Cryptographically signed by GitHub • Short-lived • Audience-restricted The token payload contains execution metadata: • Repository • Repository owner • Branch or tag • Workflow name • Job reference Think of this as a structured record describing who is running what, from where.
Token is sent to Google Cloud STS The google-github-actions/auth action sends this token to Google Cloud's Security Token Service (STS).
Google validates trust conditions GCP verifies: • Token signature (issued by GitHub) • Token audience • Attribute conditions you configured (repo, org, branch) This is where your security rules are enforced.
Token exchange happens If validation passes, STS exchanges the GitHub OIDC token for a short-lived Google access token. No service account keys are created. Nothing is persisted.
Service account impersonation The access token represents a temporary impersonation of a specific GCP service account. IAM permissions are evaluated exactly like any other GCP identity - but only for the token's lifetime.
Access expires automatically When the job ends (or the token expires), access disappears. This is zero-trust implemented correctly.

Benefits

No long-lived secrets in GitHub
Credentials expire automatically
Access can be restricted by repo, org, branch
Easier audits and compliance
No key rotation burden Security improves and operational friction drops.

Migration Overview
I recently migrated my Data ETL pipeline github action from JSON keys to WIF in under 20 minutes.
GCP Setup (One-Time)
You need to:
• Create a Workload Identity Pool

gcloud iam workload-identity-pools create "github-actions-pool" ...

• Create a Workload Identity Provider (GitHub)
• Allow a service account to be impersonated

gcloud iam workload-identity-pools providers create-oidc "github-actions-provider" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --attribute-condition="assertion.repository_owner == 'YOUR_ORG_NAME'"

Important: Attribute conditions are mandatory. This is where you lock down trust. By giving your org name you lock in the source which can be the provider so that this impersonation can happen only from github. Also not from any github repo but only from your your org repository.

GitHub Workflow Change
Enable OIDC:
permissions: contents: read id-token: write
Authenticate using WIF:
- uses: google-github-actions/auth@v2 with: workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/github-actions-pool/providers/github-actions-provider service_account: my-service-account@my-project.iam.gserviceaccount.com
That's it.

Final Thoughts
JSON keys were a necessary workaround in the past. They are technical debt today.
Workload Identity Federation gives you:
• Stronger security
• Smaller blast radius
• Less operational overhead
If Google is recommending WIF, it's the new baseline of dev sec ops

Glossary
Service Account
Non-human identity in GCP used by workloads.
Service Account JSON Key
Long-lived private key tied to a service account.
OIDC (OpenID Connect)
Identity layer on OAuth 2.0 using signed tokens.
OIDC Token (JWT)
Short-lived, signed token containing identity claims.
Identity Provider (IdP)
Entity that issues identity tokens (GitHub).
Workload Identity Federation
GCP mechanism for trusting external identities.
Workload Identity Pool
Container for external identities in GCP.
Workload Identity Provider
Defines how GCP validates external tokens.
STS (Security Token Service)
Exchanges external tokens for GCP access tokens.
Service Account Impersonation
Temporarily acting as a service account without keys.
Zero-Trust
Every access is verified; nothing is trusted by default.

IMO, a good v0 , that is, the zeroth version of your product, should feel like an insult to your capability but an "aaha" for your user

Mukesh KG — Mon, 25 Nov 2024 21:25:49 +0000

I wanted my users to have their own subdomain and ...

Mukesh KG — Tue, 12 Nov 2024 18:30:20 +0000

I wanted to create a functionality where every user of mine gets their own subdomain. And for that I needed my hosting provider to support wildcard(*) subdomain. So that anything.joyzo.in will resolve to *.joyzo.in where I have my application server running. And my application can then extract the subdomain "anything" from the full url anything.joyzo.in and build the page accordingly. As you know I am a returning-back dev and this seemingly simple task took almost 2 weeks for me, trying various hosting service providers. And finally got it done, ofcourse.
Here are my learnings:

1. Firebase

My app is in flutter. I started off thinking firebase would be ideal with seamless integration, because, you know, Google. Also, more importantly, I did not want to go searching the world for the best stack. So firebase it was. And seamless it did. Hosting worked fine. CLI was helpful. And then came the bummer.
Firebase does not support wildcard subdomain. Plain and simple NO. No turn arounds. No hacks. Nothing. You can afford two 10 days to not believe me.

2. Netlify

Then came Netlify. I follow a indie developer in Linkedin and sometime back he said he uses Netlify. So why not. There could have been many benefits and one was evident immediately. Drag and drop files to build. Cannot ask for anything simpler. But then came the bummer.
Netlify supports wild card subdomain but only for pro version. Pro version costs $19 per month. And we'll never know how easy it is to set up with a pro version 😛

But there is one important learning I had with Netlify. I learnt about NameServers.

Use this prompt to understand about nameservers in detail:
"explain nameservers like I am a fresh college grad with a CS degree".
But here is my version. A citizen developer who is looking to get things done version:

I bought my domain name joyzo.in from Godaddy. and then began development in flutter. And when I had a poc built ready in flutter, I wanted to host it. So that end users can visit joyzo.in and use my app. Fairly clear requirement. And thus came firebase. I have some idea about how firebase works. so I hosted my app in firebase and the app was live with a firebase project url. Now I researched about adding custom domain. Just by following steps I was able to make few changes and add my custom domain joyzo.in to this firebase project url. And bam, the app was live. And in the process I had to do a lot of configurations in my Godaddy domain control panel. and a only a few in firebase. Why? because my domain joyzo.in was using Godaddy nameservers. That's why I had to do a lot of configuration changes in Godaddy control panel versus firebase where the only change I had to do was to add a custom domain. So nameservers is the place where we do many changes. But what are those many changes? Changes like adding CNAME , TXT, A etc.. these are called DNS records. and nameserver is where your DNS is hosted so that you can make these "lot of" changes there. How did I specifically learn about nameservers when trying Netlify? Nothing specific. I had a documentation about changing nameserver from domain registrar, Godaddy, to Netlify. And what is the benefit? Actually there is no outstanding benefit except the fact that now you can add/modify/remove DNS records from the place where you host, Netlify, than from your domain registrar, Godaddy. We'll be anyhow using hosting services from the web interface frequently. So this is a convenience to have your dns hosted there as well. And firebase did not speak about nameservers. I am unsure whether there is a nameserver option in firebase. But Netlify do have it. They did speak about it. And now I know about it.

3. Vercel

As much as I was excited, I was disappointed that Netlify allowed wildcard subdomains but only for pro version. So researched further and found Vercel. This release post from Vercel is actually the one that caught my eye while I was still exploring other hosting options like Cloudfare, AWS, GCP etc.. And it was a breeze. Just setup your repo, set the prod branch, build script, install script and that is it. you are done hosting. Previously learnt nameserver and custom domain setup knowledge helped. Then come the important part, wildcard. It was another breeze. Just following the steps in the release post made it work like a charm. And here I have, my poc running:

*.joyzo.in

try changing the subdomain from "anything" to anything and see them all resolving to the same app.

Along side I got myself familiar with DNS records and their usages. Not expert level but I know when to change what and change what to what. I will follow up about DNS records with a post if asked for, in comments. If not, will be busy building Joyzo and sharing the journey here in dev.to exclusively.

Github for Story Writing

Mukesh KG — Wed, 27 Mar 2024 13:57:24 +0000

thoughts?

Widget Curious : Expanded

Mukesh KG — Tue, 12 Mar 2024 01:32:08 +0000

I am building a startup and I am pre product. Imagine the velocity at which the build is happening.
I was preparing a demo for a potential inital user for feedback. Demo was made in two days with just enough feature set to get the feel of the product, thanks to flutter + firebase.
At the last minute I somehow felt that the widgets in the screen weren't taking up enough space when the app is opened in a tablet. So to just be doubly sure, I added a Expanded widget at the top level. Triggered a debug run and everything seemed fine. Hence pushed to prod and went on for the demo.

As you have guessed, the demo flopped. Here are my learnings:

The Expanded widget is typically used within a Column or Row to indicate that its child should take up the remaining space in the main axis.

However, using Expanded requires its parent widget to have constraints to determine how much space should be allocated to the child. However, using Expanded requires its parent widget to have constraints to determine how much space should be allocated to the child. In some cases, especially when dealing with complex layouts or nested widgets, the absence of constraints can lead to errors or unexpected behavior, particularly in release builds where optimizations may differ.

It's important to note that while Expanded is a powerful tool for managing layout in Flutter, it's not always necessary and can sometimes be omitted depending on the specific requirements of your UI. It's always a good idea to simplify your layout and remove unnecessary widgets if they aren't contributing to the desired behavior or causing issues.

here are some scenarios where you might want to use or avoid using the Expanded widget in Flutter:

When to Use Expanded:

Flexible Layouts:
Use Expanded when you want a child widget to take up the available space along the main axis of a Row or Column. For example, if you have a list of items in a Column and you want one of the items to expand to fill the remaining space, you would wrap it with Expanded.

Column(
  children: [
    Text('Header'),
    Expanded(
      child: Container(color: Colors.blue),
    ),
    Text('Footer'),
  ],
)

Flexible Containers:
When you want a container to expand to fill the available space within its parent widget, you can use Expanded.

Row(
  children: [
    Container(color: Colors.red),
    Expanded(
      child: Container(color: Colors.blue),
    ),
    Container(color: Colors.green),
  ],
)

Flexible Sized Boxes:
Sometimes you might want a SizedBox to take up the available space within a parent widget. Wrapping it with Expanded can achieve this.

Column(
  children: [
    SizedBox(height: 20),
    Expanded(
      child: Container(color: Colors.blue),
    ),
    SizedBox(height: 20),
  ],
)

When Not to Use Expanded:

When Child Should Take Its Intrinsic Size:
If the child widget should only take its intrinsic size and not expand to fill available space, avoid using Expanded.

Row(
  children: [
    Container(width: 100, height: 100, color: Colors.blue),
    // No need for Expanded if the child should maintain its intrinsic size
    Container(width: 200, height: 100, color: Colors.red),
  ],
)

When Constraints Are Not Clear:
If the parent widget does not provide clear constraints, using Expanded might lead to layout issues. In such cases, consider using other widgets or reorganizing your layout.


Column(
  children: [
    // The parent Column does not provide constraints, so using Expanded here might lead to issues
    Expanded(
      child: Container(color: Colors.blue),
    ),
  ],
)

Single Child Layouts:
If you only have one child in a Row or Column and you want it to take up the available space, you might not need Expanded.

Column(
  children: [
    // Only one child, it will take up the available space by default
    Container(color: Colors.blue),
  ],
)

Remember, the decision to use Expanded depends on the specific layout requirements of your UI. Use it when you need a child to fill available space, and avoid it when you don't want the child to expand or when constraints are unclear.

Best Practices and Tips**

Use with Caution: While the Expanded widget can be a powerful tool for managing layout in Flutter, it should be used judiciously. Overusing Expanded can lead to complex and difficult-to-maintain layouts. Reserve its use for cases where you truly need a child widget to expand to fill available space.

Combine with Flex: The Expanded widget works hand in hand with Flex widgets like Row and Column. When using Expanded within a Row or Column, ensure that the mainAxisSize property of the parent is set to MainAxisSize.max. This allows the Expanded widget to expand to fill the available space along the main axis.

Avoid Nesting: Avoid nesting Expanded widgets within each other, as this can lead to unpredictable layout behavior. Instead, consider using a combination of Expanded and Flexible widgets within a Flex container to achieve more flexible layouts.

Test Across Devices: Always test your layouts across different devices and screen sizes, especially when using Expanded. While Expanded is great for filling available space, it's important to ensure that your layout remains responsive and looks good on all devices.

Optimize Performance: Be mindful of performance implications when using Expanded, especially in large and complex layouts. Overuse of Expanded can result in unnecessary widget rebuilding and layout recalculations, leading to performance issues. Keep your layout hierarchy as simple and efficient as possible.

it is fun to startup. if it goes by your plan, great. if not, you can always write about it. either way it is a win.

you can expect more about startups, flutter and firebase from me. letting you know just in case you are wondering to follow or not.

cheers!

How many start-up ideas do you have?

Mukesh KG — Fri, 22 Sep 2023 12:12:14 +0000

let the comment section rain

Flutter + Firebase ; What else could one ask for?

Mukesh KG — Tue, 29 Aug 2023 08:28:32 +0000

Since my recent decision to become an indie maker, I have got my hands dirty with possibly every stack available and concluded upon Flutter + Firebase. I can complete 99% of my planned projects with it. And I am astounded. It is too good to be true and I sure I am missing out something. Can some one explain what am I missing?

For context, I've been into Data Science for more that 9 years now, professionally. And the tech stack my DS works and deployment demands is mostly different than a full stack's. So I could be missing out something very silly.