FedRAMP Compliance
Introduction
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.
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
|
Teleport supports robust Role-based Access Controls* (RBAC). RBAC can be used to:
| AC-03 Access Enforcement
|
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 AttemptsThe information system:
|
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 NotificationThe 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 ( | AC-10 Concurrent Session ControlThe 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 Logout of all sessions (destroying credentials) indicates termination of all sessions and includes an explicit logout message. | AC-12 Session TerminationThe 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 AccessThe 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.
|
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 SystemsThe 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:
|
Teleport contains an Audit Log that records cluster-wide events such as:
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 AccountabilityThe 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 CapacityThe 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 AuthenticationThe information system uniquely identifies and authenticates organization-defined specific types of devices before establishing a connection. |
Teleport maintains several unique identifiers:
| IA-04 Identifier ManagementThe organization manages information system identifiers by:
|
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 DisconnectionThe 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 ManagementThe 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 CertificatesThe 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 AuthenticityThe 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.
Conclusion
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.
- The tsh client allows users to login to retrieve short-lived certificates.
- The teleport agent can be installed on any server, database, application and Kubernetes cluster with a single command.
# on a client$ tsh login --proxy=example.com
# on a server$ apt install teleport
# in a Kubernetes cluster$ helm install