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.
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.