BAMF: Open-Source Teleport Alternative for SSH and Databases

I found BAMF while evaluating self-hosted access platforms for SSH and database workflows. Its architecture was interesting enough to build in a lab with Keycloak, PostgreSQL, Redis, API, web, bridge, and agent components.

This article reports that evaluation. It does not certify BAMF as a drop-in Teleport replacement, production-ready privileged access management platform, Zero Trust implementation, or compliance solution.

Repository: mattrobinsonsre/bamf

Version and evidence boundary

The screenshots and observations came from the lab snapshot available around the original publication date. BAMF has evolved quickly since then. At this review, the upstream Go module lists release v0.8.6, published July 7, 2026, and its current README describes capabilities beyond the original lab.

Pin the exact release, Helm chart, container digests, CLI, agent, and configuration you test. Do not apply current documentation retroactively to an older screenshot, and do not assume a pre-1.0 release preserves every API, storage, or security contract.

What the lab actually demonstrated

The environment demonstrated:

• Browser authentication through a Keycloak OIDC integration.
• Resource registration through BAMF components.
• UI visibility constrained by the configured BAMF roles in the tested cases.
• SSH and PostgreSQL resources exposed through the tested access path.
• Authentication and access/session records visible in the UI.
• PostgreSQL query evidence when database auditing was configured.

It did not demonstrate multi-region failover, exhaustive protocol recording, every supported identity provider, bypass resistance, long-duration load, disaster recovery, external security assessment, or compliance effectiveness.

Architecture observed in the evaluation

The lab contained:

• Keycloak as the OIDC identity provider.
• PostgreSQL for BAMF metadata and a separate test target.
• Redis.
• BAMF API and web components.
• BAMF bridge and agent components.

Current upstream architecture describes a control plane for identity, certificates, policy, and audit, plus bridges and agents for the data path. Verify the exact topology for the selected release rather than copying the historical lab Compose layout.

Identity is only the first authorization layer

The tested OIDC flow was:

1. User opened the BAMF web application.
2. BAMF redirected the browser to Keycloak.
3. Keycloak authenticated the user.
4. BAMF consumed identity claims and applied configured roles.

SSO does not automatically provide least privilege. Validate:

• OIDC issuer, audience, redirect URI, signing algorithms, clock skew, and key rotation.
• MFA and account lifecycle at the IdP.
• Exact group/claim-to-role mapping and behavior when claims are missing or excessive.
• Session lifetime, revocation, logout, and emergency local access.
• Administrative separation between identity, BAMF policy, and target-system owners.

Test a user losing an IdP group while an access session is active. Authentication, authorization, certificate/session issuance, and target permissions can have different revocation timing.

BAMF does not replace target-system permissions

The original lab correctly exposed a critical boundary: BAMF did not create PostgreSQL users or decide database privileges for the target.

The effective authorization chain is:

IdP identity and MFA
  -> BAMF role and resource policy
  -> short-lived/session access mechanism
  -> target database, SSH, or Kubernetes authorization

The target remains the final authorization boundary. Use dedicated least-privilege database roles, SSH principals, and Kubernetes RBAC. A broad target credential behind a narrow BAMF UI is still broad access if the proxy, agent, or credential is compromised.

Current upstream documentation describes short-lived certificates and multiple tunnel/access modes. Verify which mechanism the selected resource type actually uses and whether any long-lived join token, database password, SSH key, CA key, or session credential remains.

Resource visibility is not bypass prevention

The UI showed resources permitted by the tested role configuration:

That proves a UI authorization case, not that direct network access is impossible. A controlled access platform requires network and identity enforcement that prevents users from reaching targets around the proxy.

Confirm that:

• Target firewalls accept administrative traffic only from approved agents/proxies or private paths.
• Direct SSH/database credentials are removed or tightly controlled.
• Agents and bridges authenticate each other and validate certificate chains.
• Join/bootstrap tokens are short-lived, single-purpose where possible, and monitored.
• DNS, load balancers, proxies, and TLS termination cannot route around policy.
• Break-glass access is separate, time-bounded, reviewed, and logged.

Audit and session-recording boundaries

The lab displayed identity and access/session history:

The PostgreSQL example also showed query history when PostgreSQL auditing was enabled:

These are different evidence sources. BAMF authentication/access logs can establish control-plane decisions. Database-native auditing can record database statements. Session recording depends on the protocol, access mode, client behavior, encryption termination point, and parser support.

Current upstream documentation describes SSH recordings, database wire-protocol auditing for selected engines, and HTTP auditing. Treat those as product claims until validated for the exact release and clients you operate.

Test at least:

