DEV Community: Savinda

From Control Plane to KRO: A Journey Into Kubernetes Extensibility

Savinda — Wed, 06 Aug 2025 08:18:40 +0000

Kubernetes has revolutionized how we deploy and manage infrastructure. But with great power comes great complexity. If you've ever struggled with Custom Resource Definitions (CRDs), hand-rolled controllers, or tangled YAML, you're not alone. This post sets the stage for KRO (Kube Resource Orchestrator)—a project from Google, Microsoft, and AWS—by walking you through how Kubernetes really works under the hood and why KRO is here to save your day.

How Kubernetes Works – The Control Plane

The Kubernetes control plane is the brain of the cluster. It consists of:

API Server: The front door to the cluster. Everything talks to this.
etcd: A key-value store that remembers the entire cluster state.
Controller Manager: Ensures reality matches the desired state.
Scheduler: Assigns pods to appropriate nodes.

Extending Kubernetes with CRDs

Kubernetes is declarative. You declare what you want, and the system figures out how to do it. But what if you want to define your own resource types?

That’s where CRDs (Custom Resource Definitions) come in.

apiVersion: my.example.com/v1
kind: App
metadata:
    name: demo
spec:
    release: 1.0.2

Why CRDs Alone Aren’t Enough

You need a controller (or "operator") to make CRDs come alive. A controller watches for objects like app, then acts—e.g., provisioning infrastructure, updating apps, etc.

Problem? Controllers are hard to write.

You typically need:

Code (often in Go)
Frameworks like Kubebuilder or Operator SDK
Deep knowledge of Kubernetes APIs

Common Pain Points:

overloaded API server from poorly written watches
etcd bloat from unused CRDs
Complex reconcilers and ordering logic

Why Tools/Operator Like KCC, ACK, and ASO Aren’t Enough on Their Own

While tools like KCC (Google), ACK (AWS), and ASO (Azure) let you manage cloud resources using Kubernetes CRDs, they’re tightly coupled to their respective clouds.

They’re great for cloud integration, but not for composing reusable APIs or simplifying multi-step infrastructure workflows.

That’s where KRO steps in—it’s the glue that turns raw CRDs into full-blown platform APIs.

Introducing KRO (Kube Resource Orchestrator)

KRO is a Kubernetes‑native, cloud‑agnostic framework that lets platform teams define resource bundles as reusable APIs via a ResourceGraphDefinition (RGD). KRO helps you build a self-service developer platform that works across clouds by leveraging existing operators (KCC, ACK, ASO)

Platform teams define defaults and hide complexity, letting developers consume a clean interface.

When applied, KRO:

Dynamically creates a CRD for your API.
Sets up a controller to manage instances of that CRD.
Manages ordering, dependencies via CEL expressions.
Handles both Kubernetes-native and cloud resources (via ACK, KCC, ASO).

Example Use-cases:

Provisioning a GKE/AKS/EKS cluster + IAM
Deploying web apps combined with cloud databases and load balancers

How KRO Works: Architecture

Define a ResourceGraphDefinition (RGD) – schema + resource templates + dependency definitions.
KRO validates the RGD, creates the CRD, and deploys a micro‑controller for that custom type.
A user instantiates your API object (like WebApp or GKECluster), and KRO generates underlying Kubernetes objects in the correct order.
Lifecycle is managed automatically—updates, reconciliation, status reporting.

Conclusion

KRO builds on everything that makes Kubernetes powerful—and fixes what makes it painful. Before you dive into building with KRO, it's essential to understand the journey from kubectl to CRDs to controllers. Once you do, you’ll see why KRO isn’t just a new tool—it’s a new way of thinking about Kubernetes extensibility.

Building a JWT-Aware Reverse Proxy in Go for Tiered API Access

Savinda — Tue, 17 Jun 2025 15:45:56 +0000

Savinda

Jun 12 '25

Building a JWT-Aware Reverse Proxy in Go for Tiered API Access

#programming #go #beginners #devops

