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: Dual Authorization for SSH and Kubernetes.
- Teleport Role Templates: Dynamic Access Policies with Role Templates.
- Impersonating Teleport Users: Create certs for CI/CD using impersonation.
- Passwordless: Use passwordless authentication (Preview).
- Second Factor - WebAuthn: Add Two-Factor Authentication through WebAuthn.
- Per-session MFA: Per-session Multi-Factor Authentication.
- Locking: 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
contractors, and so on.
- Teleport would have certain Teleport Roles defined:
- 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.