Cluster access without long-lived credentials

A developer leaves a project. Their portal account is disabled, but a copied cluster credential still works. If that is possible, the access review has missed a path into the system.

The problem is a standing credential that has become detached from the person using it. A better access design keeps identity, permissions, and credential lifetime connected.

The kubeconfig file is not necessarily the secret

A kubeconfig describes how a client reaches a cluster and authenticates. It can contain credentials, but it can also direct the client to a login mechanism. Removing the file is not the objective. Removing unmanaged, reusable access is.

With federated login, the user authenticates through the identity system, and the cluster evaluates the resulting identity and permissions. Command-line access can still use a configuration file without embedding a long-lived cluster secret.

Make an access grant easy to explain

An administrator should be able to answer three questions: which person or team has access, to which cluster, and with which permissions? Membership in an organization should not quietly grant access to every resource it owns.

Moncho maps team access grants to cluster role-based access control. One federated login can reach the organization’s permitted clusters, and multi-factor authentication is mandatory for financial-sector tenants.

Revocation deserves its own test. Remove a grant and check both a new login and an already-issued token. Token expiry and session handling affect how quickly an access change takes effect; a central identity provider alone does not establish that timing.

Keep the browser console tied to the user’s authority

A portal console can make resource inspection, logs, and terminal access convenient. It can also hide an overpowered shared credential behind an ordinary-looking page.

Moncho’s console forwards the tenant’s verified identity token to the cluster, where authorization is enforced. The console proxy does not use a standing cluster credential for these requests. That keeps the user’s grant relevant when they move from the portal into the cluster.

Inspect emergency access separately

When normal access fails, operators may need an emergency route. It should have a stated purpose, a narrow scope, an expiry, and a record that someone else can review.

Moncho’s platform-staff emergency access is time-boxed, scoped to one cluster, and requires a justification. Terminal output is recorded for review through a separate audit permission. Output-only recording avoids collecting a raw keystroke stream; it can still contain sensitive information printed by a command, so the recording needs careful access control.

Try the offboarding scenario

For an evaluation of Moncho’s access controls, create a limited grant, use it through the console, then revoke it. Check that another cluster remains out of reach throughout. Finally, review the emergency-access record and its expiry.

That exercise tests the part people depend on: whether the access they meant to grant is the access the system actually permits.