How Teleport Works

FedRAMP Compliance

How Teleport Access Platform helps you to implement FedRAMP compliance for SSH, for Kubernetes, and for internal web applications.


Modern cloud software is complex. It requires multiple computers or data centers and teams of engineers for building and maintenance. Securing complex systems and avoiding data breaches requires making solid engineering decisions, but also having robust processes and procedures in place to address the unavoidable human factor.

Imagine a group of security professionals that compiled a list of common-sense recommendations that have been proven to work. A compliance standard is not an annoying and boring obstacle to productivity. Think about it as just one of those lists, that has a name and tied to a well-known group of authors.

FedRAMP authorization badge

What is FedRAMP?

FedRAMP (Federal Risk and Authorization Management Program) originally was proposed as a standardized approach for the federal government to adopt secure cloud services offered by the cloud providers. FedRAMP is a product of collaboration with multiple government agencies, such as NIST, GSA, DoD, and DHS.

While the original focus of FedRAMP was on cloud infrastructure (i.e. things like virtual networks, servers, and firewalls), eventually it was applied to cloud applications as well.

If your organization is currently or planning to offer cloud infrastructure or cloud software services to the federal government, you must have your software running on a FedRAMP-compliant cloud service provider (CSP) (either by building and managing your own infrastructure or by using an existing FedRAMP-authorized CSP), your software must be able to pass FedRAMP audit by an independent auditor, and your sponsoring federal agency must approve of the audit results and grant you an Authorization To Operate (ATO).

FedRAMP introduces its own vocabulary. The foundational document is called FedRAMP Security Assessment Framework (SAF). This high-level document covers the process of becoming FedRAMP compliant, but the technical details of “getting everything right” are described in a publication called Security and Privacy Controls for Federal Information Systems and Organizations NIST 800-53. It is maintained by the National Institute of Standard and Technology (NIST).

FedRAMP requirements described in NIST publications are labeled with the severity of their impact: low, moderate, or high. Each government agency is free to decide which level of compliance they desire. That is why terms such as “FedRAMP Moderate” are frequently used.

FedRAMP compliance for SSH and Kubernetes Access

Just like with SOC 2, NIST 800-53 groups all requirements into “families” with unique identifiers (ID):

ID Family ID Family
AC Access Control MP Media Protection
AT Awareness and Training PE Physical and Env. Protection
AU Audit and Accountability PL Planning
CA Security Assessment & Authorization PS Personnel Security
CM Configuration Management RA Risk Assessment
IA Identification and Authentication SA System and Services Acquisition
IR Incident Response SI System and Information Integrity
MA Maintenance PM Program Management

Obviously, families like personnel security or physical and environmental protection are outside the scope of Teleport, but Access control, Identification, Authentication, and Audit definitely fall within Teleport’s area of responsibilities.

FedRAMP Compliance for SSH and Kubernetes

The table below connects Teleport features to FedRAMP and SOC 2 requirements. It previews how to tighten SSH and Kubernetes access when preparing for FedRAMP and SOC 2 audits.

Teleport Controls FedRAMP Requirement NIST 800-53

To comply, Teleport must be integrated with an SSO provider such as Github, Okta, Google, etc.

Role-based access control (RBAC) for SSH and Kubernetes must be enabled*.

Teleport certificate-based SSH and Kubernetes authentication and audit logging comply with these requirements without additional configuration.

AC-02 Account Management
  • The organization employs automated mechanisms to support the management of information system accounts.
  • The information system automatically removes or temporary and emergency accounts.
  • The information system automatically disables inactive accounts.
  • The information system automatically audits account creation and modification.
  • The organization requires that users log out after a defined time-period.
  • The organization establishes, administers, and audits privileged user accounts in accordance with a role-based access scheme.
  • The information system enforces organization-defined usage conditions for organization-defined system accounts.
  • The organization monitors information system accounts and reports atypical usage.

Teleport supports robust Role-based Access Controls* (RBAC).

RBAC can be used to:

  • Control which SSH nodes a user can or cannot access.
  • Control cluster-level configuration (session recording, configuration, etc.).
  • Control which UNIX logins a user is allowed to use when logging into a server.
  • Control which user groups have access to Kubernetes resources.
AC-03 Access Enforcement
  • The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
  • Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, domains) in information systems

Teleport supports two types of users: from a local database and SSO-based accounts (Github, Google Apps, Okta, etc).

For local accounts, by default Teleport locks accounts for 20 minutes after 5 failed login attempts.:

For SSO-based accounts, the number of invalid login attempts and lockout time period is controlled by the SSO provider.

AC-07 Unsuccessful Logon Attempts

The information system:

  1. Enforces a limit of organization-defined number consecutive invalid logon attempts by a user during an organization-defined time period; and
  2. Automatically locks the account/node until released by an administrator; delays next logon prompt according to organization-defined delay algorithm when the maximum number of unsuccessful attempts is exceeded.

Teleport integrates with Linux Pluggable Authentication Modules (PAM).

PAM modules can be used to display a custom message on login using a message of the day (MOTD) module within the Session management primitive.

AC-08 System Use Notification

The information system displays to users an organization-defined notification message before granting access to the system that provides privacy and security notices consistent with applicable federal laws, executive orders, and other directives.

Teleport supports both a maximum number of connections (max_connections) and the maximum number of simultaneously connected users (max_users) under the connection_limits configuration parameter.

AC-10 Concurrent Session Control

The information system limits the number of concurrent sessions for each organization-defined account and/or account type to a defined number.

Teleport user sessions are automatically terminated when a certificate expires.

Users can exit a Teleport interactive session at any time by typing exit or sending an interrupt signal to the process for remote execution of a program.

