Streamlining NIST 800-171 Compliance

Account Management

• Teleport integrates with SSO providers such as GitHub, Okta, Google, etc.
• Teleport supports role-based access control (RBAC) for SSH and Kubernetes
• Teleport certificate-based SSH and Kubernetes authentication and audit logging comply with these requirements without additional configuration.
• Audit events are emitted when a user is created, updated, deleted, locked, or unlocked.

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.

Session Termination

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.

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 & Accountability

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 such as S3 and DynamoDB where storage concerns are handled by the cloud provider.

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.

User Identification and Authentication

• Teleport integrates with SSO providers such as GitHub, Okta, Google, etc.
• Teleport can act as its own SSO provider
• Teleport can enforce the use of multi-factor authentication (MFA), including requiring per-session MFA
• Teleport supports PIV-compatible hardware keys

Identifier Management

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)

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.

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.

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.