Comments 1

4 min read

Building a JWT-Aware Reverse Proxy in Go for Tiered API Access

Savinda — Thu, 12 Jun 2025 10:21:10 +0000

Introduction

In this blog post, I’ll walk you through a small proof-of-concept project I built: a reverse proxy in Go that routes requests to different backend services based on the tier claim in a JWT token.

The proxy uses RSA public/private key cryptography to validate the JWT, then forwards the request to either a free-tier or subscribed-tier backend. The whole setup runs in containers on Minikube. It’s a great way to understand how reverse proxies and JWT authentication can work together

Motivation

I wanted to understand how reverse proxies work at a lower level and how JWTs could be used to manage access control between service tiers. I also wanted something I could deploy easily with Docker and Minikube, so it’s very infrastructure- and developer-friendly.

Architecture Overview

Here's what the system looks like:

The client sends a request with a JWT in the Authorization header
The reverse proxy verifies the JWT using a public RSA key
It extracts the tier claim (e.g., "free" or "subscribed")
Based on that, it routes the request to the appropriate backend service

All services are containerized and deployed in Minikube.

Key Components with Code Examples

🔁 Reverse Proxy (Go)

Here's how the reverse proxy is created:

target, _ := url.Parse(targetURL)
proxy := httputil.NewSingleHostReverseProxy(target)
proxy.ModifyResponse = func(resp *http.Response) error {
    log.Printf("Response from backend: %d", resp.StatusCode)
    return nil
}

Custom Director logic modifies the request:

proxy.Director = func(req *http.Request) {
    req.Header.Set("X-Forwarded-For", req.RemoteAddr)
    req.URL.Scheme = target.Scheme
    req.URL.Host = target.Host
    log.Printf("Forwarding request to: %s", req.URL.String())
}

Routing rules come from a YAML config:

routes:
  free: http://free-tier-service:9000
  subscribed: http://subscribed-tier-service:9000

This is loaded in Go as:

type Config struct {
    Routes map[string]string `yaml:"routes"`
}

🔐 JWT Auth

JWT tokens are RSA-signed and validated using the public key:

func validateJWT(r *http.Request) (jwt.MapClaims, error) {
    tokenString := extractToken(r)
    pubKeyData, _ := ioutil.ReadFile("public.pem")
    pubKey, _ := jwt.ParseRSAPublicKeyFromPEM(pubKeyData)

    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        return pubKey, nil
    })
    if claims, ok := token.Claims.(jwt.MapClaims); ok && token.Valid {
        return claims, nil
    }
    return nil, err
}

Token is extracted like so:

func extractToken(r *http.Request) string {
    bearer := r.Header.Get("Authorization")
    return strings.TrimPrefix(bearer, "Bearer ")
}

🧭 Routing Logic

Once the tier is extracted, routing is handled like this:

claims, _ := validateJWT(r)
tier := claims["tier"].(string)
targetURL := routeConfig.Routes[tier]

proxy := reverseProxy(targetURL)
proxy.ServeHTTP(w, r)

🛠️ Backends

Two simple backend services:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def free_home():
    return {"msg": "Hello Free-tier User 🌱"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=9000)

from flask import Flask
app = Flask(__name__)

@app.route("/")
def subscribed_home():
    return {"msg": "Hello Subscribed User 🚀"}

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=9000)

Each backend is a basic HTTP server with a unique response to verify routing.

🧪 Common Real-World Use Cases

SaaS platforms with "free" vs. "premium" tiers controlling access to APIs
Content streaming services that serve different quality or features based on the user's subscription
E-learning portals gating content behind subscriptions or course enrollments
Mobile backend systems offering tier-based feature access
Enterprise APIs that segment functionality by internal department or external partner level

🌐 Real-World Considerations

Here’s where things get a bit more nuanced 🔍:

In a real-world system, user identity and tier access should be validated and persisted both at the authentication system and on the backend services.

JWT Signature & PKI

