Cam Hutchison
445f8b1e1e
* release: Move Mac signing vars from script to Makefile Move the variables for Mac signing from the `build-common.sh` shell script to the `Makefile`. These vars will need to be passed to other build processes to parameterize the signing for different GitHub Actions build environments. The switch on `ENVIRONMENT_NAME` allows different secrets to be available in GitHub Actions for production (promote) vs developer (build) builds. The default environment name is `promote` so as to be compatible with the existing Drone setup, which does not define `ENVIRONMENT_NAME`. * release: Determine Mac signing key IDs automatically Remove the hard-coded MacOS signing key IDs from the Makefile and find them dynamically based on the name of the key. This allows GitHub Actions to be set up with new keys different to the ones on the Drone builders. As long as we keep the same name on the keys, we can rotate the keys without needing to update the IDs in the Makefile. This requires us to be more judicious about exporting the variables as exporting them causes them to be evaluated. We do not want to evaluate them on non-darwin targets, and on darwin, we should only evaluate it if needed for a recipe. So use a dynamic `eval` in the recipes that need the environment variables. * release: Pass key & team ID to notarize tool Override the hard-coded values in `notarize-apple-binaries` and pass the values we get based on the GitHub Actions environment. This allows us to sign and notarize software in a development branch more easily when working on the signing and notarizing process. This will not happen automatically, but it is expected that a developer can manually trigger a workflow to perform building, signing and notarizing from a dev branch where the workflow has temporarily changed the environment to `build`. A similar change to the `Makefile` in the teleport.e repository goes with this change. This adds a new bundle ID of `com.goteleport.dev` for the dev build of Teleport. This follows the same pattern as used for the dev build of the `tsh` binary and the current production bundle ID for Teleport. Previously there was no dev signing/notarizing process for the set of Teleport binaries. * release: Add script to setup the MacOS keychain for signing Add a script for setting up the MacOS keychain for signing applications and packages. It encapsulates the `security` commands to add either or both application keys and installer keys. The keys can be either base64-encoded in environment variables, or `.p12` files on disk, making it useful for local development. * release: Split MacOS signing vars into separate mk file Put the MacOS signing variables into a separate `.mk` file and include it from the main `Makefile`. Add more comments to document the purpose of the vars and where some of the values come from. * release: Add some more comments to keychain-setup.sh Explain that the purpose of the script is to be run on CI, but can also be run manually. Add the default values used to the usage message for the keychain and password. * Address PR comments on keychain-setup.sh script * Change shebang to /bin/bash * Use heredoc instead of multiple printfs for usage message * Move `local` declaration next to setting of kpath var * release: Export DEVELOPER_ID_APPLICATION in release-darwin The sub-make for enterprise needs this to be set or it cannot sign the enterprise binaries. Export it if we are doing signing/notarizing.
Read our Blog: https://goteleport.com/blog/
Read our Documentation: https://goteleport.com/docs/getting-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?
Introduction
Teleport is the easiest, most secure way to access all your infrastructure. Teleport is an identity-aware, multi-protocol access proxy which understands SSH, HTTPS, RDP, Kubernetes API, MySQL, MongoDB and PostgreSQL wire protocols.
On the server-side, Teleport is a single binary which enables convenient secure access to behind-NAT resources such as:
- SSH nodes - SSH works in browsers too!
- Kubernetes clusters
- PostgreSQL, MongoDB, CockroachDB and MySQL databases
- Internal Web apps
- Windows Hosts
- Networked servers
Teleport is trivial to set up as a Linux daemon or in a Kubernetes pod. It's rapidly
replacing legacy sshd-based setups at organizations who need:
- Developer convenience of having instant secure access to everything they need across many environments and cloud providers.
- Audit log with session recording/replay for multiple protocols
- Easily manage trust between teams, organizations and data centers.
- Role-based access control (RBAC) and flexible access workflows (one-time access requests)
In addition to its hallmark features, Teleport is interesting for smaller teams because it facilitates easy adoption of the best infrastructure security practices like:
- No need to manage shared secrets such as SSH keys: Teleport uses certificate-based access with automatic certificate expiration time 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 Active Directory.
- 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 is built upon the high-quality Golang SSH
implementation. It is fully compatible with OpenSSH,
sshd servers, and ssh clients.
| Project Links | Description |
|---|---|
| Teleport Website | The official website of the project. |
| Documentation | Admin guide, user manual and more. |
| Demo Video | 3-minute video overview of Teleport. |
| 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
| Follow the Installation Guide
Download the latest binary release,
unpack the .tar.gz and run sudo ./install. This will copy Teleport binaries into
/usr/local/bin.
Then you can run Teleport as a single-node cluster:
sudo teleport start
In a production environment, Teleport must run as root. For testing or non-production environments, run it as the $USER:
chown $USER /var/lib/teleport
- In this case, you will not be able to log in as another user.
Docker
| Follow the Docker-Compose Getting Started Guide
Deploy Teleport
If you wish to deploy Teleport inside a Docker container:
# This command will pull the Teleport container image for version 8
docker pull public.ecr.aws/gravitational/teleport:8
View latest tags on Amazon ECR Public | gravitational/teleport
For Local Testing and Development
Follow the instructions in the docker/README file.
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 Javascript (a git submodule located in the webassets/
directory).
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 v9.1.2 gets release v9.1.2.
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
Ensure you have installed correct versions of necessary dependencies:
Goversion from go.mod- If you wish to build the Rust-powered features like Desktop Access, see the
RustandCargoversion in build.assets/Makefile (search forRUST_VERSION) - For
tshversion >10.xwith FIDO support, you will needlibfidoandopenssl 1.1installed locally - To build the web UI,
yarn(< 2.0.0) is required.- If you prefer not to install/use yarn, but have docker available, you can run
make docker-uiinstead.
- If you prefer not to install/use yarn, but have docker available, you can run
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
To build tsh with Apple TouchID support enabled:
Important
tshbinaries with Touch ID support are only functional using binaries signed with Teleport's Apple Developer ID and notarized by Apple. If you are a Teleport maintainer, ask the team for access.
make build/tsh TOUCHID=yes
To build tsh with libfido:
make build/tsh FIDO2=dynamic
-
On a Mac, with
libfidoandopenssl 1.1installed viahomebrewexport PKG_CONFIG_PATH="$(brew --prefix openssl@1.1)/lib/pkgconfig" make build/tsh FIDO2=dynamic
Build output and running 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
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.
Updating Web UI assets
After you commit a change to the webapps
repo, you need to update the Web UI
assets in the webassets/ git submodule.
Run make update-webassets to update the webassets repo and create a PR for
teleport to update its git submodule.
You will need to have the gh utility installed on your system for the script
to work. For installation instructions, read the GitHub CLI installation documentation.
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 who 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.