Managing a homelab often starts simply: a few virtual machines, SSH keys, perhaps a Kubernetes cluster, and a VPN to reach everything remotely.

Then the environment grows.

In my case, my lab infrastructure includes multiple systems running on Proxmox and MicroK8s clusters. As the number of servers, services, databases, and Kubernetes workloads increases, managing privileged access using only SSH keys and administrator accounts becomes increasingly difficult to control and audit.

This raises an important question:

How can I control, centralize, and audit privileged access to my lab infrastructure without deploying an expensive enterprise PAM solution?

The answer I decided to explore is Privileged Access Management (PAM) using open-source software.

In this article, I will explain the problem I want to solve, what PAM provides, the open-source alternatives I considered—including Teleport—and why I decided to start my implementation with JumpServer.

The goal is not simply to install another application. The goal is to build a centralized access layer for my Proxmox, Linux, Kubernetes, and eventually database infrastructure.

What Is Privileged Access Management?

Privileged Access Management, commonly called PAM, is a security approach used to control and monitor access to sensitive infrastructure.

Privileged accounts can include:

• Linux root accounts

• sudo-enabled users

• Proxmox administrators

• Kubernetes administrators

• Database administrators

• Network device administrators

• Service and automation accounts

Without PAM, administrators often access infrastructure directly:

1Administrator
2      |
3      | SSH
4      v
5Linux Server
6

Or:

1Administrator
2      |
3      | kubeconfig
4      v
5Kubernetes API
6

This model works, but as infrastructure grows it creates several problems.

SSH keys can become distributed across multiple systems. Kubernetes credentials may exist on administrator laptops. Shared privileged accounts can make auditing difficult. Former users may retain credentials longer than expected.

There is also a fundamental auditing problem:

Knowing that someone authenticated is not the same as knowing what they did after authentication.

A PAM platform introduces a controlled access layer between users and infrastructure.

 1                    +------------------+
 2                    |   Administrator  |
 3                    +---------+--------+
 4                              |
 5                         MFA / SSO
 6                              |
 7                              v
 8                    +------------------+
 9                    |   PAM Platform   |
10                    |    JumpServer    |
11                    +------------------+
12                      /       |       \
13                     /        |        \
14                    v         v         v
15              Linux/VMs   Kubernetes   Databases
16                 SSH        MicroK8s   MySQL/etc.
17

Instead of allowing administrators to connect directly to every system, access can be routed through the PAM platform.

That gives us a central place for authentication, authorization, session auditing, and access policies.

Why PAM in a Homelab?

At first, implementing PAM in a homelab may sound excessive.

But a serious homelab can reproduce many of the same access-management problems found in production environments.

My environment contains Proxmox virtualization infrastructure and multiple MicroK8s systems used for testing DevOps, SRE, database, Kubernetes, and infrastructure automation technologies.

That makes it an ideal environment for experimenting with security practices such as:

• Zero Trust access

• Role-Based Access Control

• Multi-Factor Authentication

• privileged session auditing

• credential management

• least privilege

• Just-In-Time access

• centralized infrastructure access

It also solves a practical problem.

I don't want access to my infrastructure to depend on a collection of SSH private keys distributed across different machines.

I want something closer to:

 1Identity
 2   |
 3   v
 4Authentication + MFA
 5   |
 6   v
 7Authorization Policy
 8   |
 9   v
10PAM Gateway
11   |
12   +------> Proxmox hosts
13   |
14   +------> Linux VMs
15   |
16   +------> MicroK8s
17   |
18   +------> Databases
19   |
20   +------> Network devices
21

Every privileged connection should ideally have an identity, authorization decision, timestamp, target, and audit trail associated with it.

The Requirements for My PAM Lab

Before choosing a platform, I defined several requirements.

The solution should preferably be:

Open source

This is a lab environment, so I want something I can deploy, inspect, modify, destroy, and rebuild without depending on expensive licensing.

Self-hosted

The PAM control plane should run inside infrastructure I control.

SSH capable

Most of my Linux infrastructure is administered through SSH.

Kubernetes capable

