Secret Patterns for Modern Distributed Systems

Author

Govardhana M K
November 15, 2025

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor THE DEEP VIEW

Become An AI Expert In Just 5 Minutes

If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.

👀 Remote Jobs

📚️ Resources

Looking to promote your company, product, service, or event to 57,000+ Cloud Native Professionals? Let's work together. Advertise With Us

🧠 DEEP DIVE USE CASE

Secret Patterns for Modern Distributed Systems

If you have ever:

  • Set up GitHub Actions to push images to DockerHub or Google Container Registry.

  • Connected Terraform Cloud to GitHub or GitLab so it can read your repository.

  • Used AWS Cognito or Azure AD to authenticate users into an internal dashboard.

  • Configured CI pipelines to deploy into Kubernetes.

Then you have already interacted with different trust and authentication flows that rely on secrets. Let us look at the prominent ones one by one.

1. OAuth

1. Access Token Request

You configure your CI/CD pipeline, internal app, or automation tool to connect to an external system say, GitHub, Azure Vault, or a container registry.

The client (your app or tool) sends a request to the authorization server (e.g., GitHub OAuth server, Azure AD) with: client_id, client_secret, scope (optional), grant_type (e.g., client credentials)

This is the tool saying: “Here’s who I am. Can I get access to perform a task?”

2. Identity Validation and Token Issuance

The authorization server checks the credentials. If valid, it issues an access token.

This is not a password or a user credential. It’s a signed string representing what the client is allowed to do.

For example, GitHub may return a token that allows a GitHub Action to read and write to a repo.

3. Using the Access Token (Bearer Token)

Now, the client uses the token to hit protected APIs. Each call includes:

Authorization: Bearer <access_token>

The receiving API server extracts the token, validates it using keys from the identity provider, and checks claims like expiration and audience.

4. API Response

The server responds based on the validity of the token:

  • 200 OK if the token is valid

  • 400 Bad Request for missing or malformed token

  • 401 Unauthorized for expired or invalid token

If your pipeline breaks, your login fails, or your API call gets rejected, start by asking: Was there a token involved? If yes, trace it back through the OAuth flow.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Upgrade to Paid to read the rest.

Become a paying subscriber to get access to this post and other subscriber-only content.

Already a paying subscriber? Sign In.

Paid subscriptions get you:

  • • Access to archive of 250+ use cases
  • • Deep Dive use case editions (Thursdays and Saturdays)
  • • Access to Private Discord Community
  • • Invitations to monthly Zoom calls for use case discussions and industry leaders meetups
  • • Quarterly 1:1 'Ask Me Anything' power session