| title | description | h1 |
|---|---|---|
Access Controls Introduction |
Provide Role-Based Access Control (RBAC) for SSH, Kubernetes, Databases, and Web Apps. |
Access Controls for SSH, Kubernetes, Databases and Web Apps |
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.
Configure Access Controls in a 5 minute Getting Started guide.
Dual Authorization for SSH and Kubernetes. Dynamic Access Policies with Role Templates. Create certs for CI/CD using impersonation. Use passwordless authentication (Preview). Add Two-Factor Authentication through WebAuthn. Per-session Multi-Factor Authentication. Locking sessions and identities.Consider a company using Okta to authenticate users and place them into groups. A typical deployment of Teleport in this scenario would involve:
- Configuring Teleport to use existing user identities stored in Okta.
- Okta would have users placed in certain groups, perhaps
developers,admins,contractors, and so on. - Teleport would have certain Teleport Roles defined:
developersandadmins. - 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.