mirror of
https://github.com/gravitational/teleport.git
synced 2026-10-25 10:40:02 +08:00
Alan Parra
1c09d2e408
Add the WebAuthn Access Control guide and tweak various pages that mention U2F to either refer to WebAuthn or use more generic terms. * Added `/docs/access-controls/guides/webauthn/` (branched from u2f.mdx) * Added `webauthn` section to reference configuration (`u2f` kept unchanged) * U2F access control guide moved under the "References" section and removed from the index / navigation menu * Cloud guides removed (U2F was the last guide, now deleted) * WebAuthn access control guide * Update access controls pages Update links to WebAuthn and changes lingo to refer to either WebAuthn, MFA, "second factor hardware token" and "second factor authenticator", where appropriate. U2F is moved to the references sections and WebAuthn is favored as the guide to be followed in regards to MFA hardware tokens. Generic language is used whenever possible, excluding places where we reference server configuration or protocol support. * WebAuthn cloud guide * Update cloud pages * WebAuthn config reference * Update references to U2F in various pages * Link to the WebAuthn guide in from the Authentication reference page Incorporates ibeckermayer's suggestion from https://github.com/gravitational/teleport/pull/8703. * Rephrase sentences according to reviewer feedback * Replace explicit <h2> with `##` * Move "Migrating from U2F" section to the bottom * Use numbered steps * Include tabs for Cloud in config examples * Add tctl as a prerequisite for WebAuthn setup * Remove Cloud guides U2F and WebAuthn were the last remaining items. * Make linter happy
60 lines
2.5 KiB
Plaintext
60 lines
2.5 KiB
Plaintext
---
|
|
title: Access Controls Introduction
|
|
description: Provide Role-Based Access Control (RBAC) for SSH, Kubernetes, Databases, and Web Apps.
|
|
h1: 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 second factor hardware device.
|
|
- 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](./getting-started.mdx)
|
|
guide.
|
|
|
|
## Guides
|
|
|
|
<TileSet>
|
|
<Tile icon="lock" title="Dual Authorization" href="./guides/dual-authz.mdx">
|
|
Dual Authorization for SSH and Kubernetes.
|
|
</Tile>
|
|
<Tile icon="lock" title="Teleport Role Templates" href="./guides/role-templates.mdx">
|
|
Dynamic Access Policies with Role Templates.
|
|
</Tile>
|
|
<Tile icon="lock" title="Impersonating Teleport Users" href="./guides/impersonation.mdx">
|
|
Create certs for CI/CD using impersonation.
|
|
</Tile>
|
|
<Tile icon="lock" title="Second Factor - WebAuthn" href="./guides/webauthn.mdx">
|
|
Add Two-Factor Authentication through WebAuthn.
|
|
</Tile>
|
|
<Tile icon="lock" title="Per-session MFA" href="./guides/per-session-mfa.mdx">
|
|
Per-session Multi-Factor Authentication.
|
|
</Tile>
|
|
<Tile icon="lock" title="Locking" href="./guides/locking.mdx">
|
|
Locking sessions and identities.
|
|
</Tile>
|
|
</TileSet>
|
|
|
|
## How does it work?
|
|
|
|
Consider a company using [Okta](https://www.okta.com/) 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.
|