MicroK8s is an important part of my lab, so Kubernetes access is a major requirement.

Database friendly

I also want the architecture to eventually cover privileged database access.

Auditable

Being able to determine who accessed a server and what happened during that session is one of the primary reasons for implementing PAM.

MFA capable

A compromised password should not automatically provide privileged infrastructure access.

RBAC capable

Users should only see and access infrastructure they are authorized to manage.

Automation friendly

As a DevOps/SRE environment, the platform should not prevent future Infrastructure as Code and automation integrations.

Why Not Just Use a Bastion Host?

A traditional SSH bastion is already a major security improvement.

For example:

 1Internet / VPN
 2      |
 3      v
 4+-------------+
 5| SSH Bastion |
 6+------+------+
 7       |
 8   +---+---+
 9   |       |
10   v       v
11Server A Server B
12

Firewall rules can restrict SSH so that infrastructure accepts management connections only from the bastion.

However, a bastion alone is not necessarily a complete PAM system.

We still need to answer questions such as:

• Who can access each server?

• Which privileged account can they use?

• Can access automatically expire?

• Is MFA required?

• Can sessions be recorded?

• Can commands be audited?

• Who changed a privileged credential?

• Can access require approval?

• Can Kubernetes and databases use the same access model?

This is where a PAM platform becomes significantly more interesting.

Open-Source Alternatives to Teleport

Teleport is probably one of the first platforms DevOps engineers encounter when researching modern infrastructure access.

Its certificate-based architecture and strong SSH and Kubernetes integration make it particularly attractive for cloud-native environments.

But I wanted to explore alternatives that could provide a strong self-hosted experience while giving me broader PAM capabilities.

The projects worth evaluating include:

JumpServer

JumpServer is an open-source Privileged Access Management platform designed around four major areas:

• Authentication

• Authorization

• Account management

• Auditing

It supports several infrastructure protocols and asset types, including:

• SSH

• RDP

• VNC

• Kubernetes

• MySQL

• PostgreSQL

• SQL Server

• Oracle

• Redis

• MongoDB

• network devices

• web applications

For my environment, the combination of SSH + Kubernetes + databases + session auditing makes JumpServer particularly interesting.

The Community Edition is self-hosted and GPL-3.0 licensed.

Teleport

Teleport approaches the problem from a slightly different direction.

It is particularly strong as an identity-aware infrastructure access platform based around short-lived certificates.

Its architecture works extremely well with:

• SSH

• Kubernetes

• databases

• web applications

• cloud-native infrastructure

For organizations heavily focused on Kubernetes and ephemeral identity-based access, Teleport remains a very compelling platform.

For this lab, however, I want to experiment with something closer to a broader traditional PAM model that also includes credential management and heterogeneous infrastructure.

Warpgate

Warpgate is another interesting open-source project.

It acts as a smart bastion host and focuses on providing controlled access without requiring agents on every target server.

Its lightweight architecture makes it particularly attractive for homelabs and smaller infrastructure environments.

Warpgate is worth investigating when the main objective is to replace a traditional bastion with something offering stronger authentication and auditing without deploying a larger PAM ecosystem.

Bastillion

Bastillion is a web-based SSH console and bastion solution.

It centralizes SSH access and SSH key management and can be useful when the primary requirement is controlling Linux server access.

Its scope is narrower than platforms such as JumpServer or Teleport, but that simplicity can also be an advantage for environments focused almost entirely on SSH.

HashiCorp Boundary

Boundary approaches privileged access through identity-based infrastructure connectivity.

Rather than distributing credentials and exposing infrastructure endpoints directly, Boundary brokers authorized connections to infrastructure.

Its architecture is particularly interesting for dynamic cloud environments.

However, its philosophy is closer to secure infrastructure connectivity than to a traditional all-in-one PAM platform.

JumpServer vs Teleport for This Lab

The choice is less about which product is universally better and more about which architecture I want to experiment with.

Teleport would be a natural choice if my primary goal were certificate-based SSH and Kubernetes access.

JumpServer becomes especially interesting because I want to experiment with PAM itself, including privileged accounts, credential management, session recording, infrastructure assets, and centralized auditing.