• Interactive and non-interactive SSH, scp, sftp, port forwarding, and detached processes.
• PostgreSQL/MySQL prepared statements, transactions, failed statements, TLS, large queries, comments, encodings, and client variants.
• Whether credentials, query parameters, result data, headers, or terminal secrets enter recordings.
• Session termination, idle timeout, reconnect, bridge/agent restart, and partial recording.
• Clock synchronization, duplicate events, export failure, and missing-event detection.

Recording sensitive sessions increases data-exposure risk. Encrypt evidence, restrict playback/export, redact where supported, retain only what policy requires, and log access to the recordings themselves.

Availability and trust concentration

Centralized access reduces credential sprawl but concentrates trust. The platform's CA keys, metadata database, IdP integration, agents, bridges, and audit storage become security-critical.

Before production, validate:

1. CA and encryption-key storage, rotation, revocation, backup, and recovery.
2. PostgreSQL backup and point-in-time restore, including schema migration rollback.
3. API, bridge, agent, and Redis failure behavior.
4. Existing-session behavior during control-plane or bridge failure.
5. Capacity limits, connection churn, large transfers, and denial-of-service resistance.
6. Upgrade compatibility for CLI, agent, bridge, API, database schema, and recordings.
7. Monitoring for authorization failures, certificate issuance, join-token use, audit gaps, and privileged configuration changes.

An upstream claim that a tunnel survives a bridge failure should be verified through an application-level test and packet/session evidence in your topology. Do not convert a README feature statement into an availability objective.

Compliance contribution—not compliance status

PCI DSS 4.0.1 is the current published PCI DSS version at this review. BAMF evidence may contribute to controls involving restricted access, user identification/authentication, and logging/monitoring, commonly associated with Requirements 7, 8, and 10. Applicability and effectiveness must be assessed against the full requirement text, CDE scope, target permissions, MFA, retention, review, time synchronization, and control-failure detection.

For ISO/IEC 27001:2022, relevant areas can include access control, identity management, authentication information, access rights, logging, and monitoring activities. The older shorthand “A.9 and A.12” refers to the 2013 control structure and should not be presented as the current 2022 Annex A mapping.

No tool makes an organization PCI DSS or ISO 27001 compliant. An assessor needs policies, risk treatment, ownership, operating evidence, access reviews, incident handling, and proof that the configured technical controls work throughout the audit period.

“Zero Trust” needs measurable properties

Identity-aware access is consistent with Zero Trust principles, but the label alone proves nothing. Evaluate concrete properties:

• Explicit authentication and authorization for each resource/session.
• Short credential lifetime and revocation behavior.
• Device/workload context if required by policy.
• No implicit trust based only on network location.
• Continuous logging and detection of policy or delivery failure.
• Segmentation that prevents direct bypass.
• Least-privilege target authorization.

The original lab verified only part of this model.

Safer evaluation plan

Use a staged evaluation:

1. Pin release artifacts and verify checksums/signatures or provenance available upstream.
2. Deploy only isolated test targets and synthetic identities.
3. Configure SSO, MFA, roles, target permissions, and network anti-bypass controls.
4. Exercise allow and deny cases for every role/resource pair.
5. Validate session expiry, revocation, recording, audit export, and sensitive-data handling.
6. Fail each dependency and test backup/restore plus rollback.
7. Run performance and concurrency tests with representative protocols.
8. Review source, dependencies, container images, exposed services, and reported vulnerabilities.
9. Document tested scope and unresolved gaps before any production pilot.

When BAMF may be worth evaluating

BAMF may fit teams that want a self-hosted, open-source access control plane and are willing to operate and assess a fast-moving pre-1.0 project. It is especially interesting when native clients, agents, identity integration, and centralized evidence match the team's requirements.

It may be a poor fit when the organization needs established vendor support, independently validated compliance packages, a long compatibility history, specific hardware/device trust, or features that have not been demonstrated in the target environment.

Compare against Teleport, Boundary, cloud-native systems-management access, database-native identity, and managed PAM/ZTNA offerings using the same requirements and tests—not only feature tables.

Official references

• BAMF source and documentation
• BAMF Go module and current README
• PCI SSC document library
• PCI DSS v4.0.1 publication notice
• ISO/IEC 27001:2022

Conclusion

The BAMF lab showed a promising identity-aware access workflow with useful resource and audit visibility. The responsible conclusion is narrower than “open-source Teleport replacement”: BAMF is a candidate to evaluate against explicit SSH, database, identity, availability, audit, and recovery requirements. Pin the release, prevent bypass, preserve target least privilege, and treat every recording and compliance claim as something to prove in your own environment.