Monopam · Kubernetes access

cluster-admin is root.
Treat it like root.

Most PAM products stop at the SSH port. Monopam brokers Kubernetes and OpenShift access the same way it brokers servers: short-lived credentials, per-call policy, recorded sessions — and your engineers keep using kubectl.

  • Native kubectl & oc
  • Verb / namespace / resource policy
  • JIT tokens, zero standing privilege
What you get

The cluster is a privileged surface. Front it.

A kubeconfig with cluster-admin is a domain-admin password that lives in dotfiles. Monopam replaces it with brokered, expiring, recorded access.

Native tools, brokered access

Engineers keep kubectl and oc. Monopam issues a short-lived kubeconfig pointing at its gateway, injects the real cluster credential, and the user never sees it.

  • Works with unmodified kubectl and oc
  • Short-lived kubeconfig per session
  • Cluster credentials injected, never exposed
  • Native oc login supported for OpenShift

Policy at the API-call level

Every request through the gateway is evaluated against verb, namespace, and resource rules — the same allow / approval / deny model you already run for servers.

  • Verb, namespace, and resource-level rules
  • Deny > approval > allow precedence, RBAC-aligned
  • Approval flows for sensitive operations
  • OpenShift API groups covered (Projects, Routes, DeploymentConfigs)

Zero standing privilege, by construction

Tokens are minted per session via the Kubernetes TokenRequest API and expire with it. No long-lived kubeconfigs in laptops, wikis, or CI variables.

  • Just-in-time tokens per session
  • Session never outlives the token
  • No shared cluster-admin kubeconfigs
  • Time-bound, approval-gated elevation

Recorded like every privileged session

kubectl exec is a privileged shell — Monopam treats it like one. Terminal sessions are recorded; every other API call lands in a structured audit trail.

  • kubectl exec / attach terminal recording
  • Structured JSON audit for API calls
  • Searchable trail per user, cluster, namespace
  • Same audit surface as RDP / SSH sessions
How it works

Three steps to governed cluster access.

01

Register the cluster

Connect Kubernetes or OpenShift and vault the cluster credential. The gateway becomes the audited path in.

02

Write the policy

Scope access by verb, namespace, and resource. Decide what runs, what waits for approval, and what never happens.

03

Hand out nothing

Engineers request a session and get a short-lived kubeconfig. Access expires on its own; the recording stays.

Ready to start managing
identities the right way?

Spin up a fully-loaded trial tenant in under five minutes. No credit card. No sales gate.