For that reason, JumpServer will be the first platform I implement in this lab.

Proposed PAM Architecture

My current lab is based around Proxmox.

Instead of installing JumpServer directly inside Kubernetes, I plan to initially keep the PAM control plane separate from the infrastructure it protects.

Conceptually:

 1                         USERS
 2                           |
 3                    HTTPS / SSH
 4                           |
 5                           v
 6                +----------------------+
 7                |      JumpServer      |
 8                |                      |
 9                | Authentication + MFA |
10                | RBAC / ACL           |
11                | Credential Mgmt      |
12                | Session Audit        |
13                +----------+-----------+
14                           |
15                 Management Network
16                           |
17       +-------------------+-------------------+
18       |                   |                   |
19       v                   v                   v
20+-------------+     +-------------+     +-------------+
21| Proxmox     |     | Linux VMs   |     | Databases   |
22| Hosts       |     | / Services  |     | MySQL/etc.  |
23+-------------+     +-------------+     +-------------+
24                           |
25                           v
26                  +------------------+
27                  | MicroK8s Cluster |
28                  +------------------+
29                    |      |      |
30                  Node1  Node2  Node3
31

JumpServer itself can run inside a dedicated VM or isolated service environment.

This creates an important separation:

The PAM system should not depend entirely on the infrastructure it is supposed to provide emergency access to.

For example, putting the only PAM instance inside the Kubernetes cluster it manages could create a circular dependency during a cluster outage.

For the first iteration, a dedicated Proxmox VM therefore makes more sense.

Network Segmentation

PAM becomes much more valuable when combined with network controls.

Instead of:

1Laptop ----------SSH----------> Server
2

the target architecture becomes:

 1Laptop
 2   |
 3   | HTTPS / SSH
 4   v
 5JumpServer
 6   |
 7   | SSH
 8   v
 9Server
10

Firewall rules can then progressively enforce:

 1Administrator VLAN
 2       |
 3       +------> JumpServer
 4                    |
 5                    +------> Management VLAN
 6                                  |
 7                                  +--> Proxmox
 8                                  +--> Linux
 9                                  +--> MicroK8s
10                                  +--> Databases
11

Eventually, direct administrative SSH access to managed systems can be blocked.

Only JumpServer—or a controlled emergency access path—should be capable of reaching management interfaces.

This turns PAM from merely another login portal into an actual security boundary.

A Critical Requirement: Break-Glass Access

There is one important exception.

A PAM platform must not become a single point of operational failure.

If JumpServer fails, I still need a carefully controlled method to recover the infrastructure.

That means maintaining a break-glass access mechanism.

For example:

 1Normal Access
 2
 3Admin
 4  |
 5JumpServer
 6  |
 7Infrastructure
 8
 9
10Emergency Access
11
12Authorized Admin
13  |
14VPN / Restricted Management Network
15  |
16Emergency Credential
17  |
18Infrastructure
19

Break-glass credentials should be heavily protected, rarely used, and monitored.

The objective isn't to eliminate emergency administrative access.

The objective is to ensure that it remains an exception rather than the normal way infrastructure is managed.

Integrating MicroK8s

Kubernetes access is particularly interesting because traditional kubeconfig files can effectively become privileged credentials.

An administrator may currently have:

1~/.kube/config
2

containing credentials capable of managing an entire cluster.

From a security perspective, that means the administrator's workstation becomes part of the privileged access boundary.

A PAM architecture can improve this model.

Instead of distributing long-lived administrative credentials, access can be centralized and associated with individual identities.

For my MicroK8s environment, I want to test:

1. registering the Kubernetes clusters in JumpServer;

2. mapping users and permissions;

3. limiting access to specific clusters;

4. testing kubectl workflows;

5. auditing Kubernetes sessions;

6. testing least-privilege access;

7. removing unnecessary administrative kubeconfig files from endpoints.

This will be one of the most important parts of the lab.

Integrating Proxmox

Proxmox creates another interesting PAM scenario.

There are actually two different privileged access surfaces.

The first is the Proxmox web/API layer.

