Robert Zsoter

Posted on Jan 8 • Originally published at Medium

Browser-Based kubectl Access: Managing Kubernetes Without Bastion Hosts

#architecture #devops #kubernetes #security

TL;DR

This article presents a browser-based kubectl access pattern
Designed for temporary, auditable cluster interaction
No bastion host, no SSH, no heavy management tools
All actions go through the Kubernetes API and RBAC
Not intended for daily production operations

Accessing Kubernetes clusters securely is a recurring challenge, especially in environments where SSH access, bastion hosts, or heavy management tools are discouraged.

In this article, I’ll walk through a browser-based kubectl access pattern that enables temporary, auditable interaction with a Kubernetes cluster, without relying on jump hosts or always-on management platforms.

This approach is intentionally not designed for daily production operations. Its value lies in controlled access, not convenience.

Why Kubernetes Access Is Hard to Get Right

Most teams rely on one or more of these approaches:

Bastion hosts with SSH access
kubectl configured on local laptops/machines
Full-featured Kubernetes management tools
Cloud-provider shell environments

All of them work, but they come with trade-offs:

credential sprawl
infrastructure overhead/increased attack surface
long-lived access paths/credentials
limited auditability/unclear audit boundaries

In regulated or security-sensitive environments, these trade-offs become unacceptable.

Yet teams still need:

break-glass access
short-lived troubleshooting
training and workshop environments
controlled/restricted support access

This is the gap the browser-based approach addresses.

What “Browser-Based kubectl” Actually Means

This pattern does not introduce a new Kubernetes UI.

Instead, it exposes a restricted web terminal that runs kubectl inside the cluster, using:

a dedicated ServiceAccount
strict RBAC permissions
native Kubernetes audit logging

All access happens through HTTP(S).

There is:

no SSH access,
no node-level access and login,
no user kubeconfig distribution.

High-Level Architecture

Conceptually, the flow looks like this:

User Browser
     |
     v
HTTP(S) (restricted)
     |
     v
Ingress / Load Balancer
     |
     v
Service
     |
     v
Web Terminal Pod
     |
     v
kubectl
     |
     v
Kubernetes API Server

Important details:

The terminal runs as a Pod inside the cluster
Authorization is enforced by Kubernetes RBAC
All kubectl actions result in Kubernetes API requests, which can be captured by Kubernetes audit logs depending on the audit policy
Access can be disabled instantly by removing the Pod or Service
No persistent external access paths remain

and represented in an ASCII diagram:

A few pictures, in operation

basic commands:
jump into pod and use kubectl exec command -within the defined namespace:

Security Model: Why This Is Auditable by Design

This pattern relies on layered security, not a single control.

Network layer

TLS termination
IP allowlists
No direct node exposure

Kubernetes authorization

Dedicated ServiceAccount
Least-privilege RBAC
Optional read-only mode

Auditability

Every action flows through the Kubernetes API
Native audit logs capture requests

Auditability: What Is (and Is Not) Logged

This is an important clarification.

kubectl commands themselves are not logged
Kubernetes API requests are

When a user executes a command:

kubectl get pods
kubectl describe deployment ...
kubectl apply -f …

The resulting API calls can be recorded in Kubernetes audit logs, depending on the configured audit policy.

This means:

Resource access and mutations are traceable
RBAC enforcement is preserved
No hidden or opaque access paths exist (unlike SSH sessions)

This pattern relies on Kubernetes’ native security model, not on custom logging logic.

⚠️ Important

This approach does not bypass Kubernetes security controls, it depends on them.

How This Compares to Other Access Patterns

This pattern is not a replacement, it fills a specific operational niche.

When You Should (and Should Not) Use This

Not recommended

Daily production operations
CI/CD automation
Persistent admin workflows

The limitations are intentional.They help prevent accidental misuse.

Lessons Learned

After experimenting with this pattern in real environments, a few things became clear:

Kubernetes RBAC remains the single most important control
Auditability improves when access paths are explicit
Removing SSH simplifies security reviews
Temporary access patterns reduce long-term risk

Convenience is easy to add. Removing access later is much harder.

Final Thoughts

Secure Kubernetes access is less about tools and more about boundaries.

Browser-based kubectl access provides a minimal, auditable, and intentionally constrained way to interact with a cluster when traditional approaches are unavailable or undesirable.

Used correctly, it solves a real problem, without becoming a new one.

Reference Implementation

The repository demonstrating this pattern is available here: https://github.com/zsoterr/k8s-web-terminal-kubectl

And what's next?

I am planning a number of modifications and additions. You can find more information about these in README.md in the GitHub repository.

Note

This DEV.to post is a concise version of a longer, experience-based guide.

If you’re interested in deeper technical details, you can read it among My medium stories

About the Author

I’m Róbert Zsótér, Kubernetes & AWS architect. If you’re into Kubernetes, EKS, Terraform, AI and cloud-native security, follow my latest posts here:

LinkedIn: Róbert Zsótér
Substack: CSHU

Let’s build secure, scalable clusters, together.

Note: Originally published on Medium Browser-Based kubectl Access: Managing Kubernetes Without Bastion Hosts or Heavy Tools

DEV Community