Why open source infrastructure access is different for SaaS engineering teams
A SaaS engineering team that reads its SOC 2 report or a customer security questionnaire and finds shared SSH keys, a VPN with a bastion host, and production sessions nobody recorded has a access problem that is both technical and contractual. The fastest fix for most of these teams is certificate-based access with short-lived credentials tied to a named identity, and Teleport is the usual starting point because one open-source platform can cover SSH, Kubernetes and databases. The first decision, before any architecture work, is the edition: Teleport's Community Edition license is limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so the license threshold decides early whether the team can build on the free edition or must budget for Enterprise features such as just-in-time access requests.
SaaS access differs from other sectors for three reasons. First, customer assurance drives the evidence. Under the AICPA 2017 Trust Services Criteria, a SOC 2 examination tests the common criteria CC1 to CC9 for every report, and access controls over production are among the most sampled areas. Customers also ask for proof of who touched production data and when, so session recordings and access reviews are sales artifacts as much as security controls. Second, engineers reach production daily, often many times per shift. Access that is slow to request gets bypassed through shared credentials, so the design has to make the approved path the quick path. Third, multi-cloud and Kubernetes sprawl multiply the number of entry points. Each cloud account, cluster and database adds another place where a standing credential can live.
Before choosing a platform, confirm three things with your own environment: your current employee count and trailing revenue against the Community Edition limits, which SSO provider your engineers already use (Community Edition single sign-on is limited to GitHub, while Enterprise supports Okta, Microsoft Entra ID, Google Workspace, OIDC and SAML), and whether auditors in your next SOC 2 window will expect access requests to be approved and logged, which Community Edition does not offer through the web interface. Map each of these to a written decision, because switching editions later changes the rollout plan, the SSO configuration and the evidence you can produce.
Which requirements shape a SaaS production access build
This table maps the requirements most SaaS companies meet during audits and customer reviews to concrete choices in a production access build. Read each row as a question to answer before configuring Teleport: what the requirement asks, and which identity, session or approval control your evidence will depend on. Use it to decide early which controls must exist in the platform and which must be run as process.
| Requirement | Source | What it means for the access build |
|---|---|---|
| Security common criteria CC1 to CC9 | AICPA 2017 Trust Services Criteria; applies to every SOC 2 report. A Type 1 report describes controls as of a date, while a Type 2 report tests whether they operated over a period. | Every engineer, service account and vendor needs a unique identity, MFA at login, and access limited to the roles they need. Type 2 auditors sample logs across the period, so session recordings, approvals and access reviews must be retained continuously, not set up just before the audit. |
| Documented change approval for production access | SOC 2 common criteria on change management and logical access, as your auditor interprets them for your system description | Production access requests need a recorded requester, approver, reason and expiry. Confirm with your auditor whether Teleport access requests in your edition produce evidence in the form they expect, or whether tickets must be linked manually. |
| Customer contract and processor obligations under GDPR Article 28(3) and Article 32 | Regulation (EU) 2016/679, Articles 28 and 32 | Where you process EU personal data for customers, your contract must limit processing to documented instructions and require appropriate security measures. Engineers reaching customer databases through the bastion should be covered by documented access rules, and session logs should be stored where your data processing terms allow. |
| Switching rights for EU customers under the Data Act | Regulation (EU) 2023/2854, Articles 23, 25 and 50; Article 29 on switching charges | If you serve EU customers as a data processing service, customers may need to move to another provider or on-premises infrastructure. Keep infrastructure access documented and portable, avoid designs that lock access records into one proprietary service, and confirm with counsel which switching terms apply to you. |
| MFA for any individual accessing information systems (optional, only if you serve financial institutions) | FTC Safeguards Rule, 16 CFR 314.4 | Where your customers are covered financial institutions, expect them to ask for MFA on all access to systems holding their data, plus logging of authorized user activity. Teleport's SSO and MFA settings must be configured for every access path, including Kubernetes and databases. |
| Unique user identification and audit controls (optional, only if you handle ePHI) | HIPAA Security Rule, 45 CFR 164.312 | If you host or process electronic protected health information for covered entities, each person needs a unique identity and activity in systems containing ePHI must be recorded and examined. Shared SSH keys and shared database accounts cannot satisfy this, so certificate-based identities with session recording become the baseline. |
Which open source platforms fit SaaS infrastructure access
A SaaS engineering team replacing shared SSH keys, VPN and bastion access usually needs a small set of components, not one product. The cards below separate the access proxy from the identity provider, secrets store, governance layer and fallback gateway, and flag the licensing questions that decide which edition fits.
Teleport for server, cluster and database access
Teleport combines an identity-aware access proxy, a certificate authority that issues short-lived certificates, and a tunnel to resources behind the firewall, packaged as a single Go binary. It covers SSH, Kubernetes, PostgreSQL, MySQL, MongoDB, CockroachDB, internal web apps, MCP servers and Windows hosts. For SaaS teams, check which protocols your production estate actually needs, whether session recording and access requests are in the edition you can license, and how the API module (Apache 2.0) and the rest of the code (AGPL-3.0) affect your build and distribution.
Keycloak, authentik or ZITADEL for SSO and MFA
Teleport needs an identity provider to authenticate people, and the choice here sets how MFA, group claims and offboarding work across every engineering tool. Keycloak supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, authentik is MIT licensed outside its enterprise directory, and ZITADEL lists passkeys and SCIM. Confirm which connectors your Teleport edition accepts, since Community Edition single sign-on is limited to GitHub.
OpenBao or Infisical for remaining secrets
Certificates from Teleport remove most shared credentials, but database passwords, third-party API keys and CI tokens still need a home. OpenBao is MPL-2.0 and hosted under the OpenSSF, while Infisical is MIT except for ee directories with a separate enterprise license. Check which secret types you must rotate, who approves access to them, and whether the license terms of the enterprise paths match your plans.
midPoint when joiner-mover-leaver rules outgrow scripts
midPoint is an identity governance platform under EUPL 1.2 or later, and its 4.8 Curie release is supported until October 17, 2028. It becomes relevant when access grants must follow HR changes, team moves and offboarding across many systems, and when access reviews are needed. Most early-stage SaaS teams do not need it on day one. Confirm the number of source systems, the review cadence your customers ask for, and the staff who will maintain its mappings.
Guacamole or JumpServer as a fallback gateway
Browser-based gateways such as Apache Guacamole or JumpServer are useful only where Teleport cannot protect a system, such as a legacy appliance with a web console or a vendor tool that requires RDP through a browser. Keep the fallback narrow so it does not become a second access path with weaker controls. Confirm that its session recordings, approvals and credential injection meet the same standard as the primary proxy before you route anything through it.
HashiCorp Vault licensing caution
HashiCorp Vault 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. Teams that want a self-hosted secrets store with open source licensing should evaluate OpenBao or Infisical instead, and should have counsel review any BSL terms before building internal tooling on Vault. Ask any implementation partner to name the exact license file and version they will deploy.
How the Teleport Community Edition threshold changes the build
If your company is under the Community Edition limits, Teleport can serve as the core of your infrastructure access layer without a license purchase. The core model is the same in both editions: users authenticate through an identity provider, receive short-lived certificates, and reach SSH nodes, Kubernetes clusters and databases through one proxy. Your build work centers on configuring roles, resource labels and the proxy, rather than on procurement.
- Certificate-based access: Engineers receive short-lived certificates instead of holding shared SSH keys or long-lived Kubernetes tokens.
- Session recording with playback: The feature matrix lists session recording with playback in both editions, so you can record administrator sessions from the start.
- CLI-only role requests: In Community Edition, roles can only be requested through the CLI, so production access requests run through a command-line workflow.
- GitHub-only single sign-on: Community Edition limits single sign-on to GitHub, which may not match a company that runs its workforce identity on Okta, Entra ID or Google Workspace.
- Compatibility with OpenSSH: Teleport states it is fully compatible with OpenSSH servers and clients, which limits changes for engineers.
Before relying on this tab, confirm your current employee count and annual revenue against the license text, and check your identity provider model against the GitHub-only limit.
If your company is at or above the Community Edition limits, or expects to cross them during the build, the design must assume an Enterprise license. Enterprise adds the controls that most SaaS companies need once production access is audited: approvals, identity provider integration, lifecycle management and stronger session controls. Plan these into the architecture early, because retrofitting them after rollout changes role design and onboarding.
- Just-in-time access requests and reviews: Enterprise includes access requests and reviews as part of Identity Governance, so production elevation can be time-limited and approved.
- Enterprise single sign-on: Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML are supported in Enterprise.
- Moderated sessions and dual authorization: These session controls are listed as Enterprise features, which supports four-eyes approval for sensitive production sessions.
- Access lists, access reviews, locks and SCIM provisioning: These support joiner, mover and leaver processes at scale.
- Device Trust: Device checks are listed only in Enterprise, which matters if you require managed laptops for production access.
Confirm with Teleport which Enterprise features are included in the quote for your deployment model, because the feature matrix separates some capabilities by self-hosted or other deployment options.
Before any build starts, the edition decision should be documented, signed off and matched against the written scope. The Community Edition license ties eligibility to two measurable counts and includes an exception for designated critical security patch versions. Those points are easy to misread in a planning meeting, so check them against the license text rather than against a summary.
- Employee count: Confirm the number of employees against the wording of the Community Edition license, including how contractors and affiliated entities are treated, with your legal team.
- Annual revenue: Confirm annual revenue against the same license text and the period it measures, and set a review date for growth.
- Critical security patch exception: Check which patch versions are designated and whether the exception applies to the version you plan to run, since it does not extend general use.
- Written edition answer: Get the edition decision and the feature list it depends on in writing from Teleport or your reseller before the scope is signed.
- Growth trigger: Record which milestone (headcount, revenue or a required SSO integration) forces a move to Enterprise, and budget that path in the scope.
Ask your implementation partner to put the edition answer, the license reading and the growth trigger into the written scope before design begins.
How a SaaS team rolls out Teleport without breaking deploys
The sequence moves a SaaS team from shared SSH keys, VPN and bastion access to certificate-based, recorded access in controlled stages, so each stage has a clear output and deploy pipelines keep working throughout.
Inventory keys, bastions, databases and clusters
The platform or infrastructure lead, with input from each engineering team, lists every server group, bastion host, database, Kubernetes cluster and CI job that relies on shared SSH keys, static Kubernetes tokens or VPN routes. For each item, record who uses it, which service accounts and deploy pipelines depend on it, and whether it is production. The output is a shared access register that becomes the migration backlog. The step is done when every production path has an owner and a named dependency list.
Confirm the edition and license before building
Before any configuration, the team checks the Teleport Community Edition license against its own headcount and annual revenue, and compares the features it needs (single sign-on, access requests, session moderation, Device Trust) with the feature matrix. If the company is at or above the Community Edition thresholds, or needs Enterprise-only features, the commercial edition is chosen now, because switching later changes the deployment. Legal or finance signs off on the decision in writing. The output is a one-page edition decision that names the features each role relies on.
Integrate the identity provider and enforce MFA
The identity team connects Teleport to the company's identity provider, mapping groups to roles such as read-only, deploy and database admin. Multi-factor authentication is enforced at login for every user, and engineers are removed from any local account path that bypasses it. Confirm which single sign-on connectors the chosen edition supports before testing. The step is done when a test user can log in through the identity provider, receives a short-lived certificate, and is denied any role their group does not grant.
Pilot on non-production SSH and one cluster
The team enrolls a non-production SSH group and one non-production Kubernetes cluster, then runs the existing deploy scripts and CI jobs against them through Teleport machine access. Failures are logged and fixed in the role mapping or pipeline configuration, not by reinstating shared keys. Engineers use the new login path for normal work for a fixed trial period agreed in advance. The output is a pilot report listing each deploy path tested, each failure and its fix, and a go or no-go decision for production.
Migrate database and production access with break-glass
Database access (such as PostgreSQL or MySQL) and production SSH and Kubernetes access move next, one group at a time, with each group's roles reviewed by its owner. Production write access is gated by access requests with named approvers, and a break-glass path is designed in advance, with its own strong authentication, a named custodian, and an alert every time it is used. Test the break-glass path before it is needed. The output is a runbook entry per system and a tested break-glass procedure.
Retire shared keys and VPN paths
Once each group has run on Teleport through at least one full release cycle of its deploy pipeline, the team revokes the shared SSH keys, deletes static Kubernetes tokens, and removes the VPN and bastion routes that no longer carry traffic. Each removal is checked against the register from the first step so nothing is orphaned. The output is a removal log with date, owner and verification for each credential and route, which also serves as evidence for later control reviews.
Set recording retention and SIEM forwarding
The security team defines how long session recordings are kept, where they are stored, who can play them back, and how access to recordings is itself logged. Teleport audit events are forwarded to the company's SIEM, and alerts are tested for sample events such as a session started outside business hours or a production role granted outside a request. Retention periods are set by the team's own policy and any applicable framework, which should be confirmed with the compliance lead. The output is a retention policy and a tested event feed.
Operate with a runbook and a Teleport upgrade plan
The team publishes an operating runbook covering onboarding and offboarding, access request handling, break-glass use, certificate troubleshooting and recording review. An upgrade plan ties Teleport version changes to a test environment and to the Kubernetes and identity provider versions it depends on, and it is reviewed against each Teleport changelog entry before rollout. The output is an owned runbook and a documented upgrade procedure, with a named person responsible for each release decision.
Which evidence SOC 2 and customer audits ask for from access tooling
This table maps each access evidence item a SaaS company typically shows to a SOC 2 auditor or customer security team to the system that produces it and what the auditor samples. Read it as a checklist to design logging and retention before the observation window starts. DeployOpen prepares systems and evidence for assessment, but independent auditors issue the report.
| Evidence item | Produced by | What the auditor samples |
|---|---|---|
| User access list per system | Teleport roles and user lists, IdP group export, Kubernetes RBAC bindings | A dated list of who can reach each production server, database and cluster, matched to approved owners |
| Certificate issuance and expiry logs | Teleport audit log for short-lived user and host certificates | Sample certificate issuances tied to a named identity, with lifetimes showing automatic expiry rather than standing keys |
| Session recordings and playback | Teleport session recording (available in Community and Enterprise), SIEM retention of the session audit events | Recordings for sampled privileged sessions, showing who connected, which resource, and that recording was enabled |
| Access request and approval records | Teleport Enterprise just-in-time requests and reviews, or ticketing system approvals for Community deployments | Request, approver and time-bound grant for sampled production elevations, including the approver being independent of the requester |
| Access reviews | Teleport Enterprise access lists and reviews, IdP review campaigns, exported review sign-offs | Completed review cycles covering production roles, with removals actioned and dated |
| Offboarding evidence | IdP deprovisioning log, Teleport user lock or deletion event, Kubernetes RBAC removal | Leavers sampled from HR records, matched to disabled IdP accounts and revoked infrastructure access within the stated window |
| MFA enforcement settings | IdP authentication policy export, Teleport authentication connector and second factor configuration | Current settings plus change history, and sample logins showing a second factor was required |
| Change records for access policy | Git history for policy-as-code, ticketing system change tickets, Teleport audit events for role edits | Sampled changes to roles or MFA settings, showing a requester, a reviewer and a timestamp before the change took effect |
What Kubernetes access and version support mean for the design
Kubernetes does not store normal users as API objects, so a Teleport deployment cannot simply hand out a Kubernetes account. The API server authenticates users with X.509 client certificates, bearer tokens (including OpenID Connect and JWT), webhook token authentication or an authenticating proxy. Your design needs to decide which of these Teleport's short-lived certificates or identity provider tokens will feed into, and then map the identity groups from your SSO provider to Kubernetes RBAC roles. Confirm with your platform team which authentication method your managed or self-built clusters accept, because a mismatch here usually shows up as access that works for engineers in a test cluster and fails in production.
Kubernetes stores Secrets unencrypted in etcd by default, so anyone who can read the etcd data directory or a backup has the credentials. Before you rely on a bastion for cluster access, configure encryption at rest for Secrets, restrict list and watch on Secret objects to a small set of service roles, and consider an external store through the Secrets Store CSI Driver for high-value credentials. Access requests in Teleport control who reaches the API server, but they do not limit what a role can read once inside, so RBAC and etcd encryption remain your responsibility.
Plan upgrades around the support window. The Kubernetes project maintains the three most recent minor releases, and as of September 2026 these were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Releases arrive about three times a year, so a cluster can fall out of support within a year of its last upgrade. The version skew policy requires the kube-apiserver to be upgraded one minor version at a time, ahead of controller managers, schedulers and kubelets, which can be up to three minor versions older. Ask your Teleport and Kubernetes implementation partner to test the access path after each control-plane upgrade, and confirm the Teleport version you run supports the Kubernetes minor version in your fleet.
Questions SaaS teams ask before hiring an implementation partner
What does an open source infrastructure access project cost, and what drives the price?
The cost comes from three places: the software, the engineering work to deploy and integrate it, and the staff who run it afterward. Teleport's open source pieces carry no license fee for organizations inside the Community Edition terms, but Teleport's pricing page says commercial customers pay for active users and protected resources, and it does not publish prices, so confirm the commercial terms directly with the vendor. Implementation cost rises with the number of servers, Kubernetes clusters and databases you bring under access control, the identity provider you connect, and how many approval workflows you need. Ask any partner for a fixed-scope quote built from a written list of systems, deliverables and timelines. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and the quote follows from that scope.
How long does a Teleport rollout take, and what sets the pace?
The pace is set by how many resources and identity sources you migrate, how much of your current access is undocumented, and how quickly teams can change their habits. A typical sequence starts with the identity provider and a pilot group, then moves SSH nodes, Kubernetes clusters and databases in waves, and only then retires shared keys and the old bastion. Teleport supports certificate-based access with automatic expiration, which removes the need to hunt down static keys, but finding those keys takes time. Ask for a timeline in the written scope that lists each wave, the acceptance test for each wave and the change window needed for production systems. No duration is given here because none is supplied for this type of project.
What does our engineering team have to provide before the work starts?
You need to provide an inventory of the systems in scope, named owners for each system, access to the identity provider and a test environment that mirrors production. Your team also has to decide the access model: which roles can reach which hosts, which actions need an approval, and who signs off on break-glass access. Security and platform staff should confirm where the Teleport Auth and Proxy services will run, how they reach your databases and clusters, and which network paths stay open during migration. Ask a partner to list these inputs in the scope document so that delays are visible before the project starts.
Can our own engineers run Teleport without an implementation partner?
Yes, a capable platform team can deploy Teleport, since it ships as a single Go binary that can run as a Linux daemon or as a Kubernetes Helm deployment. The harder work is the design: role mapping, session recording retention, approval paths, high availability and integration with your identity provider and logging stack. Most teams underestimate the migration of existing shared keys and the proof that old access has been removed. A partner adds value where you lack that experience or lack time, and an internal team adds value where it already runs similar platforms. Decide with a written inventory of skills and a pilot, and keep your own staff on the runbooks so the knowledge stays in the company.
Which Teleport features need an Enterprise license, and how do we handle that?
The Teleport Community Edition license makes distributed builds available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Teleport's feature matrix limits Community Edition single sign-on to GitHub, and it places just-in-time access requests, access lists, access reviews, moderated sessions, dual authorization and Device Trust in Enterprise. Session recording with playback is available in both editions. Before you choose, check your headcount and revenue against the license, list the features your design needs, and ask the partner to map each requirement to an edition in writing. Your legal team should confirm the license terms for your situation.
How do we keep the access platform, Kubernetes and etcd upgraded?
Plan upgrades on three tracks: the access platform, the Kubernetes clusters it protects and the etcd data store behind them. Kubernetes publishes roughly three minor releases a year, and the project maintains only the three most recent minor versions, so an unpatched cluster falls out of support quickly. The version skew policy requires you to upgrade kube-apiserver one minor version at a time, before other control plane components and kubelets. Teleport publishes frequent point releases, so schedule a recurring patch window and test each one in staging. Ask the partner for an upgrade runbook, a backup and restore test for etcd, and a retainer or internal ownership model for ongoing patching. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
What to ask an implementation partner about SaaS access
Start with the license, because it decides the edition before any architecture work begins. Ask the partner to state in writing how the Teleport Community Edition license applies to your organization, including headcount and revenue at the time of deployment and at each planned growth point, and who is responsible for re-checking that position when the company crosses the threshold. The answer should name the edition for each component (SSH, Kubernetes, database access), identify which features you depend on that are Enterprise only, such as access requests, dual authorization and SCIM provisioning, and show the cost of those features in a quote rather than assuming them. Ask for a written list of features that will be unavailable on the chosen edition, so the gap is visible to your leadership and not discovered during an audit.
Next, test the operating model. A good partner describes production change control in concrete terms: which roles can approve a just-in-time request for production, how emergency access is granted and revoked under break-glass design, where the break-glass account credentials are held, how each use is alerted and reviewed, and how certificate lifetimes are set for human sessions versus automation. Ask what certificate TTL is configured for each role and who can change it. Ask how the partner maps your controls to SOC 2 Common Criteria CC6 and CC8 evidence, meaning which Teleport audit events, role definitions, access request records and access reviews an examiner will sample, and what is still a manual process. Require coverage for Kubernetes and etcd backups, including snapshot schedules, restore testing and who holds the encryption keys for Secrets. Finally, ask how upgrades are handled against Teleport releases such as 18.11.4: the test environment, the rollback plan, the change record and the support window for your version.
How DeployOpen scopes and builds SaaS infrastructure access
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts or data centers. For SaaS engineering teams replacing shared SSH keys and a VPN plus bastion, we start from a written scope that fixes which servers, clusters and databases come under certificate-based access, and which edition of the chosen platform that scope requires.
How we scope
- Inventory servers, Kubernetes clusters and databases that engineers reach today, with the owners of each.
- Confirm the Teleport edition against your employee count and annual revenue before any build work starts.
- Agree in writing which production access requests, approvers and session recording rules are in scope.
How we build
- Deploy the access proxy and certificate authority on your infrastructure, with SSO wired to your identity provider.
- Configure short-lived certificates, role mappings for SSH, Kubernetes and database resources, and recorded sessions.
- Test access paths, expiry behavior and session playback against the scope before any engineer relies on them.
How we hand over
- Document architecture, role definitions, request workflow and break-glass steps for your platform team.
- Deliver runbooks for onboarding, offboarding, certificate rotation and session recording retention.
- Walk through the evidence your SOC 2 or ISO 27001 auditor is likely to sample, such as access lists and session logs.
How we support
- Support is available as a retainer for upgrades, patching, backups and changes to roles and resources.
- Plan upgrades with you as Teleport releases appear, and confirm each change in a staging environment first.
- Run continuous security testing of the access layer if your scope includes it, with findings tracked to closure.
