SSH, Kubernetes, databases and RDP audit trails: where identity breaks

TL;DR: Trading firms often cannot tie privileged actions in SSH, Kubernetes, databases, and RDP back to a specific identity, leaving auditors to reconstruct evidence from fragmented logs, according to Teleport. The real problem is not log volume but attribution, because shared credentials and disconnected audit trails make compliance proof brittle.

NHIMG editorial — based on content published by Teleport: How to Make Trading Infrastructure Audit-Ready Across SSH, Kubernetes, Databases, and RDP

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

Questions worth separating out

Q: How should trading firms make privileged sessions audit-ready across SSH, Kubernetes, databases, and RDP?

A: They should design the access path so every privileged session is tied to one identity from authentication through session termination.

Q: Why do shared kubeconfigs and shared database users create compliance risk?

A: Shared credentials collapse attribution.

Q: What breaks when SSH keys are used as standing privileged access in trading environments?

A: Standing SSH keys create a gap between access and accountability.

Practitioner guidance

• Eliminate shared administrative credentials Assign per-user or per-machine access for SSH keys, kubeconfigs, database users, and RDP accounts so every privileged session can be tied to one accountable identity.
• Bind session logs to upstream identity events Correlate IdP authentication, access requests, and downstream session records so auditors can follow one identity chain instead of reconciling disconnected log sources.
• Record session activity at the command level Capture SSH commands, Kubernetes exec activity, database queries, and interactive desktop actions as replayable events rather than treating logon events as sufficient evidence.

What's in the full article

Teleport's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact log fields and session artifacts Teleport says auditors can use to trace SSH, Kubernetes, database, and RDP activity.
• The example audit records for Linux auth logs, Kubernetes API events, PostgreSQL queries, and Windows Security Event Logs.
• The mechanics of short-lived session certificates and how they change the evidence chain for privileged access.
• The case study details for Exness, including how hundreds of clusters are attributed to cryptographic identities.

👉 Read Teleport's analysis of audit-ready identity attribution across trading infrastructure →

SSH, Kubernetes, databases and RDP audit trails: where identity breaks?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →