Teleport provides connectivity, authentication, access controls and audit for infrastructure.
Here is why you might use Teleport:
[1] The open source version supports only GitHub SSO.
Teleport works with SSH, Kubernetes, databases, RDP, and web services.
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:
You can set up Teleport as a Linux daemon or a Kubernetes deployment.
Teleport focuses on best practices for infrastructure security:
Teleport uses Go crypto. It is fully compatible with OpenSSH, sshd servers, and ssh clients, Kubernetes clusters and more.
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.
If you wish to deploy Teleport inside a Docker container see the installation guide.
For Local Testing and DevelopmentTo run a full test suite locally, see the test dependencies list
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 v16.0.0 gets release v16.0.0.
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
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.
Linux 64-bit ARM Dependenciesbinaryen. Check with which wasm-opt. If not found, install with apt-get install binaryen (Debian-based systems). On other platforms, wasm-pack installs it automatically.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
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.
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/teleportRunning 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@latest
Note that we use go install instead of the suggested go get, because we don't want CompileDaemon to become a dependency of the project.
Build and run the Teleport binary:
By default, this runs a teleport start command. If you want to customize the command, for example by providing a custom config file location, you can use the TELEPORT_ARGS parameter:
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.
The Teleport Web UI resides in the web directory.
Rebuilding Web UI for developmentTo rebuild the Teleport UI package, run the following command:
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.
All dependencies are managed using Go modules. Here are the instructions for some common tasks:
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.
go get github.com/new/dependency@versionUpdate dependency to the latest version
go get -u github.com/new/dependency
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
Note: Devbox support is still experimental. It's very possible things may not work as intended.
Teleport can be built using devbox. To use devbox, follow the instructions to install devbox here and then run:
devbox shell
This will install Teleport's various build dependencies and drop you into a shell with these dependencies. From here, you can build Teleport normally.
A nix flake is located in build.assets/flake that allows for installation of Teleport's less common build tooling. If this flake is updated, run:
devbox install
in order to make sure the changes in the flake are reflected in the local devbox shell.
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!
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:
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.
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.
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4