7a7f08cb39
* start the refactor away from aquasecurity/libbpfgo to use cilium/ebpf Remove debug statements and unused code in BPF library This commit eliminates unnecessary debug log statements from bpf_test.go and removes unused code in disk.go and network.go files within BPF library. The aim is to make codebase cleaner, enhancing readability and maintainability without losing track of functional aspects. It's part of an ongoing effort to maintain optimal code quality across the project. Revise Dockerfile and Makefile instructions Adjusted Dockerfile and Makefile commands to optimize build process. The changes ensure better readability and maintainability of code, especially with respect to BPF bytecode and test preparations. A clause was also added to check for the presence of clang before building BPF bytecode. Refactor BPF code and tests Refactored BPF source code and its corresponding tests for better readability and efficiency. This includes updating data structures like rawExecEvent, rawOpenEvent, rawConn4Event and rawConn6Event to their more meritorious versions like commandDataT, diskDataT, networkIpv4DataT and networkIpv6DataT respectively. Also, generated concise and clear bindigs for eBPF programs to replace the previous multi-arch setup. Furthermore, correspondingly adapted all related test cases arising in bpf_test.go, command.go and other files. Remove counter_test from BPF and related test code This commit removes the file counter_test.bpf.c from the enhanced recording in BPF. Following this file deletion, corresponding test functions in bpf_test.go, that were originally testing the functionality provided by counter_test.bpf.c, have been removed as well. Refactor BPF test and improve error handling The commit refactors the BPF test suite to run each test as a sub-test by using t.Run, easing debugging and error tracing. It also simplifies the 'executeCommand' function by removing redundant function calls related to finding executable files, and improves error handling. In 'cgroup.go', the code has been adjusted to retry on EBUSY errors when removing a cgroup, instead of ignoring them. Update cgroup deletion process and error handling The changes made introduce a retry mechanism when deleting a cgroup in case the cgroup is busy. This prevents a failed attempt from immediately returning an error. Additionally, error handling has been improved in the 'writePids' function to better handle 'no such process' errors. Enhance cgroup monitoring in disk.bpf.c The code has been updated to check if current cgroup is being monitored in the "enter_open" method of "disk.bpf.c". If the cgroup is not marked for monitoring, it will be ignored, enhancing overall cgroup management. Improve resource handling This commit introduces a deferred close to the sendEvents function to ensure proper resource handling of the eventBuf object. Add rlimit package to remove resource limits Introduced the "github.com/cilium/ebpf/rlimit" package and added a function to remove resource limits for kernels less than 5.11. This operation is necessary for kernels with a lower version because they may face issues when running applications with allocated memory limitations. Fix a test after rebase Refactor BPF testing setup and implement session closing This commit updates the BPF testing structure to remove the context dependency in event generation functions, simplifying the test setup. Additionally, it adds a 'closed' field to the 'open', 'conn', and 'exec' structs alongside mutex protection. This implementation allows checking if a session is closed before any operations, correctly handling already closed sessions. Furthermore, it corrects tracepoints for handling 'openat' and 'openat2' system calls for different platforms. This refactoring effort aims to improve the robustness and readability of the BPF testing suite. Update conditions for BPF bytecode building This update modifies the Makefile to add a conditional check for the presence of /usr/include/bpf/bpf_helpers.h. This new requirement must be met along with the existence of /usr/include/linux/bpf.h and the installation of Clang, in order to facilitate the correct build of BPF bytecode. Consequently, this change enhances the reliability of the build process. Add conditional for bpf_helpers.h in Makefile This commit adds an additional check in the Makefile for the existence of /usr/include/bpf/bpf_helpers.h. This ensures that BPF bytecode only gets built when both bpf.h and bpf_helpers.h exist, and Clang is installed, improving the build process reliability. Refactor and improve BPF bytecode generation This commit refactors and improves the BPF bytecode generation process. It introduces distinct bytecode structures for different architectures, ensuring better compatibility and execution. The BPF test is adjusted due to its tendency to fail unpredictably, hence it's commented out to avoid unnecessary build failures. This commit also eliminates certain redundancies in `common.mk`, improving the clarity of the build process. Comment out test code in bpf_test.go The test code in the file bpf_test.go has been commented out. These changes are circumstantial and do not imply that the test code is obsolete or unnecessary. The use of such tests may be needed in future commits or for local development testing and debugging. Remove libbpf dependency from Vagrantfile and update README The Vagrantfile and README have been updated to remove the no longer needed libbpf dependency. This change simplifies the project set up by eliminating unused build steps in the Vagrantfile and correcting related instructions in the README. This results in a more streamlined, intuitive build process and reduced potential for code complexity and dependency conflicts. Remove obsolete dependencies and related code blocks The 'aquasecurity/libbpfgo' library referencing and the related code blocks have been removed from the test files and core modules. The corresponding setup instructions in the dockerfiles and build scripts have also been eliminated. This update simplifies the build process and overall project structure while reducing unnecessary dependency risks. Remove aquasecurity/libbpfgo dependency Remove restricted.bpf.c Migrate disk events to cilium Migrate network events to cilium Remove restricted session Use cilium/ebpf for BPF * fix build issues caused by stale branch Also updated bpf bytecode, updated github.com/cilium/ebpf to 0.19.0, and updated bpf/README to reflect changes * fix tests and a bit of cleanup Also added a subtest and fixed receiving IPv6 network events and fixed attempting to create tracepoints for syscalls that are not present on arm64. * repurpose buffer size configs to set event channel buffer size * add new GHA job to check that generated eBPF files are up to date * fix lost event promethus counters and address feedback * address feedback * use only unsafe instead of CGO to convert C strings * rename common_data_t comm -> command * convert strings in bpf programs from char arrays to u8 or uint8 arrays so we can convert them to Go strings without the use of the unsafe package --------- Co-authored-by: Jakub Nyckowski <[email protected]> Co-authored-by: Tim Ross <[email protected]>
Teleport provides connectivity, authentication, access controls and audit for infrastructure.
Here is why you might use Teleport:
- Set up SSO for all of your cloud infrastructure [1].
- Protect access to cloud and on-prem services using mTLS endpoints and short-lived certificates.
- Establish tunnels to access services behind NATs and firewalls.
- Provide an audit log with session recording and replay for various protocols.
- Unify Role-Based Access Control (RBAC) and enforce the principle of least privilege with access requests.
[1] The open source version supports only GitHub SSO.
Teleport works with SSH, Kubernetes, databases, RDP, and web services.
- Architecture: https://goteleport.com/docs/reference/architecture/
- Getting Started: https://goteleport.com/docs/get-started/
Table of Contents
- Introduction
- Installing and Running
- Docker
- Building Teleport
- Why Did We Build Teleport?
- More Information
- Support and Contributing
- Is Teleport Secure and Production Ready?
- Who Built Teleport?
- License
Introduction
Teleport includes an identity-aware access proxy, a CA that issues short-lived certificates, a unified access control system and a tunneling system to access resources behind the firewall.
We have implemented Teleport as a single Go binary that integrates with multiple protocols and cloud services:
- SSH nodes.
- Kubernetes clusters
- PostgreSQL, MongoDB, CockroachDB and MySQL databases.
- Internal Web apps.
- Windows Hosts.
- Networked servers.
You can set up Teleport as a Linux daemon or a Kubernetes deployment.
Teleport focuses on best practices for infrastructure security:
- No need to manage shared secrets such as SSH keys or Kubernetes tokens: it uses certificate-based auth with certificate expiration for all protocols.
- Two-factor authentication (2FA) for everything.
- Collaboratively troubleshoot issues through session sharing.
- Single sign-on (SSO) for everything via GitHub Auth, OpenID Connect, or SAML with endpoints like Okta or Microsoft Entra ID.
- Infrastructure introspection: Use Teleport via the CLI or Web UI to view the status of every SSH node, database instance, Kubernetes cluster, or internal web app.
Teleport uses Go crypto. It is fully compatible with OpenSSH, sshd servers, and ssh clients, Kubernetes clusters and more.
| Project Links | Description |
|---|---|
| Teleport Website | The official website of the project. |
| Documentation | Admin guide, user manual and more. |
| Blog | Our blog where we publish Teleport news. |
| Forum | Ask us a setup question, post your tutorial, feedback, or idea on our forum. |
| Slack | Need help with your setup? Ping us in our Slack channel. |
| Cloud-hosted | We offer Enterprise with a Cloud-hosted option. For teams that require easy and secure access to their computing environments. |
Installing and Running
To set up a single-instance Teleport cluster, follow our getting started guide. You can then register your servers, Kubernetes clusters, and other infrastructure with your Teleport cluster.
You can also get started with Teleport Enterprise Cloud, a managed Teleport deployment that makes it easier to enable secure access to your infrastructure.
Sign up for a free trial of Teleport Enterprise Cloud.
Follow our guide to registering your first server with Teleport Enterprise Cloud.
Docker
Deploy Teleport
If you wish to deploy Teleport inside a Docker container see the installation guide.
For Local Testing and Development
To run a full test suite locally, see the test dependencies list
Building Teleport
The teleport repository contains the Teleport daemon binary (written in Go)
and a web UI written in TypeScript.
If your intention is to build and deploy for use in a production infrastructure
a released tag should be used. The default branch, master, is the current
development branch for an upcoming major version. Get the latest release tags
listed at https://goteleport.com/download/ and then use that tag in the git clone.
For example git clone https://github.com/gravitational/teleport.git -b v18.0.0 gets release v18.0.0.
Dockerized Build
It is often easiest to build with Docker, which ensures that all required tooling is available for the build. To execute a dockerized build, ensure that docker is installed and running, and execute:
make -C build.assets build-binaries
Local Build
Dependencies
The following dependencies are required to build Teleport from source. For
maximum compatibility, install the versions of these dependencies using the
versions listed in build.assets/versions.mk:
For an example of Dev Environment setup on a Mac, see these instructions.
Perform a build
Important
- The Go compiler is somewhat sensitive to the amount of memory: you will need at least 1GB of virtual memory to compile Teleport. A 512MB instance without swap will not work.
- This will build the latest version of Teleport, regardless of whether it is stable. If you want to build the latest stable release, run
git checkoutandgit submodule update --recursiveto the corresponding tag (for example,- run
git checkout v8.0.0) before performing a build.
Get the source
git clone https://github.com/gravitational/teleport.git
cd teleport
To perform a build
make full
tsh dynamically links against libfido2 by default, to support development
environments, as long as the library itself can be found:
$ brew install libfido2 pkg-config # Replace with your package manager of choice
$ make build/tsh
> libfido2 found, setting FIDO2=dynamic
> (...)
Release binaries are linked statically against libfido2. You may switch the linking mode using the FIDO2 variable:
make build/tsh FIDO2=dynamic # dynamic linking
make build/tsh FIDO2=static # static linking, for an easy setup use `make enter`
# or `build.assets/macos/build-fido2-macos.sh`.
make build/tsh FIDO2=off # doesn't link libfido2 in any way
tsh builds with Touch ID support require access to an Apple Developer account.
If you are a Teleport maintainer, ask the team for access.
Build output and run locally
If the build succeeds, the installer will place the binaries in the build directory.
Before starting, create default data directories:
sudo mkdir -p -m0700 /var/lib/teleport
sudo chown $USER /var/lib/teleport
Running Teleport in a hot reload mode
To speed up your development process, you can run Teleport using
CompileDaemon. This will build
and run the Teleport binary, and then rebuild and restart it whenever any Go
source files change.
-
Install CompileDaemon:
go install github.com/githubnemo/CompileDaemon@latestNote that we use
go installinstead of the suggestedgo get, because we don't want CompileDaemon to become a dependency of the project. -
Build and run the Teleport binary:
make teleport-hot-reloadBy default, this runs a
teleport startcommand. If you want to customize the command, for example by providing a custom config file location, you can use theTELEPORT_ARGSparameter:make teleport-hot-reload TELEPORT_ARGS='start --config=/path/to/config.yaml'
Note that you still need to run make grpc if you modify
any Protocol Buffers files to regenerate the generated Go sources; regenerating
these sources should in turn cause the CompileDaemon to rebuild and restart
Teleport.
Web UI
The Teleport Web UI resides in the web directory.
Rebuilding Web UI for development
To rebuild the Teleport UI package, run the following command:
make docker-ui
Then you can replace Teleport Web UI files with the files from the newly-generated /dist folder.
To enable speedy iterations on the Web UI, you can run a local web-dev server.
You can also tell Teleport to load the Web UI assets from the source directory.
To enable this behavior, set the environment variable DEBUG=1 and rebuild with the default target:
# Run Teleport as a single-node cluster in development mode:
DEBUG=1 ./build/teleport start -d
Keep the server running in this mode, and make your UI changes in /dist directory.
For instructions about how to update the Web UI, read the web README.
Managing dependencies
All dependencies are managed using Go modules. Here are the instructions for some common tasks:
Add a new dependency
Latest version:
go get github.com/new/dependency
and update the source to use this dependency.
To get a specific version, use go get github.com/new/dependency@version instead.
Set dependency to a specific version
go get github.com/new/dependency@version
Update dependency to the latest version
go get -u github.com/new/dependency
Update all dependencies
go get -u all
Debugging dependencies
Why is a specific package imported?
go mod why $pkgname
Why is a specific module imported?
go mod why -m $modname
Why is a specific version of a module imported?
go mod graph | grep $modname
Why did We Build Teleport?
The Teleport creators used to work together at Rackspace. We noticed that most cloud computing users struggle with setting up and configuring infrastructure security because popular tools, while flexible, are complex to understand and expensive to maintain. Additionally, most organizations use multiple infrastructure form factors such as several cloud providers, multiple cloud accounts, servers in colocation, and even smart devices. Some of those devices run on untrusted networks, behind third-party firewalls. This only magnifies complexity and increases operational overhead.
We had a choice, either start a security consulting business or build a solution that's dead-easy to use and understand. A real-time representation of all of your servers in the same room as you, as if they were magically teleported. Thus, Teleport was born!
More Information
Support and Contributing
We offer a few different options for support. First of all, we try to provide clear and comprehensive documentation. The docs are also in GitHub, so feel free to create a PR or file an issue if you have ideas for improvements. If you still have questions after reviewing our docs, you can also:
- Join Teleport Discussions to ask questions. Our engineers are available there to help you.
- If you want to contribute to Teleport or file a bug report/issue, you can create an issue here in GitHub.
- If you are interested in Teleport Enterprise or more responsive support during a POC, we can also create a dedicated Slack channel for you during your POC. You can reach out to us through our website to arrange for a POC.
Is Teleport Secure and Production-Ready?
Yes -- Teleport is production-ready and designed to protect and facilitate access to the most precious and mission-critical applications.
Teleport has completed several security audits from nationally and internationally recognized technology security companies.
We publicize some of our audit results, security philosophy and related information on our trust page.
You can see the list of companies that use Teleport in production on the Teleport product page.
Who Built Teleport?
Teleport was created by Gravitational, Inc.. We have built Teleport by borrowing from our previous experiences at Rackspace. Learn more about Teleport and our history.
License
Teleport is distributed in multiple forms with different licensing implications.
The Teleport API module (all code in this repository under /api) is available
under the Apache 2.0 license.
The remainder of the source code in this repository is available under the GNU Affero General Public License. Users compiling Teleport from source must comply with the terms of this license.
Teleport Community Edition builds distributed on http://goteleport.com/download are available under a modified Apache 2.0 license.