OPS ONLINETHREAT LEVEL: ELEVATEDSECTOR 04 · ACTIVE WATCHUPLINK NOMINAL · 99.997%MISSION CLOCKT+ 00:00:00DOCTRINE FM-26.A
Identity & AccessAnonymized

Zero-Trust Identity & Access Engineering

Identity-provider-integrated access to infrastructure, databases, and internal applications, enforced with hardware-token authentication and a custom PKI trust chain — no standing credentials, no shared secrets.

IndustryTechnology / SaaS
EnvironmentKubernetes, managed database cluster
Related ServiceInfrastructure Security Assessment
StatusDelivered

Initial problem

Access to infrastructure, databases, and internal tooling relied on a mix of standing credentials and shared secrets — a common pattern that scales poorly and leaves no clean audit trail of who accessed what, when, and why. The goal was a unified, identity-based access model with no standing privileged credentials anywhere in the path.

Scope

Engineering work

An access-proxy layer was integrated with the identity provider via OIDC, replacing standing credentials with short-lived, identity-bound sessions. The Kubernetes cluster was joined using projected service-account tokens validated against the identity provider's published key set — eliminating long-lived cluster credentials entirely.

Access control was structured around group-based defaults with per-application role scoping, plus a just-in-time access-request workflow for anything requiring elevated privilege — access is requested, reviewed, and time-boxed rather than standing.

Database access was wired into the same proxy layer for a managed PostgreSQL cluster, which required building a custom three-certificate-authority TLS trust chain and reissuing a replication certificate with the correct extended key usage to satisfy the database's client-authentication requirements — a non-trivial PKI problem that a default configuration doesn't handle.

Authentication was hardened to hardware-token-only (WebAuthn) with cross-platform attachment and device-model filtering, including debugging and resolving enrollment issues with a specific hardware security key model during rollout.

Deliverables

Validation

Access paths were tested end-to-end — infrastructure, cluster, and database — confirming no standing credentials remained in any path and that hardware-token enforcement could not be bypassed through a fallback authentication method.

Information intentionally withheld: client name, specific vendor product names and versions, internal service names, and exact network topology. Technical substance is representative of the actual engagement; identifying specifics have been generalized.

Rethinking Your Access Model?

Tell us your current access architecture and what's driving the change. We'll scope a realistic path to identity-based, no-standing-credential access.