Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Conversational AI / SaaS Platform |
| Cloud Environment | AWS (primary), Azure (multi-region), GCP |
| Identity Provider | Keycloak (self-hosted SSO) |
| Workloads | 1,000+ VMs, Kubernetes (EKS) estate |
| Team | DevOps / Infrastructure team owns access and rollout |
| Focus Area | Just-In-Time access across cloud, VM, and Kubernetes |
The Situation: Interested in JIT, Protective of the Existing Identity Stack
The DevOps and infrastructure leadership on this team had been interested in Just-In-Time access for a while. The pain was familiar: standing access to cloud consoles, VMs, and Kubernetes that lingered long after the task that justified it was done, and no clean, time-bound way to grant and automatically revoke elevation.
But they had a well-founded reservation that stalls many JIT conversations: they already ran Keycloak as their single sign-on provider, and they were not about to rip it out or route their entire identity flow through a new gateway. Any access solution had to respect the identity stack they had already built and standardized on. “We like the idea of JIT, but we are not replacing our SSO” is the sentence that ends a lot of evaluations — because a surprising number of access tools assume they get to be the identity provider.
The Core Challenge
The team wanted zero standing privilege — time-bound, approval-gated access across cloud consoles, VMs, and Kubernetes — without displacing Keycloak or forcing engineers through a new proxy or portal. The access model had to sit on top of the existing SSO, not in front of it or instead of it.
Why “Don’t Touch My SSO” Is the Right Instinct
1. The IDP Is the Center of Gravity
An organization’s identity provider is wired into everything — application logins, group membership, provisioning, deprovisioning, audit. Replacing it or inserting a gateway in front of it is a high-blast-radius change that touches every authenticated flow. A team that has standardized on Keycloak has good reason to treat it as fixed infrastructure, not something a security tool gets to renegotiate.
2. Proxies and Gateways Add a Failure Surface Engineers Feel
Access solutions that work by proxying connections insert themselves into the runtime path. That means a new component that can break, add latency, and change the workflow engineers already know. The moment kubectl or an SSH flow behaves differently because of a security tool, adoption suffers.
3. Standing Privilege Is the Actual Risk — Not the Login
The team’s real problem was not authentication; Keycloak handled that fine. The problem was that once authenticated, engineers held standing entitlements to production consoles, VMs, and clusters that persisted whether or not they were being used. The fix needed to target the standing grant, not the login flow.
The Cloudanix Approach: An Access Layer After Authentication
Cloudanix Just-In-Time access is designed to operate on top of an existing identity provider rather than replacing it. It is IDP-native: it flips assignments at the identity layer for the duration of a granted window, rather than acting as a proxy or gateway in the connection path.
Keeps Keycloak as the Identity Provider
Cloudanix does not replace SSO. Engineers continue to authenticate through Keycloak exactly as they do today. Cloudanix sits after authentication as an access layer, granting and revoking time-bound elevation on top of the existing identity — so the IDP the team standardized on stays exactly where it is. This directly answers the “we are not replacing our SSO” objection: nothing about the identity provider changes.
One Lifecycle Across Cloud, VM, and Kubernetes
The same request → approve → time-bound grant → auto-revoke lifecycle applies across surfaces the team cares about:
- Cloud JIT: time-boxed AWS, Azure, and GCP console access, granted for a window and automatically revoked.
- VM JIT: short-lived, keyless access to VMs across the estate, with session recording available.
- Kubernetes JIT: ephemeral, role- and namespace-scoped access to clusters — including private EKS clusters — without handing out standing kubeconfig.
One engine and one policy model cover all three, rather than a different tool per surface.
Zero New Tools in the Engineer’s Path
Because Cloudanix flips assignments at the identity layer instead of proxying connections, engineers keep using the same SSO portal, the same kubectl, and the same access flows. JIT is effectively invisible until someone needs access they do not currently have — at which point they request it, it is approved, and it auto-revokes when the window closes. There is no new gateway to route through and no runtime component in the connection path.
Identity-Stamped Audit
Every request, approval, session, and revocation is logged against the real human identity — not just a shared role name — producing the zero-standing-privilege audit trail that auditors and cyber insurers increasingly ask for.
The Outcome
The team moved toward zero standing privilege across cloud consoles, VMs, and Kubernetes — with time-bound, approval-gated, auto-revoking access — while keeping Keycloak firmly in place as their identity provider. Engineers kept their existing workflows, and access became something requested and granted for a window rather than held indefinitely.
Key Results
✅ Keycloak Stays: JIT layers on top of existing SSO, no IDP replacement ✅ No Proxy in the Path: Assignments flipped at the identity layer, not a gateway ✅ One Lifecycle, Three Surfaces: Cloud, VM, and Kubernetes under one engine ✅ Zero New Tools for Engineers: Same SSO, same kubectl, same flows ✅ Standing Privilege Eliminated: Access granted for a window, auto-revoked ✅ Identity-Stamped Audit: Every grant tied to the real human identity
Want JIT Without Touching Your SSO?
If you run Keycloak (or any IDP) and want zero standing privilege without replacing your identity stack or proxying your engineers’ connections, Cloudanix JIT layers on top of what you already run.
Schedule a Demo to see JIT across cloud, VM, and Kubernetes on your existing SSO.
