Teleport
FedRAMP Compliance for Infrastructure Access
- Edge version
- Version 17.x
- Version 16.x
- Version 15.x
- Older Versions
Teleport provides the foundation to meet FedRAMP requirements for the purposes of accessing infrastructure. This includes support for the Federal Information Processing Standard FIPS 140-2. This standard is the US government approved standard for cryptographic modules. This document explains how Teleport FIPS mode works and how it can help your company to become FedRAMP authorized.
Obtain FedRAMP authorization with Teleport
Teleport includes FedRAMP and FIPS 140-2 features to support companies that sell into government agencies.
Access controls
Control | Teleport Features |
---|---|
AC-02 Account Management | Audit events are emitted in the Auth Service when a user is created, updated, deleted, locked, or unlocked. |
AC-03 Access Enforcement | Teleport Enterprise supports robust Role-based Access Controls (RBAC) to: • Control which infrastructure resources 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. |
AC-07 Unsuccessful Logon Attempts | Teleport supports two types of users: local and SSO-based accounts (GitHub, Google Apps, Okta, etc). For local accounts, by default, Teleport locks accounts for 30 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-08 System Use Notification | 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-10 Concurrent Session Control | Teleport administrators can define concurrent session limits using Teleport’s RBAC. |
AC-12 Session Termination | Admins can terminate active sessions with session locking. Teleport terminates sessions on expiry or inactivity. |
AC-17 Remote Access | Teleport administrators create users with configurable roles that can be used to allow or deny access to system resources. |
AC-20 Use of External Information Systems | Teleport supports connecting multiple independent clusters using a feature called Trusted Clusters. When allowing access from one cluster to another, roles are mapped according to a pre-defined relationship of the scope of access. |
Audit and accountability
Control | Teleport Features |
---|---|
AU-03, AU-04, AU-12 Audit and Accountability – Content of Audit Records and AU-12 Audit Generation | Teleport contains an Audit Log that records cluster-wide events such as: • Failed login attempts. • Commands that were executed (SSH “exec” commands). • Ports that were forwarded. • File transfers that were initiated. |
AU-10 Non-Repudiation | Teleport audit logging supports both events as well as audit of an entire SSH session. For non-repudiation purposes, a full session can be replayed back and viewed. |
Configuration management
Control | Teleport Features |
---|---|
CM-08 Information System Component Inventory | Teleport maintains a live list of all nodes within a cluster. This node list can be queried by users (who see a subset they have access to) and administrators any time. |
Identification and authentication
Control | Teleport Features |
---|---|
IA-02 Concurrent Session Control | Integrates with SSO providers such as GitHub, Okta, Google, etc. Acts as its own SSO provider. Enforces the use of multi-factor authentication (MFA), including requiring per-session MFA. Supports PIV-compatible hardware keys, as well as connection and user limits. |
IA-04 Identifier Management | Maintains several unique identifiers: local users are required to be unique (unique username), roles have unique names and tied to organization roles via SSO, identifiers for devices are unique randomly generated IDs (UUID). |
IA-08 Identification and Authentication (Non-Organizational Users) | Teleport supports PIV-compatible hardware keys. |
IA-03 Device Identification and Authentication | 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. |
System and communications protection
Control | Teleport Features |
---|---|
SC-10 Network Disconnection | Teleport requires valid X.509 or SSH certificates issued by a Teleport Certificate Authority (CA) to establish a network connection for device-to-device network connection between Teleport components. |
SC-12 Cryptographic Key Establish and Management | 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. Teleport supports Hardware Security Modules (HSM). Teleport Enterprise builds against a FIPS 140-2 compliant library (BoringCrypto) is available. In addition, when Teleport Enterprise is in FedRAMP/FIPS 140-2 mode, Teleport will only start and use FIPS 140-2 compliant cryptography. |
SC-13 Use of Cryptography | 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-17 Public Key Infrastructure | Certificates Teleport initializes cryptographic keys that act as a Certificate Authority (CA) to further issue X.509 and SSH certificates. SSH and X.509 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. |
SC-23 Session Authenticity | Teleport SSH and TLS sessions are protected with SSH user and X.509 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. |
mTLS
Teleport implements mTLS for all communications between user clients and Teleport servers with several exceptions listed below.
Following successful authentication to SSO Identity Provider, Teleport issues the authenticated user x.509 client certificates signed by its own internal x.509 CA. Target Teleport services and clients require valid x.509 certificates and mTLS for all target SSH, K8s, database, and web application connections.
Inside the ATO boundary, mTLS is used for communication between the Teleport proxy and internal hosts running all protocols.
mTLS exceptions
- Teleport components provide read-only health check REST endpoints requiring only TLS.
- Teleport offers optional web UI for Windows Desktop and SSH. For web UI access, Teleport uses TLS + session cookie + bearer token with proxy. Teleport Proxy converts web sessions to mTLS to reach out to Teleport servers.
- Teleport offers optional SSH compatibility mode. In this mode Teleport dials target OpenSSH services using OpenSSH client certificates issued and signed by Teleport OpenSSH CA.
- The connection from the Teleport Proxy to Teleport desktop agent is mTLS, but the connection Teleport desktop agent to an RDP server is only TLS. The agent authenticates itself to the RDP server via a virtual PIV-compatible smartcard containing a user certificate issued by Teleport’s internal CA.
FIPS mTLS details
In FIPS builds, Teleport uses Go’s BoringCrypto-based networking stack for all protocols.
For a detailed list of cryptographic algorithms used in FIPS mode please consult Teleport FIPS documentation.
You also can follow the Installation instructions for Teleport Enterprise edition to download and install the appropriate FIPS-compliant binaries for your operating environment and package manager or from compressed archive (tarball).
For example, you can download and install from the compressed archive by running the following commands:
Teleport Enterprise customers can download the custom FIPS package from their[Teleport account](https://teleport.sh). Look for `Linux 64-bit (FedRAMP/FIPS)`.curl https://cdn.teleport.dev/teleport-ent-16.4.10-linux-$SYSTEM_ARCH-fips-bin.tar.gz.sha256<checksum> <filename>curl -O https://cdn.teleport.dev/teleport-ent-16.4.10-linux-$SYSTEM_ARCH-fips-bin.tar.gzVerify that the checksums match
shasum -a 256 teleport-ent-16.4.10-linux-$SYSTEM_ARCH-fips-bin.tar.gztar -xvf teleport-ent-16.4.10-linux-$SYSTEM_ARCH-fips-bin.tar.gzcd teleport-entsudo ./install
After you download and install, all of the Teleport Enterprise binaries are
installed in the /usr/local/bin
directory. You can verify you have FIPS-compliant
binaries installed by running the teleport version
command and verifying that
the X:boringcrypto
library is listed. For example:
teleport versionTeleport Enterprise 16.4.10 api/14.0.0-gd1e081e 1.22.10 X:boringcrypto
If your Teleport cluster runs on AWS, the cluster can run in US-East or US-West regions for services with low or moderate impact levels. For services with a high impact level, the cluster must run in a GovCloud region to support FIPS.
Configure the Teleport Auth Service
Save the following configuration file as /etc/teleport.yaml
on the Teleport Auth
Service:
version: v3
teleport:
auth_token: xxxx-token-xxxx
# Pre-defined tokens for adding new nodes to a cluster. Each token specifies
# the role a new node will be allowed to assume. The more secure way to
# add nodes is to use `ttl node add --ttl` command to generate auto-expiring
# tokens.
#
# We recommend to use tools like `pwgen` to generate sufficiently random
# tokens of 32+ byte length.
# you can also use auth server's IP, i.e. "10.1.1.10:3025"
auth_server: 10.1.1.10:3025
auth_service:
# enable the auth service:
enabled: true
tokens:
# this static token is used for other nodes to join this Teleport cluster
- proxy,node:xxxx-token-xxxx
# this token is used to establish trust with other Teleport clusters
- trusted_cluster:xxxx-different-token-xxxx
# To Support FIPS local_auth needs to be turned off and a SSO connector is
# required to log into Teleport.
authentication:
# local_auth needs to be set to false in FIPS mode.
local_auth: false
type: saml
# If using Proxy Mode, Teleport requires host key checks.
# This setting needs is required to start in Teleport in FIPS mode
proxy_checks_host_keys: true
# SSH is also enabled on this node:
ssh_service:
enabled: false
Configure the Teleport SSH Service
Save the following configuration file as /etc/teleport.yaml
on the Node
Service host:
version: v3
teleport:
auth_token: xxxx-token-xxxx
# Specify either the Proxy Service address...
proxy_server: teleport.example.com:3080
# or the Auth Service address
auth_server: 10.1.1.10:3025
# Enable the SSH Service and disable the Auth and Proxy Services:
ssh_service:
enabled: true
auth_service:
enabled: false
proxy_service:
enabled: false
Configure service unit file
Download the systemd
service unit file from the examples directory
on GitHub and save it as /etc/systemd/system/teleport.service
on both servers.
run this on both servers:
sudo systemctl daemon-reloadsudo systemctl enable teleport
Start Teleport in FIPS mode
When using teleport start --fips
, Teleport will start in FIPS mode.
- If the
--fips
flag is selected, Teleport will fail to start unless the binaries are compiled with the appropriate cryptographic module (BoringCrypto). - If no TLS or SSH cryptographic primitives are specified, Teleport will default to FIPS-compliant cryptographic algorithms.
- If TLS or SSH cryptographic primitives are not FIPS 140-2 compliant, Teleport will fail to start.
- Teleport will always enable at-rest encryption for both DynamoDB and S3.
- If recording proxy mode is selected, validation of host certificates should always happen.
- Running commands like
ps aux
can be useful to note that Teleport is running in FIPS mode.
Deploy a Teleport Cluster in FIPS mode with Helm
Set the following values in your cluster-values.yaml configuration:
enterpriseImage: public.ecr.aws/gravitational/teleport-ent-fips-distroless
authentication:
localAuth: false
As of Teleport version 15, versionOverride and extraArgs no longer need to be set in the values file to enable FIPS mode.
Default cryptographic algorithms
In FIPS mode, Teleport will use the following cryptographic algorithms by default.
Default FIPS ciphers for SSH:
[email protected]
[email protected]
aes128-ctr
aes192-ctr
aes256-ctr
Default FIPS Key Exchange Algorithms (KEX) for SSH:
ecdh-sha2-nistp256
ecdh-sha2-nistp384
Default FIPS Message Authentication Codes (MAC) for SSH:
[email protected]
[email protected]
hmac-sha2-256
hmac-sha2-512
Default FIPS Public Key Authentication Algorithms for SSH:
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
rsa-sha2-256
rsa-sha2-512
Default FIPS cipher suites for TLS 1.2:
tls-ecdhe-ecdsa-with-aes-128-gcm-sha256
tls-ecdhe-rsa-with-aes-128-gcm-sha256
tls-ecdhe-ecdsa-with-aes-256-gcm-sha384
tls-ecdhe-rsa-with-aes-256-gcm-sha384
Default FIPS cipher suites for TLS 1.3:
tls-aes-128-gcm-sha256
tls-aes-256-gcm-sha384
FedRAMP audit log
At the close of a connection (close of a *srv.ServerContext), the total data transmitted and received is emitted to the Audit Log.
What else does the Teleport FIPS binary enforce?
- TLS protocol version is restricted to TLS 1.2 and TLS 1.3.
- All uses of non-compliant algorithms such as NaCl are removed and replaced with compliant algorithms such as AES-GCM.
- Teleport is compiled with BoringCrypto.
- User, host, and CA certificates (and host keys for recording proxy mode) only use 2048-bit RSA private keys.
Remote desktop access
Teleport uses Rust for RDP connections, and thus uses a fork of Cloudflare's boring
library under the hood for FIPS-compliant TLS cryptography. The primary notable difference to the specifications listed above is that
TLS is restricted to TLS 1.2 only (1.3 is not supported).
Note that arm64
FIPS builds do not support access to Windows desktops.