Since JWTs are signed using PKI (public/private key cryptography), any attempt by a user to modify the token’s claims (like the tier) will break the signature verification. This means:

The backend can (and should) verify the JWT signature itself to ensure the token is genuine and untampered.

If the signature check fails, the request must be rejected.

This prevents users from forging or altering their JWTs to escalate privileges.

Why Backend Validation Matters

Even though the proxy validates the JWT, backends should never blindly trust the proxy. The proxy can be bypassed if someone calls the backend API directly.

Backends should perform their own JWT validation or check with a centralized auth system.

Token Freshness and Revocation

JWTs are stateless, meaning once issued, they carry claims until expiry.

If user privileges change (e.g., downgrade from subscribed to free), the backend needs a way to invalidate old tokens or verify claims against a database.

This can be done with short token lifetimes, token revocation lists, or real-time claim checking.

Proxy as a Single Point of Failure

The proxy could become a bottleneck or single point of failure.

For production, consider dedicated API gateways (e.g., Kong, Ambassador, Istio) that offer robust features like rate limiting, observability, and retries.

✋ Limitations

No HTTPS (for now)
Static public key loading (no hot reload or key rotation)
Basic error handling
No rate limiting, observability, or distributed tracing
No token revocation or refresh support

Still, it’s a clean and focused implementation that illustrates the core ideas beautifully.

🚧 Source Code & Deployment

You can find the full source code on my Github

To deploy it in Minikube:

Build the Docker images for the proxy and backends
Apply the Kubernetes manifests
Test with curl and different JWTs

💭 Final Thoughts

This was a fun project to build and learn from. If you’re new to Go or want to understand JWT-based routing and reverse proxy logic, I highly recommend trying something like this. Yes, it’s basic — but it’s real, working code, and you’ll walk away with actual insights.

Let me know what you think! Feedback is welcome — just keep in mind that this was built for educational purposes, not production 🚀

Behind the Code: A Simple Look at the Software Supply Chain

Savinda — Fri, 16 May 2025 03:40:55 +0000

Whether you're building your first web app or deploying containers in the cloud, you're already using a software supply chain — even if you’ve never heard of it before. This blog post is a beginner-friendly introduction to what the software supply chain is, why it matters, and how it can affect your code and security. No complex jargon, no deep dives — just the core concepts, explained in simple terms, with a few memes along the way to keep things fun.

Modern software development is rarely about building everything from scratch. Instead, we assemble applications using open-source libraries, external APIs, containers, CI/CD tools, and cloud platforms. This network of components and tools is known as the software supply chain.

But while this speeds up innovation, it also introduces risk: if any part of the chain is compromised — intentionally or not — the whole system can be affected.

Real-World Example

Let’s say you're building a Node.js app and install a package: npm install express
What you might miss is that express pulls in multiple dependencies, and one of those could be:

outdated and vulnerable
or worse, a trojan placed by a malicious actor

This is how supply chain attacks happen and that’s why software supply chain security is now a top priority for developers and organizations alike.

Why It Matters

Supply chain attacks have become a favored strategy for attackers, as demonstrated in high-profile incidents like:

SolarWinds (2020)
Log4Shell (2021)
Event-Stream NPM package (2018)

These weren’t just bugs — they were exploits hiding in third-party tools or dependencies. These incidents have pushed the tech world to rethink how software is built and secured.

How to Protect the Software Supply Chain

Securing your supply chain is about visibility and control. Here’s how to get started:

Tool/Practice
SBOMs (Software Bill of Materials) ==> Know exactly what's in your build
Sigstore (cosign, Fulcio) ==> Sign and verify artifacts
Snyk, Trivy, Grype ==> Scan for vulnerabilities in code and containers
Provenance (in-toto, SLSA) ==> Track how software was built and by whom

Final Thoughts

If you're deploying software - whether it's to a serverless platform, a Kubernetes cluster, or an IoT device - you're part of the software supply chain.

Don’t assume trust.
Verify every layer.
Automate scanning and signing where possible.