The second is the underlying Debian/Linux operating system of each Proxmox node.

For the initial implementation, JumpServer can protect SSH access to the Proxmox hosts.

Later, I want to evaluate how the architecture can incorporate Proxmox authentication and API access without creating unnecessary dependencies.

The desired model is:

 1Administrator
 2      |
 3      v
 4Identity / MFA
 5      |
 6      v
 7JumpServer
 8      |
 9      v
10Proxmox Management Access
11

rather than distributing root SSH credentials across administrator machines.

Databases Are Next

Another reason I selected JumpServer for the first experiment is database access.

Database administrators frequently require privileged accounts such as:

1root
2postgres
3admin
4dba
5

Directly distributing these credentials makes accountability difficult.

Eventually, I want my lab to follow the same principle:

1Engineer
2   |
3   v
4PAM
5   |
6   +----> MySQL
7   +----> PostgreSQL
8   +----> Redis
9

This will be particularly useful when experimenting with Database Reliability Engineering practices.

What I Want to Achieve

The final architecture should allow me to answer questions that are surprisingly difficult in many environments:

Who accessed this server?

When did they access it?

Which privileged account did they use?

What commands were executed?

Who accessed the Kubernetes cluster?

Which database was accessed?

Can I revoke one person's access without rotating credentials across every server?

Can I require MFA before privileged infrastructure access?

If the platform can reliably answer those questions, then the PAM implementation is providing real value.

Implementation Roadmap

I plan to build the lab incrementally.

Phase 1 — Deploy JumpServer

Create a dedicated VM in Proxmox and deploy the JumpServer Community Edition.

Validate:

• HTTPS

• administrative access

• backups

• persistent storage

• MFA

Phase 2 — Linux Asset Management

Register Linux virtual machines and Proxmox nodes.

Configure users, privileged accounts, asset groups, RBAC, and SSH access.

Phase 3 — Audit

Enable and test:

• session recording

• command auditing

• authentication logs

• file-transfer auditing

Then intentionally perform several administrative operations and verify what information is recorded.

Phase 4 — MicroK8s

Register the MicroK8s clusters and test controlled Kubernetes access.

The objective will be to reduce the need for long-lived administrator kubeconfigs.

Phase 5 — Database Access

Add MySQL, PostgreSQL, and Redis lab environments and experiment with privileged database access.

Phase 6 — Network Enforcement

Once PAM access works reliably, progressively modify firewall policies so that privileged management interfaces can primarily be reached through JumpServer.

Phase 7 — Break-Glass Procedure

Document and test emergency access.

A recovery mechanism that has never been tested isn't really a recovery mechanism.

PAM Is More Than Installing JumpServer

One lesson is already clear before deploying anything:

Installing a PAM product does not automatically create a PAM architecture.

The software is only one component.

A proper implementation also requires:

 1Identity
 2   +
 3MFA
 4   +
 5RBAC
 6   +
 7Credential Management
 8   +
 9Network Segmentation
10   +
11Session Auditing
12   +
13Logging
14   +
15Break-Glass Access
16   +
17Operational Procedures
18

Without those controls, JumpServer would simply become a sophisticated jump box.

The real objective is to make privileged access intentional, identifiable, limited, auditable, and revocable.

Conclusion

As homelabs evolve into serious infrastructure environments, security architecture should evolve with them.

My Proxmox and MicroK8s environment has reached the point where managing access entirely through SSH keys, kubeconfig files, and privileged accounts is no longer the model I want to use.

Implementing PAM provides an opportunity to improve that architecture while experimenting with security patterns used in enterprise environments.

After evaluating several open-source approaches, I decided to start with JumpServer because it combines traditional PAM capabilities with support for the infrastructure I care about most: Linux, Kubernetes, databases, and heterogeneous systems.

The next step is where things become more interesting.

In the next article, I will build the JumpServer VM in Proxmox, deploy the Community Edition, configure HTTPS and MFA, and onboard the first Linux servers.

From there, we will progressively move toward a PAM-controlled Proxmox and MicroK8s environment.

The goal isn't simply to build a jump server.

The goal is to build a privileged access architecture.