Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | FinTech / SaaS |
| Cloud Environment | GCP (70%), Azure (30%) |
| Workloads | VMs + GKE — Kubernetes is the primary compute layer |
| K8s Platform | Google Kubernetes Engine (GKE), including private clusters |
| Identity Provider | Google Cloud Identity / Workspace |
| Console Access | 10–15 people with cloud and cluster access |
| Communication | Slack |
| Compliance | ISO 27001, SOC 1, SOC 2, GDPR |
| Access Model Before | Standing kubeconfigs, shared cluster-admin, manual RBAC |
| Primary Interest | Kubernetes JIT with pre-defined roles |
The Situation: GKE Is Where the Work Happens, and Access Is the Weak Point
For this FinTech, GKE was not a secondary compute layer bolted onto a VM estate. It was the backbone. Two enterprise SaaS products — the ones processing financial transactions through an OLTP data tier — ran as workloads across GKE clusters spanning development, staging, and production. Engineers touched pods, logs, deployments, and services multiple times a day. When the team mapped where their access requests actually went, Kubernetes dominated.
The problem was never that engineers needed cluster access. It was how that access was granted, scoped, and — in theory — revoked:
- Standing kubeconfigs sitting on developer laptops with long-lived credentials.
- Shared cluster-admin bindings handed out because scoping a namespace-level role by hand takes time the team does not have.
- Manual RBAC changes processed ad hoc, with no consistent approval trail.
- GKE audit logs that attributed actions to a shared federated identity, making “who actually did this?” an unanswerable question after an incident.
For a team under ISO 27001, SOC 1, SOC 2, and GDPR, with real financial data moving through those clusters, the gap between how access should work and how it actually worked was a compliance liability waiting for an auditor to find it.
The Core Challenge
Kubernetes was the dominant access surface, each request required manual RBAC work, and the path of least resistance — cluster-admin for everyone — had quietly become the norm. The team needed GKE access to be self-service, time-bound, and scoped to the roles they had already designed, without reintroducing the friction that pushed them toward cluster-admin in the first place. And they needed it to work with private GKE control planes, which complicate every “just give engineers kubectl” shortcut.
Where the Gaps Were
Standing Kubeconfigs on Every Laptop
Every engineer who had ever needed a cluster had a ~/.kube/config with GKE credentials. Those credentials did not expire, were not scoped to specific namespaces, and persisted long after the task that justified them was finished. The consequences are direct:
- One stolen or compromised laptop with a valid kubeconfig is a direct route into any cluster that config references — including production clusters running regulated financial workloads.
- Rotation never happens, because rotating tokens breaks every developer’s local setup. So the credentials simply accumulate.
- No inventory exists of which engineers hold active credentials to which clusters. The team cannot answer “who can reach production GKE right now?” with precision.
Shared Cluster-Admin as the Default
The team had designed sensible RBAC: namespace-scoped view roles for debugging, edit roles for deployments, admin roles for cluster operations. In practice, engineers were often given cluster-admin anyway, because:
- Namespace-scoped bindings take effort. Determining the right namespace, the right role, creating the binding, testing it, communicating back — for an urgent request, cluster-admin is a single faster command.
- Debugging does not know its scope in advance. An engineer chasing a crashlooping pod may need to inspect multiple namespaces and cluster-level resources; starting with view on one namespace guarantees a second request minutes later.
- Bindings do not self-destruct. A cluster-admin binding created for a 30-minute investigation survives until someone manually removes it — which is to say, effectively never.
The result: multiple engineers holding standing cluster-admin on production clusters, each action logged under the same federated role. When a misapplied manifest causes an outage, the investigation starts with “which of our admins did this?” and frequently ends without an answer.
Audit Logs That Audit Nothing Useful
GKE audit logging records API-server activity, but when every engineer authenticates through the same mapped identity, the audit trail attributes everything to that one principal. Cloud Audit Logs in GCP show who assumed what, but correlating those events with specific kubectl commands inside a cluster means cross-referencing timestamps across two different log systems — a forensic exercise nobody runs proactively, and a poor answer when an auditor asks “prove who had admin access to production and what they did with it.”
Private Clusters vs. Productive Engineers
The team had done the right thing by configuring GKE control planes as private endpoints rather than exposing them publicly. But that security decision created a daily productivity problem. Engineers could not kubectl from their laptops without one of the usual workarounds: a VPN with broad network access baked in, a shared bastion host, or brittle port-forwarding. Each workaround reintroduced exactly the kind of standing, broad access the private endpoint was meant to prevent.
The Cloudanix Solution: GKE JIT With Pre-Defined Roles
Cloudanix Kubernetes JIT replaced standing kubeconfigs, shared cluster-admin bindings, and manual RBAC management with ephemeral, scoped, identity-stamped GKE access — delivered through the tools engineers already use.
How It Works for GKE Clusters
-
Engineer requests access via Slack or the Cloudanix Console, selecting the cluster, namespace, role (view / edit / admin / cluster-admin), and duration, with a reason or incident ID attached.
-
Approval routes by sensitivity. View access on a development namespace can auto-approve. Edit access on a production namespace requires one approver. Cluster-admin on any production cluster escalates with full context to a designated approver.
-
Engineer runs
cdx k8s connect. The Cloudanix CLI opens an outbound tunnel into the cluster’s VPC — solving the private-cluster problem — mints a short-lived kubeconfig scoped to the granted role and namespace, and sets the kubectl context. -
Engineer uses normal tools.
kubectl,k9s, Lens, Helm — anything that reads a kubeconfig works unchanged. The session is scoped to exactly what was granted; an engineer withviewon one namespace cannot exec into pods or reach another namespace. -
Every command is stamped to the real human, not the shared federated identity. When the audit trail shows a
rollout restartin a production namespace, it names the specific engineer who ran it. -
Access auto-expires. When the window closes, the kubeconfig is invalidated, the tunnel closes, and the binding is removed. No standing access survives the session.
Pre-Defined Roles Mapped to Teams
The team had already done the RBAC design. Cloudanix makes those roles requestable and enforceable instead of aspirational:
- Engineering can request
viewandediton development and staging namespaces (auto-approved), andviewon production namespaces (one approval). - Platform/DevOps can request up to
adminon any namespace (auto-approved for non-prod) andcluster-adminon production (escalated approval). - Custom scoped policies map precisely to the team’s existing RBAC design, so the model they built is finally the model that is enforced on every request — not the one that gets overridden whenever urgency wins.
Solving the Private GKE Cluster Problem
For fully private GKE control planes, cdx k8s connect dials outbound to a lightweight proxy inside the customer’s own VPC. The path is: engineer’s laptop → outbound HTTPS → Cloudanix relay → customer VPC proxy → private GKE API server. No VPN. No bastion. No inbound network changes, no new ingress rules, no security-group edits. The API server stays private, and engineers get scoped kubectl from anywhere — without the broad-access workaround that defeats the purpose of a private cluster.
Identity-Stamped Audit for Compliance and Forensics
Every JIT session resolves the “who was the admin?” problem with a single, attributable timeline — the request, the approval, the role and namespace granted, the duration, the commands run, and the auto-revocation — all tied to one named human and all landing in the customer’s own GCP storage. For ISO 27001 and SOC 2 evidence, and for incident investigation, this converts “the cluster-admin role did it” into “this engineer ran this command at this time, under this approved request.”
One Engine Across Every Surface
Because this team is GCP-heavy with an Azure footprint, VMs alongside GKE, and a MySQL data tier, the same JIT engine that governs GKE also brokers cloud console access across GCP and Azure, VM access with session recording, and database access. One policy model, one approval flow in Slack, one audit trail across all surfaces — rather than a separate access tool per surface with fragmented logs.
Why Standing Kubernetes Access Is Especially Dangerous
Kubernetes access differs from cloud console access in one critical way: the blast radius of a single command can be larger and faster than almost any IAM action. kubectl delete ns production removes every pod, service, secret, and configmap in that namespace instantly. kubectl exec into a pod with a mounted service-account token hands an attacker whatever that service account can reach — which, in a cluster running financial workloads, can be a direct line to sensitive systems.
Standing cluster-admin on a production GKE cluster is not merely “elevated access.” It is often the single highest-risk standing privilege an engineering team holds — more dangerous than console access because the damage is immediate and hard to roll back. For a team where GKE is the dominant surface, that made Kubernetes JIT the highest-priority control to put in place, and the control had to be fast enough that engineers would never want to route around it. (See why Kubernetes security matters for the broader picture.)
Platform Impact
| Metric | Before | After |
|---|---|---|
| Standing cluster-admin bindings | Multiple engineers | Zero |
| Time to cluster access | Minutes to hours (manual RBAC) | Under 60 seconds |
| Audit attribution | Shared federated identity | Real human identity |
| Private cluster access | VPN / bastion with broad reach | Scoped outbound tunnel |
| Kubeconfig rotation | Never (breaks setups) | Not needed — ephemeral per session |
| RBAC enforcement | Aspirational, overridden in practice | Enforced per request |
| Compliance evidence | Cross-reference two log systems | Single attributable timeline |
From GKE to Every Other Surface
A FinTech that fixes Kubernetes access first has made the sharpest risk reduction available to it — but it has also built the foundation for everything else. The same request → approve → time-boxed grant → auto-revoke lifecycle extends to GCP and Azure consoles, to the VMs running alongside GKE, and to the MySQL databases behind the application tier. Build the governance model once on the surface that matters most, and carry it forward without adopting a new tool each time the access surface grows.
For a team under four compliance frameworks with a lean security function, that is the difference between buying a Kubernetes access tool and buying an access-governance platform that happens to start with the surface where the risk is highest.
Running GKE as Your Primary Compute Layer?
If Kubernetes is where most of your engineering happens, and your access model still rests on standing kubeconfigs, shared cluster-admin, and manual RBAC — Cloudanix Kubernetes JIT gives engineers sub-60-second, scoped access (even to private GKE control planes) with the time-bound, identity-stamped, auto-revoked controls your compliance obligations require.
Book a Free Assessment to see Kubernetes JIT working with your GKE clusters — including private control planes — in a single session.
Related Resources
- What is Google Kubernetes Engine (GKE)?
- Importance of Kubernetes Security
- JIT Access for EKS Cluster RBAC: Eliminating Standing Kubernetes Privileges
- Implementing JIT Access in AWS, Azure & GCP: Complete Guide
- What is Zero Standing Privilege?
- Kubernetes Security Checklist 2026: Hardening EKS, AKS & GKE
- Multi-Cloud CSPM for a GCP-Heavy FinTech with GKE Workloads