Logout of all sessions (destroying credentials) indicates termination of all sessions and includes an explicit logout message.

AC-12 Session Termination

The information system automatically terminates a user session after organization-defined conditions are met and provides a logout capability for user-initiated communications sessions whenever authentication is used to gain access to information resources.

Teleport administrators create users with configurable roles that can be used to allow or deny access to system resources.

Teleport Proxy uses SSH or HTTP/TLS to authenticate and encrypt and transfer data between clients and servers.

Teleport encourages an architecture that requires all connections to go through the Teleport proxy.

AC-17 Remote Access

The organization: establishes and documents usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed. It authorizes remote access to the information system prior to allowing such connections.

  • The information system monitors and controls remote access methods.
  • The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.
  • The information system routes all remote accesses through managed remote access control points.

Teleport supports connecting multiple independent clusters using a feature called Trusted Clusters. After the establishment of a Trusted Cluster relationship between two clusters, one cluster “trusts” SSH and TLS certificates signed by the other and allows SSH connections from the other. When allowing access from one cluster to another, roles are mapped according to a pre-defined relationships to based on the scope of access.

AC-20 Use of External Information Systems

The organization establishes terms and conditions consistent with any trust relationships established with other organizations owning, operating, and/or maintaining external information systems. This allows authorized individuals to:

  1. Access the information system from external information systems; and
  2. Process, store, or transmit organization-controlled information using external information systems.

Teleport contains an Audit Log that records cluster-wide events such as:

  • Failed login attempts
  • The command that was executed (SSH “exec” commands)
  • Ports that were forwarded
  • File transfers that were initiated
  • Filesystem changes
  • Network activity that happened during an interactive user session
  • Recorded interactive user sessions
  • Events typically include information such as the type, time of occurrence, user or node on which they occurred, and a human-readable audit message.

    Teleport supports sending audit events to external managed services like DynamoDB where storage concerns are handled by the cloud provider.

AU-03 Audit and Accountability

The information system generates audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, the outcome of the event, and the identity of any individuals or subjects associated with the event.

AU-04 Audit Storage Capacity

The organization allocates audit record storage capacity in accordance with organization-defined audit record storage requirements.

Teleport requires valid x509 or SSH certificates issued by a Teleport Certificate Authority (CA) to establish a network connection for device-to-device network connection between Teleport components.

IA-03 Device Identification and Authentication

The information system uniquely identifies and authenticates organization-defined specific types of devices before establishing a connection.

Teleport maintains several unique identifiers:

  • The local users are required to be unique (unique username)
  • Teleport roles have unique names and tied to organization roles via SSO
  • Teleport identifiers for devices are unique randomly generated IDs (UUID)
IA-04 Identifier Management

The organization manages information system identifiers by:

  • Receiving authorization from organization-defined personnel to assign an individual, group, role, or device identifier;
  • Selecting an identifier that identifies an individual, group, role, or device;
  • Assigning the identifier to the intended individual, group, role, or device;
  • Preventing reuse of identifiers for the organization-defined time period; and
  • Disabling the identifier after an organization-defined time period of inactivity.

Teleport disconnects and releases all resources for non-active communications. In addition, session and idle timeouts and be specified to terminate and release resources for inactive connections.

SC-10 Network Disconnection

The information system terminates the network connection associated with a communications session at the end of the session or after the organization-defined time period of inactivity.

Teleport initializes cryptographic keys that act as a Certificate Authority (CA) to further issue x509 and SSH certificates. SSH and x509 user certificates that are issued are signed by the CA and are (by default) short-lived. SSH host certificates are also signed by the CA and rotated automatically (a manual force rotation can also be performed).

Teleport Enterprise builds against a FIPS 140-2 compliant library (BoringCrypto). In addition, when Teleport Enterprise is in FedRAMP/FIPS 140-2 mode, Teleport will only start and use FIPS 140-2 compliant cryptography.

SC-12 Cryptographic Key Establish and Management

The organization establishes and manages cryptographic keys for required cryptography employed within the information system in accordance with organization-defined requirements for key generation, distribution, storage, access, and destruction.

The organization produces, controls, and distributes symmetric cryptographic keys using NIST FIPS-compliant or NSA-approved key management technology and processes.

Teleport initializes cryptographic keys that act as a Certificate Authority (CA) to further issue x509 and SSH certificates. SSH and x509 user certificates that are issued are signed by the CA and are (by default) short-lived. SSH host certificates are also signed by the CA and rotated automatically (a manual force rotation can also be performed).

SC-17 Public Key Infrastructure Certificates

The organization issues public-key certificates under an organization-defined certificate policy or obtains public key certificates from an approved service provider.

Teleport SSH and TLS sessions are protected with SSH user and x509 client certificates. For access to the Web UI, Teleport uses bearer token auth stored in a browser token to authenticate a session. Upon user logout, SSH and TLS certificates are deleted from disk and cookies are removed from the browser.

SC-23 Session Authenticity

The information system protects the authenticity of communications sessions.

The information system invalidates session identifiers upon user logout or other session termination.

* RBAC is available for users of Teleport Enterprise.


Note that not all relevant NIST requirements are listed above.

As Teleport’s design goal was to provide sensible choices by default, it enforces most of the best practices automatically without additional configuration.

Easy to get started

Teleport is easy to deploy and use. We believe that simplicity and good user experience are key to first-class security.

Teleport consists of just two binaries.
  1. The tsh client allows users to login to retrieve short-lived certificates.
  2. The teleport agent can be installed on any server, database, application and Kubernetes cluster with a single command.
Download Teleport
# on a client$ tsh login
# on a server$ apt install teleport
# in a Kubernetes cluster$ helm install

Try Teleport today

In the cloud, self-hosted, or open source
Get StartedView developer docs