Fork me on GitHub
Teleport

Access Controls for SSH, Kubernetes, Databases and Web Apps

Introduction

Here are examples of access policies you can define with Teleport:

  • Analytics team members can SSH into the MongoDB read replica, but not the main database.
  • Interns can't access production databases.
  • Devops can access the production server only when using a registered U2F hardware token.
  • Members of my team can access the production Kubernetes cluster if approved by someone else from the team.

Role-Based Access Control (RBAC) is almost always used in conjunction with Single Sign-On (SSO), Github (in the Teleport Open Source Edition), and OIDC or SAML (in the Teleport Enterprise editions).

It also works with users stored in Teleport's internal database.

Getting started

Configure Access Controls in a 5 minute Getting Started guide.

Guides

How does it work?

Consider a company using Okta to authenticate users and place them into groups. A typical deployment of Teleport in this scenario would involve:

  1. Configuring Teleport to use existing user identities stored in Okta.
  2. Okta would have users placed in certain groups, perhaps developers, admins, contractors, and so on.
  3. Teleport would have certain Teleport Roles defined: developers and admins.
  4. Mappings would connect the Okta groups (SAML assertions) to the defined Teleport roles.

Every Teleport user will be assigned a Teleport role based on their Okta group membership.

Have a suggestion or can’t find something?
IMPROVE THE DOCS